More moving sprites means sluggish performance?
by Steve D · in Torque Game Builder · 02/26/2010 (6:25 am) · 11 replies
Hi everyone, I'm wondering if TGB has any limits in relation to the number of sprites moving around on the level causing laggy performance? Right now for a single level I have a tile map (1000x1000 in size, 10 units per square) with probably close to 1000 stationary sprites for scenery, they don't move or do anything for that matter.
With about 12 sprites moving around on the level (some of them are not on camera), they are moving by the SetMoveForward command with no updates or logic running, performance seems fine with no issues.
When I bump that up to 20 sprites, the scene is jittery and the mouse is sluggish, even the moving sprites are skipping a bit.
Can anyone shed any light or give me any information? Does a lot of movement in TGB slow the engine down?
With about 12 sprites moving around on the level (some of them are not on camera), they are moving by the SetMoveForward command with no updates or logic running, performance seems fine with no issues.
When I bump that up to 20 sprites, the scene is jittery and the mouse is sluggish, even the moving sprites are skipping a bit.
Can anyone shed any light or give me any information? Does a lot of movement in TGB slow the engine down?
#3
If moving 20 sprites around was performance hungry then TGB would be useless. Being as you've got a lot of sprites in your level including a tile-map with *1 million tiles* then you don't need to do much wrong to get performance glitches. Also, if your tile-map has more than 1 layer then it'll have n-million more tiles.
As Michael suggests, have a look at the debug banner to see if anything odd is happening, which it must be.
02/26/2010 (10:08 am)
TGB offers no limits unless you factor in a specific hardware configuration you/your users are using which is the same for most things.If moving 20 sprites around was performance hungry then TGB would be useless. Being as you've got a lot of sprites in your level including a tile-map with *1 million tiles* then you don't need to do much wrong to get performance glitches. Also, if your tile-map has more than 1 layer then it'll have n-million more tiles.
As Michael suggests, have a look at the debug banner to see if anything odd is happening, which it must be.
#4
If you're showing some big sprites (or big source images scaled down to small on-screen site) then you may become fillrate limited on the GPU.
There's also an issue we ran into and fixed related to adding t2dSceneObject instances to the scene. This is a particular issue if you have a bunch of sprites. Adding new objects to the scene becomes progressively slower. Doesn't sound like what you're describing though.
steve
02/26/2010 (12:02 pm)
I've had success with thousands of sprites active at once. FPS is good. Of course, those are pretty small sprites.If you're showing some big sprites (or big source images scaled down to small on-screen site) then you may become fillrate limited on the GPU.
There's also an issue we ran into and fixed related to adding t2dSceneObject instances to the scene. This is a particular issue if you have a bunch of sprites. Adding new objects to the scene becomes progressively slower. Doesn't sound like what you're describing though.
steve
#5
Melv, I didn't word the tile map description very well. What I meant to say was it's 1000x1000 in total size, 100 squares going across and down.
I am not using OnUpdate calls at all so I can't figure out what I'm doing wrong here. Also, which I forgot to mention in my first post, on each sprite I have about 10 triggers mounted to each sprite, would that make a difference at all?
Here is a link to the screen capture. I admit I am not up to speed with all this information so if anyone can look at it and tell me if there are any obvious problems I would be grateful!! For this example I took out a lot of the static sprites I was using and I even shrunk the tile map to see if that would make a difference but with 20 sprites moving around I still see them "jittering" a bit.
http://www.blackwatergames.com/roadwars/screen.png
02/26/2010 (1:03 pm)
Hi guys, thanks for the various responses, it's appreciated!Melv, I didn't word the tile map description very well. What I meant to say was it's 1000x1000 in total size, 100 squares going across and down.
I am not using OnUpdate calls at all so I can't figure out what I'm doing wrong here. Also, which I forgot to mention in my first post, on each sprite I have about 10 triggers mounted to each sprite, would that make a difference at all?
Here is a link to the screen capture. I admit I am not up to speed with all this information so if anyone can look at it and tell me if there are any obvious problems I would be grateful!! For this example I took out a lot of the static sprites I was using and I even shrunk the tile map to see if that would make a difference but with 20 sprites moving around I still see them "jittering" a bit.
http://www.blackwatergames.com/roadwars/screen.png
#6
You're only rendering 24 objects in that view (PotRender/ActRender) so that's irrelevant. Also the moving objects are not causing bin-relocations (BinReloc) so again, that's irrelevant.
If you have lots of sprites tthat don't move then they don't need to be sending collisions. Turn sending collisions off and all those collision checks will go away. Make sure they have receive collisions on so that objects that do send still collide with them. Only make the objects that move send and potentially receive collisions.
If you want some background on collision-detect in TGB I would suggest reading the following document that explains it in detail.
Collision Detection & Response
02/26/2010 (1:16 pm)
Per-frame you've got 5817 potential collisions (PotCol) resulting in no actual collisions (ActCol) which is a huge waste of CPU time. That results in 9452 bin-collision checks (BinCollis) with a maximum of 9691 being seen. You're showing a total of 2130 collision contacts in progress. That's seriously huge.You're only rendering 24 objects in that view (PotRender/ActRender) so that's irrelevant. Also the moving objects are not causing bin-relocations (BinReloc) so again, that's irrelevant.
If you have lots of sprites tthat don't move then they don't need to be sending collisions. Turn sending collisions off and all those collision checks will go away. Make sure they have receive collisions on so that objects that do send still collide with them. Only make the objects that move send and potentially receive collisions.
If you want some background on collision-detect in TGB I would suggest reading the following document that explains it in detail.
Collision Detection & Response
#7
02/26/2010 (1:22 pm)
Thanks for the insight Melv, I will do that and I will read that document. As I mentioned, I have about 8 to 10 triggers mounted to each vehicle, for navigation, fire control, etc. What would be causing the huge numbers you mentioned and cpu overhead? Because outside of the 20 vehicles and those triggers I honestly don't have much else in the level.
#8
When you say you don't have much else in the level you did say you had 1000 sprites. It's these that should not be sending collisions.
02/26/2010 (1:29 pm)
Triggers send collisions although having 8-10 on each vehicle sounds like overkill but of course I don't know what you're doing. They are much more expensive than just using a scene-object and processing callbacks.When you say you don't have much else in the level you did say you had 1000 sprites. It's these that should not be sending collisions.
#9
But all of this has helped, I am now certain it's something with my work and not TGB so just have to figure it out!
02/26/2010 (1:31 pm)
Thanks, I actually turned off those sprites and the results are in the screenshot.But all of this has helped, I am now certain it's something with my work and not TGB so just have to figure it out!
#10
02/26/2010 (1:46 pm)
Also! I just reduced the size of those mounted triggers and sure enough the PotCol number has been reduced and the visual performance clearly has improved! So now I know what direction I need to go on and at least I know the cause, thanks!
#11
Good luck.
02/26/2010 (2:11 pm)
Yeah, there's nothing worse than stuff happening and you don't know why. That's why I wrote the debug-banner to give you some idea of which sub-system is causing problems. Even so, those values in the debug banner don't necessarily mean anything bad on any one system but you do get a sense of what is too high or what is just a waste.Good luck.
Torque Owner Steven Hine
Also, if there are a lot of echo calls to the command console for debugging, that would effect performance.
I don't know how you are updating these sprites, but grouping them and updating them together instead of one at a time may help.