newSpriteSheet and other methods not available in sprite object

Sorry if this is an error on my part but I can’t find a reference to this, nor is there any source code to check it against:

Step 1:

local sprite = require “sprite”

Sprite object is OK:
table: 0x3ce930

pairs(sprite):
__gc function: 0x1ae19760

Step 2:
local spriteSheet = sprite.newSpriteSheet(“chimpTex8x8.png”, 128, 128)

Result:
…attempt to call field ‘newSpriteSheet’ (a nil value)

No other documented methods (such as sprite.newSprite()) seem to be available on the returned object either.

I’m probably doing something wrong, as I’m not very familiar with Lua. Thanks in advance for anyone who can point me in the right direction.

Version: 0.1.0
Build: 2010.6.17.1
[import]uid: 3953 topic_id: 1445 reply_id: 301445[/import]

Hmm. After testing this, it seems to work if you do this instead:

[lua]require “sprite”[/lua]

…which is not what our documentation says, and not how our other built-in libraries work!

So I just edited our online docs to match the above, but I’m logging this as bug #296 because it’s not consistent behavior. [import]uid: 3007 topic_id: 1445 reply_id: 4032[/import]

OK, thanks.

Also, in the docs it says sprite.newSprite() but it actually expects a spriteSet parameter. [import]uid: 3953 topic_id: 1445 reply_id: 4034[/import]

You are correct! I’ve just fixed that too. [import]uid: 3007 topic_id: 1445 reply_id: 4036[/import]

Another thing I’ll throw in: when you call a prepare() on a newSprite, it will not loop unless the starting frame in the spriteSet is 1.

Any sprites created with this method will play once then disappear if the named spriteSet has a starting frame other than 1.

The usual caveats apply in that I’m just learning Corona, aso I may be doing something wrong. I can supply source if req.

EDIT: in looking for a workaround, I found that spriteInstance:addListener(…) is rejected. [import]uid: 3953 topic_id: 1445 reply_id: 4037[/import]

I emailed these issues around 2-3 weeks ago to beta@anscamobile.com (as it is stated on the download page) but I guess Ansca didn’t took notice of this. Sometimes you have wonder. :-/

[import]uid: 5712 topic_id: 1445 reply_id: 4038[/import]

All of these (#306, #296) are fixed in GE Alpha 3. [import]uid: 54 topic_id: 1445 reply_id: 4063[/import]

Where do we check these bug ID listings? I see there’s a new public site, but only a few most recent reports. Are these bugs (such as 306 and 296) only on your internal database? [import]uid: 3953 topic_id: 1445 reply_id: 4348[/import]

Yes, #306 and #296 are on our internal bug database. We’ve been trying to make that public but decided to switch to a public database instead. All new bugs will be tracked on the public one.
https://developer.anscamobile.com/project/issues/ [import]uid: 7559 topic_id: 1445 reply_id: 4349[/import]

OK, thanks for the info Tom. [import]uid: 3953 topic_id: 1445 reply_id: 4368[/import]

About the so-called fixes in Game SDK alpha 3:

#296 require “sprite” doesn’t return anything - fixed
#306 sprite won’t loop unless starting frame is 1 - NOT fixed*
#591 event.sprite isn’t pushed for sprite listener - NOT fixed. addListener() is still nil
#594 sprite properties need implementation - Don’t know about this. Certainly methods (as above) are missing

*Now will only loop if start frame is 1-16 (inclusive), except in odd exception** below:

sprite.add(spriteSet, “seq1”, 16, 16, 1500) - works
sprite.add(spriteSet, “seq1”, 17, 16, 1500) - doesn’t work
sprite.add(spriteSet, “seq1”, 17, 32, 1500) - **DOES work!
sprite.add(spriteSet, “seq1”, 33, 32, 1500) - doesn’t work

My tests use a 1024x1024 tex atlas & I declare frames as 128x128 in sprite.newSpriteSheet()

Unless the API has changed in an unexpected wat, items 306 and 591 seem to be a big ommission. I’m not sure how they can have been ticked off by QA as fixed.

Also, as I’ve reported elsewhere, the physics engine still does not work with sprites. Crashes simulator. I know it’s only alpha, but these are all pretty rudimentary bits of functionality for a 2D sprite engine. [import]uid: 3953 topic_id: 1445 reply_id: 4942[/import]

Mark,

#591 event.sprite isn’t pushed for sprite listener - NOT fixed. addListener() is still nil

It’s not addListener, it’s addEventListener. The docs are wrong and we’ll fix that.

#306, so you are saying it works fine for start frame 1-16, but not 18? Weird, we’ll look into that.

The physics engine does work with sprites, if you have a case that doesn’t please post or send some sample code… thanks.
[import]uid: 54 topic_id: 1445 reply_id: 4978[/import]

Just updated the online sprite sheet docs to addEventListener() rather than addListener(). [import]uid: 3007 topic_id: 1445 reply_id: 4979[/import]

Thanks for the clarification re addEventListener.

Yes, if start frame is 1-16 it will loop OK.

If start frame is > 16 it will not work, except in certain cases, such as start frame 17 and frame count == 32

There’s probably some unintended (or undocumented) logic to this, but I haven’t figured it out yet (maybe some column-major code buried in there somewhere?)

Perhaps the designer and/or tester had a particular behaviour in mind. In my test I’m using an 8x8 frame tex atlas 1024x1024 pixels (128x128 cells) and animation routines of 8 or 16 frames. [import]uid: 3953 topic_id: 1445 reply_id: 4986[/import]

And just reaffirming your statement that physics is in fact working with sprites. 'Twas my mistake in not calling physics.start() [import]uid: 3953 topic_id: 1445 reply_id: 4987[/import]

Mark, I reproduced the problem with higher start frames, and wow, that’s really weird. It also is varying the frame time. I’m upping the priority of that bug, #689. [import]uid: 54 topic_id: 1445 reply_id: 5107[/import]

Hi Eric.

User Neoblargg has pinpointed the problem in this post in the online docs.

EDIT: it also explains why starting from frame 1 is the only sequence that works as expected, because endframe and framecount are the same. [import]uid: 3953 topic_id: 1445 reply_id: 5109[/import]

Any news on this one? It’s hard to do anything useful with spritesheets with the current restriction. Perhaps it’s just a matter of removing the erroneous exception thrown? Perhaps I should enter this on the new bug database. [import]uid: 3953 topic_id: 1445 reply_id: 5203[/import]

Doh; I reviewed the code, and you guys are absolutely correct, mea maxima culpa. It’s now fixed for the next drop, which will be out shortly after Beta 8, which is coming out real soon now. I’m awfully sorry… Created issue 1758. [import]uid: 54 topic_id: 1445 reply_id: 5207[/import]

OK, thanks. I’ve just entered it into the new bug database, so feel free to delete it if I’ve duplicated your entry. [import]uid: 3953 topic_id: 1445 reply_id: 5209[/import]