I’d like to understand a bit more what impacts FPS dramatically in Corona. How much do these factors impact the FPS rate and what else, besides these, has an impact?
Anyone? I’ve tried to find documentation on this but can’t… [import]uid: 135391 topic_id: 34936 reply_id: 139059[/import]
To put things simply: the amount of “things you do” affects the framerate, while the amount of “things you have” in your app affects memory. In extreme cases of course things change, but you can forget about that in a lot of cases.
Using texture memory should not slow down the app - until you run up against the absolute limit where the system will begin work to hard in the background to free up memory, and you might notice a slowdown. Once again, this last scenario is pretty rare in most cases.
Graphics on screen are drawn by the GPU, so this shouldn’t affect your framerate too much. Again, yes, there is also an overhead on the CPU for every object, but this is in most cases negligeable.
So, lots of textures, no problem for the framerate. Many objects on screen, not that much of a problem for the framerate until you start running into over a hundred images, let’s say, for an iPhone 4 or iPad. Once again, I’m oversimplifying. Older builds or deprecated sprite code will runs worse than the newer sprite code using imageGroups, because it reduces the amount of OpenGL calls. Google this for more info.
So, what you “have” does not affect the framerate too much in most cases.
Now, what you “do” affects the framerate most: this includes animations, transitions and most of all the code you execute. Code you put in your enterFrame is the most crucial. This loop needs to execute 30 or 60 times per second - this means you have about 33 (at 30fps) or 16 (at 60fps) milliseconds. If you put too much code your enterFrame loop it will take longer than 33 or 16 milliseconds and your framerate will drop under 30 or 60fps.
Loading a texture is also “doing” something so this affects the framerate. Loading a sound also affects the framerate negatively, because loading is “doing” something. Once the sound is loaded it is something you “have” in your app, so it uses memory but does not affect framerate too much. Playing a sound on the other is “doing” something, so it will drop the framerate a tiny bit. Streaming audio is a tricky one: streaming means the processor is continually decoding your audio, so “doing” something.
In short: firstly, the most important thing is to keep the logic in your enterFrame event (and to a lesser degree other events) as lean as possible, secondly, minimize or even better, completely avoid loading sounds or graphics during gameplay. Thirdly, having lots of images just sitting on the screen will still be fast with the newer builds, but once you start using code to move a lot of images, you could feel a performance hit.
Does that about answer your question? [import]uid: 70134 topic_id: 34936 reply_id: 139088[/import]
Thanks, that’s very helpful. It also appears the that complexity of physics shapes used on sprites dramatically affects FPS, too. [import]uid: 135391 topic_id: 34936 reply_id: 139186[/import]
Yes, because calculating physics and checking for collision is “doing” something, even if it’s not your code but the Box2D coding running. So the heavier the physics (in number or in complexity) the slower the framerate.
There are almost always intelligent ways to lower the calculations needed by writing code that turns of physics or other calculations for objects that are off screen or unimportant or uncritical for other reasons. For instance, I have a lot games where my first calculation is always “how close am I to the camera”. If an object is on screen or close to the edges off the screen (but outside it) the rest of the code for this object runs. If it is sufficiently off screen I do nothing with these objects. [import]uid: 70134 topic_id: 34936 reply_id: 139217[/import]
Anyone? I’ve tried to find documentation on this but can’t… [import]uid: 135391 topic_id: 34936 reply_id: 139059[/import]
To put things simply: the amount of “things you do” affects the framerate, while the amount of “things you have” in your app affects memory. In extreme cases of course things change, but you can forget about that in a lot of cases.
Using texture memory should not slow down the app - until you run up against the absolute limit where the system will begin work to hard in the background to free up memory, and you might notice a slowdown. Once again, this last scenario is pretty rare in most cases.
Graphics on screen are drawn by the GPU, so this shouldn’t affect your framerate too much. Again, yes, there is also an overhead on the CPU for every object, but this is in most cases negligeable.
So, lots of textures, no problem for the framerate. Many objects on screen, not that much of a problem for the framerate until you start running into over a hundred images, let’s say, for an iPhone 4 or iPad. Once again, I’m oversimplifying. Older builds or deprecated sprite code will runs worse than the newer sprite code using imageGroups, because it reduces the amount of OpenGL calls. Google this for more info.
So, what you “have” does not affect the framerate too much in most cases.
Now, what you “do” affects the framerate most: this includes animations, transitions and most of all the code you execute. Code you put in your enterFrame is the most crucial. This loop needs to execute 30 or 60 times per second - this means you have about 33 (at 30fps) or 16 (at 60fps) milliseconds. If you put too much code your enterFrame loop it will take longer than 33 or 16 milliseconds and your framerate will drop under 30 or 60fps.
Loading a texture is also “doing” something so this affects the framerate. Loading a sound also affects the framerate negatively, because loading is “doing” something. Once the sound is loaded it is something you “have” in your app, so it uses memory but does not affect framerate too much. Playing a sound on the other is “doing” something, so it will drop the framerate a tiny bit. Streaming audio is a tricky one: streaming means the processor is continually decoding your audio, so “doing” something.
In short: firstly, the most important thing is to keep the logic in your enterFrame event (and to a lesser degree other events) as lean as possible, secondly, minimize or even better, completely avoid loading sounds or graphics during gameplay. Thirdly, having lots of images just sitting on the screen will still be fast with the newer builds, but once you start using code to move a lot of images, you could feel a performance hit.
Does that about answer your question? [import]uid: 70134 topic_id: 34936 reply_id: 139088[/import]
Thanks, that’s very helpful. It also appears the that complexity of physics shapes used on sprites dramatically affects FPS, too. [import]uid: 135391 topic_id: 34936 reply_id: 139186[/import]
Yes, because calculating physics and checking for collision is “doing” something, even if it’s not your code but the Box2D coding running. So the heavier the physics (in number or in complexity) the slower the framerate.
There are almost always intelligent ways to lower the calculations needed by writing code that turns of physics or other calculations for objects that are off screen or unimportant or uncritical for other reasons. For instance, I have a lot games where my first calculation is always “how close am I to the camera”. If an object is on screen or close to the edges off the screen (but outside it) the rest of the code for this object runs. If it is sufficiently off screen I do nothing with these objects. [import]uid: 70134 topic_id: 34936 reply_id: 139217[/import]
Another question about FPS on the iPad 3: I am getting dramatically different FPS on different devices. Most devices seem fine (55+ FPS), but my FPS is dropping down to 35-45 FPS on some game levels on the iPad 3. Why would that be and how should I address correcting it? [import]uid: 135391 topic_id: 34936 reply_id: 140392[/import]
I was reusing my old config.lua and it had antialias = true declared. I think if it defaults to false now if not declared.
Anyways, I spent weeks struggling to find what was causing my framerate to drop from 60 FPS to 30 FPS when I “replaced” my device build onto my device.
On a “clean” load of the build, where I first deleted the app and then loaded the new build, the game would play at a smooth 60 FPS, but when I either rebooted the device or “replaced” the build, the FPS would instantly drop to 30.
From my experience, I would never set antialias to true ever again.
I thought I’d pass on this ugly experience.
Nail [import]uid: 106779 topic_id: 34936 reply_id: 140401[/import]
Hi Nate2,
I can’t say for sure, but different devices (of the same model) could have different results for several reasons, e.g. because of apps running in the background. So an iPad 3 running only 2 apps in the background might run faster than an iPad 3 running 10 apps in the background. You don’t notice this in the lighter level, but the more complex ones might reveal this issue.
I’m not saying this is the case, and I’ve never had this happen to me, but this could be a reason. Mind you, if you’re getting slowdowns on an iPad 3 (with it’s blazing fast processor) I think you’re doing something wrong somewhere in your coding (meaning it’s not optimal) - or you might just have to accept that the app you’re making is just too much for mobile devices at the moment.
p.s. I don’t mean to offend you, but my hunch is you should optimize your code. [import]uid: 70134 topic_id: 34936 reply_id: 140403[/import]
Another question about FPS on the iPad 3: I am getting dramatically different FPS on different devices. Most devices seem fine (55+ FPS), but my FPS is dropping down to 35-45 FPS on some game levels on the iPad 3. Why would that be and how should I address correcting it? [import]uid: 135391 topic_id: 34936 reply_id: 140392[/import]
I was reusing my old config.lua and it had antialias = true declared. I think if it defaults to false now if not declared.
Anyways, I spent weeks struggling to find what was causing my framerate to drop from 60 FPS to 30 FPS when I “replaced” my device build onto my device.
On a “clean” load of the build, where I first deleted the app and then loaded the new build, the game would play at a smooth 60 FPS, but when I either rebooted the device or “replaced” the build, the FPS would instantly drop to 30.
From my experience, I would never set antialias to true ever again.
I thought I’d pass on this ugly experience.
Nail [import]uid: 106779 topic_id: 34936 reply_id: 140401[/import]
Hi Nate2,
I can’t say for sure, but different devices (of the same model) could have different results for several reasons, e.g. because of apps running in the background. So an iPad 3 running only 2 apps in the background might run faster than an iPad 3 running 10 apps in the background. You don’t notice this in the lighter level, but the more complex ones might reveal this issue.
I’m not saying this is the case, and I’ve never had this happen to me, but this could be a reason. Mind you, if you’re getting slowdowns on an iPad 3 (with it’s blazing fast processor) I think you’re doing something wrong somewhere in your coding (meaning it’s not optimal) - or you might just have to accept that the app you’re making is just too much for mobile devices at the moment.
p.s. I don’t mean to offend you, but my hunch is you should optimize your code. [import]uid: 70134 topic_id: 34936 reply_id: 140403[/import]