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]
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. :-/
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]
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]
#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]
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]
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]