Issues with Imagesheets/Image Groups/Sprites from build 759+

Solar2D Daily Builds and Public Releases
#1

Hi everyone,

The comment thread for the “Image Sheets, Image Groups, and Sprites” blog post is getting pretty full, so I moved the discussion here.

Issues that are currently being addressed right now, and will be in one of the upcoming daily builds soon is:

  • spriteObject.frame is currently read-only. We are working on adding a spriteObject:setFrame() method to allow you to switch to a specific frame.

  • We’re working on adding an event.target to the sprite listener (see the updated blog post for an example of how to use the new sprite listener—in short, it currently only has a “began” and “ended” event.phase).

  • We are working on a fix for the imageGroup:insert() issue.

Please post a reply to this thread if you are experiencing any other issues, or if something was left out of the blog post.

Thanks for all your help in getting these API’s cleaned up! [import]uid: 52430 topic_id: 23275 reply_id: 323275[/import]

#2

One possible issue… And I say “possible” because it might be part of point #3 above (image groups). I tried a basic scenario with image groups and they didn’t clean up properly; as in, they locked the texture memory from the “parent” imageSheet and would not release it, even when the image group children were removed, the group itself removed, and then the group nil’led out. Has anybody else observed or tested this? My testing was fairly basic so I don’t want to claim this is a proven bug at this point… just something to check into.

Brent Sorrentino
Ignis Design [import]uid: 9747 topic_id: 23275 reply_id: 93194[/import]

#3

@jonathanbeebe Just to let you know, I’ll submit the bug I described at the comments later tonight, when I get back to work, glad to help! :slight_smile: [import]uid: 13811 topic_id: 23275 reply_id: 93216[/import]

#4

I have another thread about this but I can’t seem to get the answer. While I now know that spriteObject.frame is read only I’m wondering if you’re able to change the frame of a newImageRect() after it has been created.

I’m making a game with lots of tiles which changes frames but they do not have animations, would there be a performance loss in using spriteObjects instead of rects? [import]uid: 129450 topic_id: 23275 reply_id: 93241[/import]

#5

Thanks for the info, Jonathan.

How long would we (approximately) need to wait for this spriteObject:setFrame() method?

We are facing the same problem as info583 above. The problem is that our app is near publication (planned to be released within a week) and due to the great and noticeable performance boost the new API gives, we decided to switch to new sprites entirely (using image sheets and display.newImageRect). It really makes a big difference!

After updating our project, we found that it currently isn’t possible to switch to a specific frame anymore (since Sprite.currentFrame doesn’t work), which is a vital feature that was used throughout our app.

Now we have to decide either to switch back to the old API (which would make the App noticeable slower again) or wait for this method to be added.

So we’d need to know if there is any (approximate) time frame to count with? Would this be a matter of days only or would it take clearly longer?
[import]uid: 10504 topic_id: 23275 reply_id: 93243[/import]

#6

Excellent question @info583! I meant to ask this when the API was first released. I assume that’s one of the key benefits in the new imageSheet API: the ability (upcoming?) to switch the “frame” of a *static* image, not just an animated sprite. Somebody please correct me if I’m wrong, but in the previous image APIs there was no easy way to simply swap one image with another image, unless you made it into a sprite and then changed the frame… but that obviously added some bloat to objects which didn’t need full animation capability. [import]uid: 9747 topic_id: 23275 reply_id: 93299[/import]

#7

We’ve got several fixes coming in tomorrow’s daily build (767 or after)

* Adding spriteObject:setFrame( index ): index can be from 1 to the number of frames specified in the sequence data.
* Adding event.target to the sprite listener (this only applies to listeners used in the *new* Sprite API).
* Fix for the imageGroup:insert() issue when inserting sprites
* Fix for sprite:pause()/sprite:play() when the sequence is time-based
* Fix for w/h issue for sequences with different frame sizes on each frame (previously the w/h defaulted to the w/h of the first frame causing subsequent frames to be skewed/scaled improperly)
[import]uid: 26 topic_id: 23275 reply_id: 93412[/import]

#8

So every sprite instance requires its own sequence data now?

[lua]local character = display.newSprite( imageSheet, sequenceData )
character:setFrame(1)[/lua]

Doesn’t this produce some overhead compared to the old API when using and creating many sprites at once? If we only want to use “static” sprites and swap a sprite’s frame (without animation), it would probably be enough to let each sprite automatically know all of the sheet’s frames (number of total frames etc.) without the need to create special sequence data for each sprite -at a first glance, at least.
[import]uid: 10504 topic_id: 23275 reply_id: 93487[/import]

#9

>>spriteObject:setFrame() <<

Yay.
Signed on here to keep abreast of news. Apologies for post on same topic but different thread today. (Wish Id seen this first) [import]uid: 108660 topic_id: 23275 reply_id: 93504[/import]

#10

How can we swap the displayed frame with images created using display.newImageRect from an image sheet?

[lua]image = display.newImageRect( imageSheet, frameNum, frameWidth, frameHeight )[/lua]

And would it be more efficient to use newImageRect then instead of sprites if we do not need animation and just want to be able to swap the currently displayed frame of an image?
[import]uid: 10504 topic_id: 23275 reply_id: 93517[/import]

#11

@x-pressive.com said:

So every sprite instance requires its own sequence data now?

Not necessarily. If I understand your question, do you mean that every sprite instance must have its own self-linked sequence data? Not really… the sequence data can be stored in a separate table and then the named sequences can be used and re-used for any sprite via an upvalue lookup. So in theory, you could have 4 different sprites using 4 different image sheets, but use just ONE sequence for all of them, assuming that sequence “pattern” (start frame, count, time, etc.) was the same for all 4 sprites. I think keeping the sequence data outside of the image sheet is, in this new API, more flexible… and upvalue lookups shouldn’t cause a noticeable performance hit unless you’re doing 10000 of them in a loop or something similar.

I do, however, hope Ansca adds “timeScale” to the new API. If I have 3 core player animations, and I also want the same 3 sequences in a *faster* time loop, I now have to add 3 new sequences and switch from “normal” to “faster” every time. In the old API, “sprite.timeScale” allowed me to just speed up or slow down the same sequence, on the fly, with one command. Much easier. :slight_smile:

And would it be more efficient to use newImageRect then instead of sprites if we do not need animation and just want to be able to swap the currently displayed frame of an image?

I mentioned this in my comment above. Most likely the upcoming "sprite:setFrame(frame)" will work perfectly well with *static* images too, not just sprites. I think that was one of the key points in this entire API… previously if we wanted an object with 2 “frames” that we wanted to change occasionally (i.e. a light bulb “on” and “off” images), we had to make it into a sprite and swap the frames. This added unnecessary overhead to an object which really wasn’t an animation.

Brent
[import]uid: 9747 topic_id: 23275 reply_id: 93552[/import]

#12

Image objects will always display the same image, so use sprites if you want to swap the frame of a sheet, e.g. a button with an up and down state.
[import]uid: 26 topic_id: 23275 reply_id: 93565[/import]

#13

@ignisdesign, sprite.timeScale is available in the new Sprite API as of today’s daily build (767). [import]uid: 26 topic_id: 23275 reply_id: 93566[/import]

#14

> Doesn’t this produce overhead…

You can reuse the sequenceData table in multiple sprites.

See “Single Sequence; consecutive frames” in the sprite tutorial:

http://blog.anscamobile.com/2012/03/image-sheets-image-groups-and-sprites/

There are several ways to structure sequenceData. For consecutive frames of the same width/height (the use case you allude to), it’s actually quite simple.
[import]uid: 26 topic_id: 23275 reply_id: 93568[/import]

#15

Hi Walter,
Thanks for the prompt response! However, I’m a little perplexed by “make ‘changeable’ images into sprites”. The following is quoted from Jonathan’s blog post on the new API…

“It is very possible that you may already be implementing this type of functionality using the previous (and now deprecated) sprite API. The problem with that is, the sprite API was made to be used for animations, so there was a lot of unnecessary “baggage” that came along with any of your static objects that were created in that manner.”

So it’s the same with the new API, and will be so in the “final” release? Does this add the same amount of baggage as before? Will there ever be a command to simply swap an image from one frame to another, assuming both frames are from the same imageSheet? I think alot of developers would like this feature.

And thank you VERY much for “timeScale”. This features was awesome in the previous API and I will download the next build so I can use it again. :slight_smile:

Thanks,
Brent Sorrentino
Ignis Design
[import]uid: 9747 topic_id: 23275 reply_id: 93571[/import]

#16

The wording is a little unclear, and we probably could have framed it better (no pun intended).

The unnecessary baggage we observed was that people were using sprites to optimize texture memory (e.g. single frame sprites sharing the same spritesheet).

With image sheets, you don’t need to use sprites if all you want to do is optimize texture memory by grouping multiple images onto a single image file. Previously, you could only use the old sprite API (sprites + sprite sheets). With the new set of API’s, you can use newImage/newImageRect with image sheets — here you avoid creating sprites that you don’t need to.

If you want to switch between frames, you should still use sprites. You can either use them for animation or for switching between static frames. [import]uid: 26 topic_id: 23275 reply_id: 93582[/import]

#17

With the new set of API’s, you can use newImage/newImageRect with image
sheets — here you avoid creating sprites that you don’t need to.

If you want to switch between frames, you should still use sprites. You can
either use them for animation or for switching between static frames.

So : when we get back the ability to set the frame for a sprite, does this mean we are back with the old performance?
Is new sprite == old sprite??
[import]uid: 108660 topic_id: 23275 reply_id: 93584[/import]

#18

OK thanks Walter!

One more question: the new Dailiy Build says it adds:

"sprite.sequence"

…and the original blog post mentions:

"spriteObject:setSequence( name )"

Can you clarify the difference between these? Are they interchangeable? Are they both read/write?

EDIT: stupid question on my part. I assume that "sprite.sequence" is the read function, and "sprite:setSequence(name)" sets it… same correlation as "sprite.frame" and the new "sprite:setFrame(frame)" [import]uid: 9747 topic_id: 23275 reply_id: 93583[/import]

#19

@IgnisDesign: For right now sprite properties, such as sprite.sequence are read-only. To get the currently loaded sequence, you can query sprite.sequence. To set a new sequence, use sprite:setSequence().

@jeff472: With Walter’s latest check-in, you can now set the frame for the sprite using sprite:setFrame(), and you will still gain the performance benefits that were introduced with this API :slight_smile: [import]uid: 52430 topic_id: 23275 reply_id: 93612[/import]

#20

Thanks for clarifying this. One question though: does display.newImageRect provide any better graphics (drawing) performance compared to display.newSprite (if there is no need to change the frame of an image at a later time), except that display.newImageRect may use less memory than using sprites? [import]uid: 10504 topic_id: 23275 reply_id: 93624[/import]