Ideas on how to boost Engine Efficiency
by Daniel Liverance · in iTorque 2D · 10/19/2011 (12:31 pm) · 15 replies
Hello,
I am currently working on a big project and I have stumbled upon a problem.
I have a lot of static sprites, and I realize that there is a limit for the number of sprites that can be on the screen at any given time. I was just wondering if anyone knows of ANY performance boosting tricks that I can use.
I currently have about 20 sprites on the screen that each have 6 other sprites mounted to them, and I can only get 30 fps with just them moving onscreen slowly.
I used the Torque Profiler and found that 50 % of the time is being spent in the T2D_t2dSceneGraph_integrateObject with 40% being spent in T2D_t2dSceneObject_updateMount
I then changed it so that nothing is "mounted", I just set the position of every sprite to be where it would have been mounted anyways, but this only brought the T2D_t2dSceneObject_updateMount down to 30%.
I have already turned off physics for all sprites in the game completely, and I set the positions manually. I have also set setCollisionActive(false, false) and setCollisionPhysics(false, false);
I am doing all of this in C++ so I am open to completely hacking the crap out of the engine to give me any more fps.
any suggestions would be appreciated.
Also, this is a problem with the CPU being a bottleneck, not the GPU. I have tested this extensively, and I just needed to know if there are any more tricks for CPU performance in the iTorque Engine.
Thanks a lot.
I am currently working on a big project and I have stumbled upon a problem.
I have a lot of static sprites, and I realize that there is a limit for the number of sprites that can be on the screen at any given time. I was just wondering if anyone knows of ANY performance boosting tricks that I can use.
I currently have about 20 sprites on the screen that each have 6 other sprites mounted to them, and I can only get 30 fps with just them moving onscreen slowly.
I used the Torque Profiler and found that 50 % of the time is being spent in the T2D_t2dSceneGraph_integrateObject with 40% being spent in T2D_t2dSceneObject_updateMount
I then changed it so that nothing is "mounted", I just set the position of every sprite to be where it would have been mounted anyways, but this only brought the T2D_t2dSceneObject_updateMount down to 30%.
I have already turned off physics for all sprites in the game completely, and I set the positions manually. I have also set setCollisionActive(false, false) and setCollisionPhysics(false, false);
I am doing all of this in C++ so I am open to completely hacking the crap out of the engine to give me any more fps.
any suggestions would be appreciated.
Also, this is a problem with the CPU being a bottleneck, not the GPU. I have tested this extensively, and I just needed to know if there are any more tricks for CPU performance in the iTorque Engine.
Thanks a lot.
About the author
I am 21 years old, and have just recently graduated from College for Game Programming (with honours) and I am now the Lead Programmer at Blinker Studios.
#2
10/19/2011 (1:24 pm)
these stats are from my iPhone 4 
#3
One thing we did do to improve performance was to force 16bit for all our sprites.
10/19/2011 (1:59 pm)
Problem is the iPhone4 is a bit limited in performance terms (as is iPad1). We actually get better performance on 3GS compared to iPhone4.One thing we did do to improve performance was to force 16bit for all our sprites.
#4
Dude, I started doing tests yesterday and the two major things I noticed are size, size of sprite, a bigger sprite demands more memory and the number of them. As soon as I pass 30 sprites, no matter the size, the engine suffers. So you are working with 6x20, which is 120!!!
Having said that, 30fps is not too bad.
I would suggest, pooling, streamlining, taking some of the rendering requirements you have, out of the game.
Also, what scott mentioned, I believe what bit rate you save your sprite at effects performance too. For some reason (and I may be wrong) but I believe that 16bit is better than 8bit, in terms of engine efficiency.
10/19/2011 (2:00 pm)
So wait, you currently have 20 sprites that are all using physics (setLinearVelcoity for example) at one time? TIMES the 6 sprites mounted to each??!Dude, I started doing tests yesterday and the two major things I noticed are size, size of sprite, a bigger sprite demands more memory and the number of them. As soon as I pass 30 sprites, no matter the size, the engine suffers. So you are working with 6x20, which is 120!!!
Having said that, 30fps is not too bad.
I would suggest, pooling, streamlining, taking some of the rendering requirements you have, out of the game.
Also, what scott mentioned, I believe what bit rate you save your sprite at effects performance too. For some reason (and I may be wrong) but I believe that 16bit is better than 8bit, in terms of engine efficiency.
#5
The iPhone 4 isn't quite powerful enough for games using Retina Display, almost but not quite (at least for the iTorque Engine).
I have Retina Display disabled for this game, Just so everyone knows.
10/19/2011 (2:12 pm)
I can't really say much because I have not had a 3GS to test on but I just can't wrap my head around the 3GS performing better than the 4. UNLESS the iPhone4 is using Retina Display, that would make sense.The iPhone 4 isn't quite powerful enough for games using Retina Display, almost but not quite (at least for the iTorque Engine).
I have Retina Display disabled for this game, Just so everyone knows.
#6
I was using physics on all 20 sprites, but I changed it so that I set the positions manually, which helped a bit.
Also the size is very small, the maximum size I am using is 62 x 117 pixels, for IPad resolution, so its actually about 26 x 49 (approximately) on my iPhone.
also I forgot to mention previously: I will try the 16 bit images as well to see if this boosts performance.
10/19/2011 (2:18 pm)
@rennieI was using physics on all 20 sprites, but I changed it so that I set the positions manually, which helped a bit.
Also the size is very small, the maximum size I am using is 62 x 117 pixels, for IPad resolution, so its actually about 26 x 49 (approximately) on my iPhone.
also I forgot to mention previously: I will try the 16 bit images as well to see if this boosts performance.
#7
10/19/2011 (3:03 pm)
hmm. well those are the things I noticed that do the most damage. For instance, I am building a large side scroller. I laid all the elements out and began monitoring the fps. When the level was large in size, physically plus all the added elements, enemies and projectiles that fps was very much effected. Shrinking the size of the level physically, without removing any other element, just switching the size from say 10000x 10000y to 100x and 100y, helped boost fps. then, removing elements of course further helped. All things like physics, calculate mass, collisions, all will effect memory.
#9
no I can't make the screen resolution any less, but you can decide to make the IOS View either 960 x 640 to make use of the Retina Display or keep the window size at 480 x 320 that will be stretched to 960 x 640 and will alleviate the stress from the GPU's fragment shader. IE it only goes over 1/4 the amount of pixels when you use the smaller window size.
10/19/2011 (4:30 pm)
@Ronnyno I can't make the screen resolution any less, but you can decide to make the IOS View either 960 x 640 to make use of the Retina Display or keep the window size at 480 x 320 that will be stretched to 960 x 640 and will alleviate the stress from the GPU's fragment shader. IE it only goes over 1/4 the amount of pixels when you use the smaller window size.
#10
I just noticed... I removed a second gui (hud) and gained on average 10fps. so from 30 to 40.
10/19/2011 (6:11 pm)
also, just to add...I just noticed... I removed a second gui (hud) and gained on average 10fps. so from 30 to 40.
#11
10/19/2011 (6:20 pm)
Try turning off blending and use Alpha Test to get transparency on your sprites, that should be quicker (although it will result in a hard outline).
#12
Actually using Alpha Test would make it go a lot slower.
Alpha test bypasses a lot of the GPU's optimizations, and actually you should use blending in stead of alpha test if you want to increase performance.
Good idea though.
10/19/2011 (6:40 pm)
@ConorActually using Alpha Test would make it go a lot slower.
Alpha test bypasses a lot of the GPU's optimizations, and actually you should use blending in stead of alpha test if you want to increase performance.
Good idea though.
#13
10/19/2011 (8:15 pm)
There's not much getting around the scene graph's integrate function. It's too core. A different approach is to find other areas where the CPU is being consumed and start whittling those down.
#14
with out having any idea where to look for those things, where or what type of clue would you give me? What type of file, and what type of vars etc?
10/19/2011 (10:10 pm)
@Michael, with out having any idea where to look for those things, where or what type of clue would you give me? What type of file, and what type of vars etc?
#15
there is a profiler in Torque:
www.garagegames.com/community/forums/viewthread/106929
10/19/2011 (10:33 pm)
@renniethere is a profiler in Torque:
www.garagegames.com/community/forums/viewthread/106929
Torque Owner Scott Wilson-Billing
MeYuMe