Time Moves Faster in Graphics 2.0

Solar2D General Questions/Discussion
#1

Hi all,

I’m finishing up migrating Doggins to Graphics 2.0 so that I can submit an update to Apple, and after dealing with the minor issues (removal of setReferencePoint, changes to setFillColor, etc), I’m nearly done. However, when I tested on my iPad this morning, I noticed a problem with one of my sprites.

Here’s what’s happening: I have a sprite that plays through a 74 frame animation sequence. I’m running at the Corona default of 30 fps, which means that it should take 2.467 seconds to play the sequence (roughly 2500ms). I have a timer that destroys the sprite after 2500ms, which should be right after the animation finishes. Under Graphics 1.0, this worked perfectly on both simulator and device. Under Graphics 2.0, this works in the simulator, but on my iPad the sprite is destroyed after only 47 frames of animation. I increased the timer to 2750ms, and while the sprite gets further now (maybe around 60 frames of animation), it’s still unable to finish. Again, waiting 2500ms worked on both the simulator and device under Graphics 1.0.

I’ve noticed other small timing differences with my game running under Graphics 2.0; things just feel slightly faster or different. But while most of those cases don’t affect usability, the issue above is breaking my game.

Anyone have any idea what is happening? Why would this be different from Graphics 1.0 to Graphics 2.0?

Thanks,

  • David
#2

Hi David,

I’m not sure the about the internal reasons behind this, but because of the potential room for error/inconsistency with frame rates and timers and devices, I don’t think you should be using a timer to “assume” that a sprite animation will finish after a specific time. Instead, you should implement (and should have in your 1.0 version) a sprite listener that gets triggered when the animation finishes. This way you’ll know that the animation has successfully finished and you can take the proper action to destroy it.

Brent

#3

Hi Brent,

While I agree with you that it’s not a great way to go about it (and I am using a sprite listener, albeit for a different reason), my problem is that my originally coded solution worked. It worked through several versions of Corona, several released updates to my game, and on iPads ranging from iPad 1 to iPad Air. It wasn’t until the Graphics 2.0 update that it broke, and it’s frustrating to not know why.

The most plausible thing I can think of is that Graphics 2.0 is actually slower, and thus it’s taking longer to load, display, and animate my sprite than it used to, causing the timer to still fire after 2500ms, despite the animation not being complete. But I don’t understand why it would be slower. The only other idea I have is that timers now run faster (which may explain some of the other odd behavior I’m seeing), but that doesn’t really make sense.

Thanks for the help,

  • David
#4

When Graphics 2.0 was first released, most of my projects ran slower than on g1.0.  

That was a while ago and I would assume some optimisation has been done since then, but it’s possible that it is running slower for you too. Have you tried printing the time between frames in an enterFrame listener and see if it increases in g2.0?

#5

@AlanPlantPot: I haven’t tried that, that’s an interesting idea. Thanks!

In the meantime, I’ve changed my methodology in this situation, but I’m still worried about the rest of my game, which uses timers for all sorts of things.

#6

Hi David,

I’m not sure the about the internal reasons behind this, but because of the potential room for error/inconsistency with frame rates and timers and devices, I don’t think you should be using a timer to “assume” that a sprite animation will finish after a specific time. Instead, you should implement (and should have in your 1.0 version) a sprite listener that gets triggered when the animation finishes. This way you’ll know that the animation has successfully finished and you can take the proper action to destroy it.

Brent

#7

Hi Brent,

While I agree with you that it’s not a great way to go about it (and I am using a sprite listener, albeit for a different reason), my problem is that my originally coded solution worked. It worked through several versions of Corona, several released updates to my game, and on iPads ranging from iPad 1 to iPad Air. It wasn’t until the Graphics 2.0 update that it broke, and it’s frustrating to not know why.

The most plausible thing I can think of is that Graphics 2.0 is actually slower, and thus it’s taking longer to load, display, and animate my sprite than it used to, causing the timer to still fire after 2500ms, despite the animation not being complete. But I don’t understand why it would be slower. The only other idea I have is that timers now run faster (which may explain some of the other odd behavior I’m seeing), but that doesn’t really make sense.

Thanks for the help,

  • David
#8

When Graphics 2.0 was first released, most of my projects ran slower than on g1.0.  

That was a while ago and I would assume some optimisation has been done since then, but it’s possible that it is running slower for you too. Have you tried printing the time between frames in an enterFrame listener and see if it increases in g2.0?

#9

@AlanPlantPot: I haven’t tried that, that’s an interesting idea. Thanks!

In the meantime, I’ve changed my methodology in this situation, but I’m still worried about the rest of my game, which uses timers for all sorts of things.