FPS and performance observations
by Stamatios Sarris · in iTorque 2D · 12/18/2009 (11:32 am) · 8 replies
Hi,
We have progressed quite a bit in our game.
I was experimenting and snooping around to
see what kind of performance we are getting.
Under normal circumstances the fps is around 28 to 31
as displayed by the function metrics(fps);.
The motion appears to be jerky, a little bit more
when the metric is displayed, a little less when it is not.
OK.
While intentionally adding performance killers
the fps got as low as 19, but the overall appearance didn't
change at all. As i have read in other threads it appears that
the iPhone refreshes the screen at 15fps when its load is
equivalent to something from 15 fps to 29.99 fps. At 30 fps and
above the motion of the sprites is less jerky (but not perfect)
indicating a 30 fps drawing.
When i removed the background (which is a t2dStaticSprite with a
480x320 png) the fps went above 60fps and the motion was smooth
as silk . (i believe that the iPhone was actually updating at
60 fps at that time). While on that state the actual frame rate
varies (i believe depending on what the background tasks do).
When above 60fps everything is perfect (naturally ...) when below
(even at 59 fps) the jerky movement returns.
All that on an iPhone 2g and the beta 1.3 iTGB without anything
disabled, with collisions on and everything on script.
I plan to start chopping soon and will post the results.
Has anyone noticed something similar when dealing with large pictures ?
I have downloaded the Defense Net game and the motion is flawless there.
Hope that if i slim the engine as much as possible i will be able to
get things much better...
We have progressed quite a bit in our game.
I was experimenting and snooping around to
see what kind of performance we are getting.
Under normal circumstances the fps is around 28 to 31
as displayed by the function metrics(fps);.
The motion appears to be jerky, a little bit more
when the metric is displayed, a little less when it is not.
OK.
While intentionally adding performance killers
the fps got as low as 19, but the overall appearance didn't
change at all. As i have read in other threads it appears that
the iPhone refreshes the screen at 15fps when its load is
equivalent to something from 15 fps to 29.99 fps. At 30 fps and
above the motion of the sprites is less jerky (but not perfect)
indicating a 30 fps drawing.
When i removed the background (which is a t2dStaticSprite with a
480x320 png) the fps went above 60fps and the motion was smooth
as silk . (i believe that the iPhone was actually updating at
60 fps at that time). While on that state the actual frame rate
varies (i believe depending on what the background tasks do).
When above 60fps everything is perfect (naturally ...) when below
(even at 59 fps) the jerky movement returns.
All that on an iPhone 2g and the beta 1.3 iTGB without anything
disabled, with collisions on and everything on script.
I plan to start chopping soon and will post the results.
Has anyone noticed something similar when dealing with large pictures ?
I have downloaded the Defense Net game and the motion is flawless there.
Hope that if i slim the engine as much as possible i will be able to
get things much better...
#2
My objects are less than 1/2 screen (all inclusive, with the text objects and all, but without the background) so i should have plenty of fill rate left for each frame out of the four screen sizes you mention...
Defense Net, which uses iTGB (congrats guys), has a full background image, a tileMap with many tiles and the motion is almost perfect (some times the missiles jerk a tiny bit), in the very same iPhone i use ...
12/18/2009 (12:24 pm)
Something is not going too well then. My objects are less than 1/2 screen (all inclusive, with the text objects and all, but without the background) so i should have plenty of fill rate left for each frame out of the four screen sizes you mention...
Defense Net, which uses iTGB (congrats guys), has a full background image, a tileMap with many tiles and the motion is almost perfect (some times the missiles jerk a tiny bit), in the very same iPhone i use ...
#3
I've got a 1024x1024 image (PNG) for all my sprites, plus a 512x512 background (PVR), and a 512x512 track (PVR), and the game runs at about 47 FPS on a 2nd gen iPod Touch.
12/18/2009 (1:46 pm)
Converting your background to a power-of-2 square PVR with "optimised" set in the datablock will improve your performance.I've got a 1024x1024 image (PNG) for all my sprites, plus a 512x512 background (PVR), and a 512x512 track (PVR), and the game runs at about 47 FPS on a 2nd gen iPod Touch.
#4
on a 3Gs the frame rate is a ridiculously high 62fps (double from a jailborken 2g and absolutely smooth)
on an ipod Touch 2g the frame rate is 50 - 52 (jerks a bit but much better than the 2g)
Again with no optimisations and nothing left out of iTGB.
VERY IMPORTANT NOTE !!!!
if you are shopping for an iPod Touch 3G (late 09 as called by apple),
which sports the latest (iphone 3gs class) hardware, for personal or development use,
DO NOT BUY THE 8GB MODEL
although packaged and sold as iPod Touch 3G it is NOT!!!!!
It is simply a repackaged 2g ipod touch with iphone 2g and 3g equivalent internals.
ONLY THE 32GB and 64GB iPod Touch have the new fast internals...
12/21/2009 (7:29 am)
Haven't tested the compressed textures yet, but as a side note :on a 3Gs the frame rate is a ridiculously high 62fps (double from a jailborken 2g and absolutely smooth)
on an ipod Touch 2g the frame rate is 50 - 52 (jerks a bit but much better than the 2g)
Again with no optimisations and nothing left out of iTGB.
VERY IMPORTANT NOTE !!!!
if you are shopping for an iPod Touch 3G (late 09 as called by apple),
which sports the latest (iphone 3gs class) hardware, for personal or development use,
DO NOT BUY THE 8GB MODEL
although packaged and sold as iPod Touch 3G it is NOT!!!!!
It is simply a repackaged 2g ipod touch with iphone 2g and 3g equivalent internals.
ONLY THE 32GB and 64GB iPod Touch have the new fast internals...
#5
Neither the 2nd gen itouch nor the 3GS class devices are suited for any usefull testing at all, especially not for iTGB thats CPU capped, not gpu capped.
What runs at 60 FPS on the 3GS will barly run at stable 24FPS on a the 1st generation devices and the iphone 3G and that is defacto a massive part of the market.
Also, due to the phone services, itouch of a generation are commonly faster and more stable than the iphones of the same generation.
12/21/2009 (8:36 am)
if you are a dev and buy either for the purpose of testing its basically a dead end bad idea.Neither the 2nd gen itouch nor the 3GS class devices are suited for any usefull testing at all, especially not for iTGB thats CPU capped, not gpu capped.
What runs at 60 FPS on the 3GS will barly run at stable 24FPS on a the 1st generation devices and the iphone 3G and that is defacto a massive part of the market.
Also, due to the phone services, itouch of a generation are commonly faster and more stable than the iphones of the same generation.
#6
we mostly agree ...
Yes iPods are much faster than the same class iPhone.
As said above 32 -> 52 fps from iphone to ipod on the same hardware class.
Yes the iPhone 2g/3g is the vast majority of users, and that platform sucks.
But i wouldn't ever ship something that claims compatibility with a product without testing it on the actual product... I truly don't trust apple, so i have one of everything my product is supposed to run on and do actual testing. From my first app (and on every other occasion) my choice was proved to be right, both from OS side and from hardware side. (for example accelerometer and sound have slightly different behavior between OS versions and some things timed for 2g/3g iphone where completely out of sequence on the 3gs due to sloppy programming from my part)
a bit irrelevant but possibly note worthy:
iTGB might be cpu limited but the iphone 2g/3g is also seriously gpu limited. For example removing the background of our app DOUBLES the fps on that platform. Or removing 1/4 of the screen worth in transparencies gives 4fps and MUCH smoother animation (and this i believe has nothing to do with the CPU).
Ah ! and another thing.
Saving pngs with transparency on when it is not needed has an fps penalty. When i changed the background image to a version not saved with transparency on i got an extra 2fps.
Naturally the graphic artist was shot. :-)
12/21/2009 (9:52 am)
@Marcwe mostly agree ...
Yes iPods are much faster than the same class iPhone.
As said above 32 -> 52 fps from iphone to ipod on the same hardware class.
Yes the iPhone 2g/3g is the vast majority of users, and that platform sucks.
But i wouldn't ever ship something that claims compatibility with a product without testing it on the actual product... I truly don't trust apple, so i have one of everything my product is supposed to run on and do actual testing. From my first app (and on every other occasion) my choice was proved to be right, both from OS side and from hardware side. (for example accelerometer and sound have slightly different behavior between OS versions and some things timed for 2g/3g iphone where completely out of sequence on the 3gs due to sloppy programming from my part)
a bit irrelevant but possibly note worthy:
iTGB might be cpu limited but the iphone 2g/3g is also seriously gpu limited. For example removing the background of our app DOUBLES the fps on that platform. Or removing 1/4 of the screen worth in transparencies gives 4fps and MUCH smoother animation (and this i believe has nothing to do with the CPU).
Ah ! and another thing.
Saving pngs with transparency on when it is not needed has an fps penalty. When i changed the background image to a version not saved with transparency on i got an extra 2fps.
Naturally the graphic artist was shot. :-)
#7
http://imageoptim.pornel.net/
Maybe 16-bit or 15-bit with alpha can help a little, too.
12/21/2009 (11:33 am)
I haven't tried the tools here yet, but one makes indexed images:http://imageoptim.pornel.net/
Maybe 16-bit or 15-bit with alpha can help a little, too.
#8
No need to create them outside.
Indexed images are of no use, they aren't supported.
@stamatios: right, those devices themself would be gpu limited. But fact is that the iTGB code is written in a way that will never get the gpu usage over 70% without the use of significantly oversized images / fullscreen backdrops, not even on an itouch 1st generation. it will run into the cpu border much before that point commonly
thats whats meant by capped. The capping part is the one that will lead to the ultimate maximum and thats the cpu, because if the cpu is at 100%, the whole engine will joke.
to get a gpu capped game, you basically only have one possibility and thats not iTGB related but a designer error, because that possibility is overflooding the fillrate. In that case the things you mentioned actually make a difference, just because they get you into the available fillrate again (on the pre 3GS, you can basically draw the fullscreensize 4-6 times per frame to get fluent fps. go above that and it will joke and die down significantly)
thats the reason why pvr are so important.
Use a twice as high and twice as wide 4bpp pvr compressed texture and you still only use half as much memory, have the same quality and commonly a quite better performance.
12/22/2009 (12:40 am)
You could enforce going 16bit png straight through iTGB and XCode.No need to create them outside.
Indexed images are of no use, they aren't supported.
@stamatios: right, those devices themself would be gpu limited. But fact is that the iTGB code is written in a way that will never get the gpu usage over 70% without the use of significantly oversized images / fullscreen backdrops, not even on an itouch 1st generation. it will run into the cpu border much before that point commonly
thats whats meant by capped. The capping part is the one that will lead to the ultimate maximum and thats the cpu, because if the cpu is at 100%, the whole engine will joke.
to get a gpu capped game, you basically only have one possibility and thats not iTGB related but a designer error, because that possibility is overflooding the fillrate. In that case the things you mentioned actually make a difference, just because they get you into the available fillrate again (on the pre 3GS, you can basically draw the fullscreensize 4-6 times per frame to get fluent fps. go above that and it will joke and die down significantly)
thats the reason why pvr are so important.
Use a twice as high and twice as wide 4bpp pvr compressed texture and you still only use half as much memory, have the same quality and commonly a quite better performance.
Torque 3D Owner Marc Dreamora Schaerer
Gayasoft
On the pre 3GS devices, the rules of thumb is that you have a fillrate of 4-5 times the screen.
so if you waste already the fillrate of a whole screen just for the background image, it should definitely have an important function, assuming that it isn't a less realtime action oriented gameplay