FYI. 13890 is fixed in the next daily build [import]uid: 26 topic_id: 23275 reply_id: 108170[/import]
13890 fixes the visibility problems with image groups, but not the problems with sprites within image groups. However Danny has let me know that this issue is still in the system and the engineers are aware of it 
[import]uid: 46639 topic_id: 23275 reply_id: 108372[/import]
@inas, Good catch. Yes, this is bug #14525. Fix is on the way. [import]uid: 26 topic_id: 23275 reply_id: 108604[/import]
Any chance you could update
http://blog.anscamobile.com/2012/03/image-sheets-image-groups-and-sprites/
with the new features/changes to the APIs?
There’s no mention of trimming support, and in release notes I can see that such support was added, how does it work?
[import]uid: 109453 topic_id: 23275 reply_id: 108631[/import]
And one more thing.
I’m trying to use the new animation system. When using old iphone [i.e. low res graphics] everything is fine. Once I change to Iphone 4 I get some kind of “bounciness”.
Take a look at this video: https://www.dropbox.com/s/9acg23le58pckxj/ScreenRecordMovie19.mov
Any ideas why would that happen? [import]uid: 109453 topic_id: 23275 reply_id: 108658[/import]
I did update to 2012.825, and a lot of the image sheet issues did go away. Thank you! But…
I am still getting a “ghost” image of a sprite in certain cases. I have a sprite with physics as kinematic, and when I touch or move another physics object, a ghost image will remain where the kinematic image was at the time, and the kinematic image continues to move. If I set the object’s isVisible = false, then both images will disappear. [import]uid: 114363 topic_id: 23275 reply_id: 108855[/import]
hey guys,
any chance you could trigger the sprite listener for every frame instead only for began and ended phases?
It is very difficult to simulate the previous behavior. I have to trigger sprite listener myself from enterFrame, checking if current frame is different than frame from previous enter frame.
Unfortunately even with that I ran into trouble, as it means sprite listener is triggered twice for first and last frame…
Also… how to properly detect that loop occured?
[import]uid: 109453 topic_id: 23275 reply_id: 109341[/import]
I think my current issue is the “ghost” issue I’m seeing when I set
[lua]object.isVisible = false;[/lua]
I have an imagesheet with 6 different backgrounds. I load all of them up and set isVisible = false to ones I don’t need.
I have them scrolling and I see a “ghost” image of one of the ones that DOES NOT have isVisible = false;
So, I actually don’t see the isVisible = false images, just a copy of one that IS visible trailing behind it as it scrolls.
If I remove all these sheets from the imagegroup I put them in they work just fine.
What I’m using isn’t sprites it’s images done with the
[lua]local image = display.newImage(sheet, frameindex)[/lua]
Edit: I’m using the latest 828 build. [import]uid: 123298 topic_id: 23275 reply_id: 109735[/import]
@krystian6, schizoid2k
We need a test case to investigate your issues, as we believed the issue was addressed. If you haven’t already, please file a bug and attach a simple test case — I say simple b/c otherwise it’ll take us a lot longer to dig into your issue. Let us know the bug numbers.
@Axie Studios, you are encountering a limitation in image groups. Image groups are designed as an optimization where you have lots of images (a lot more than just 6) and right now we’re limiting what you can do on each child to preserve certain performance characteristics (e.g. setting isVisible, etc). I notice in your case you only have 6 backgrounds, so the best thing to do is to stick them in a normal group, as you won’t get any performance benefit from using image groups.
[import]uid: 26 topic_id: 23275 reply_id: 109756[/import]
@walter Oh ok. I didn’t know that. How may frames would you say that I need before I start putting them in image groups?
I have 3 other sheets that vary from 22 to 26 different images on one sheet. [import]uid: 123298 topic_id: 23275 reply_id: 109786[/import]
Hi Walter,
I spent quite a bit of time trying to duplicate this in a test program, but I cannot get it to occur… but I think I know why.
This ghosting happens in 2 places in my app, and in both cases, I am performing some intensive work – in one case it is several loops, and in the other case it is adding some physics objects to the screen. When I commented out those block in my code, there was no ghosting
So it seems that in cases of “heavier” processing, the ghosting appears. I am at a loss as to how to fix this in my code since the loops check the status of several sprites at given intervals, and I add more physics objects if needed.
I hope this helps. [import]uid: 114363 topic_id: 23275 reply_id: 109795[/import]
@walter: How is ghosting because of setting the isvisible property NOT a bug? Your comment concerns me because I already have a bug filed with exactly that issue, and I was lead to believe it will be fixed. While I agree that 6 images (5 of whch would be hidden!) is going toget zero speed benefits from image groups, that does not mean it is inherently wrong to set it up lke that.
Naturally for now he can use normal groups as a pwrfectly worthwhile wokaround, and I apologise if this was the intent of your post and I misunderstood. [import]uid: 46639 topic_id: 23275 reply_id: 109800[/import]
@rakoonic only 2 of them are hidden instead of 5.
They’re layered on top of each other to get that parallax feeling. I swap two out when you hit “warp speed” in my game.
I had two different regular star images, and 2 different warp speed star images.
My problem was while the warp speed stars had isVisible = false.
1 of the 2 regular stars had a copy of itself “ghosting” behind it as it moved.
The other remaining two were a sky background at the very back and then a pause menu screen. [import]uid: 123298 topic_id: 23275 reply_id: 109802[/import]
@axie, ah ok thanks for clearing that up. However. i think you wont see a noticable speed difference still between image groups or proper display groups. Displaygroups make a real difference when you are talking about100s of sprites, not 4 or 5. In fact my own speed tests showed me that there is no speed gain using image sheets in display groups when compared to normal images, so if you have memory issues you could try loading your individual images by a simple newImage() call. [import]uid: 46639 topic_id: 23275 reply_id: 109823[/import]
Anybody knows if they are going to add a “next frame” event listener to this API?? (as they old spritesheet api did have)
I absolutely need it to finish my game, it means a huge difference in performance and quality!!!
[import]uid: 105206 topic_id: 23275 reply_id: 111150[/import]
@nml: I would need that too. Right now i split the whole animation into multiple animations, a dirty workaround. [import]uid: 90610 topic_id: 23275 reply_id: 111153[/import]
@dingo
yeah, i’m doing that too. i believe it is ridiculous to have to do all that work, it means slowing down the app while having no need to actually do it. I don’t understand why they haven’t added the “next” phase from the start, but well, they might have their reasons.
I just want to know if there is any intention of doing this short-time, cause if not, i’ll have to change a huge amount of code! (and i don’t want to do it for nothing) [import]uid: 105206 topic_id: 23275 reply_id: 111171[/import]
I know this isn’t necessarily the best suggestion, and might not even be possible within your game structure, but could you add a somewhat hacked “next-frame listener” to your code manually?
For example, attach a flag variable “.previousFrame” to the sprite (it starts at value 1, or whatever the starting frame of your sprite is). Then start a Runtime listener that compares the sprite’s “.frame” value (the one Corona uses to read/reference the frame) to this “previousFrame” value. If the two aren’t equal, that indicates the frame has changed… and then you can call the function you need, as if a next-frame listener was called. Of course, when this happens you also update “.previousFrame” to the current frame.
I understand this isn’t ideal, and maybe not even possible within your structure, i.e. if you have dozens of sprites that need tracking, it would be difficult to implement it. I’m just thinking, if your game(s) are really on the cusp of hitting the market and you need this kind of functionality to improve them, this “hack” might do the trick until Ansca gets the real next-frame listener in.
Brent Sorrentino
[import]uid: 9747 topic_id: 23275 reply_id: 111202[/import]
Just out of curiosity, why are you guys using the new API if it doesn’t do what you need?
It seems a bit unfortunate to switch to an admittedly (Ansca has been quite clear on this) unfinished API then bemoan that it isn’t finished, when there was no need to update in the first place.
I should point out that for now, literally the only 2 benefits to the new API are:
- Less confusing syntax
- Image group speed-ups (but with enough bugs to make them unusable for some people)
I should stress that second point - just using the new image sheets gives ZERO speed-up on its own. [import]uid: 46639 topic_id: 23275 reply_id: 111213[/import]
this is unfortunate. the new api and old api with its isVisible bug is not completely functional in the current build. [import]uid: 58777 topic_id: 23275 reply_id: 111216[/import]