Perf stress tests on TGB (aka T2D) ???
by Jason Swearingen · in Torque Game Builder · 02/13/2006 (9:01 pm) · 9 replies
I was wondering if anyone else has taken the time to write some perf tests for TGB.
The last tests I ran, using the 1.1a1 bits, was still pretty bad (though better than 1.0.2)
by "bad" i mean aprox 500 static sprites on the screen was causing considerable lag.
has anyone done these tests with the newer beta?
The last tests I ran, using the 1.1a1 bits, was still pretty bad (though better than 1.0.2)
by "bad" i mean aprox 500 static sprites on the screen was causing considerable lag.
has anyone done these tests with the newer beta?
#2
the size of the sprite didnt seem to matter that much, though with super-super-small sprites i was able to get maybe 100 more sprites on the screen before lag out.
and for testing the lag, I just used the scroller-demo player, with the arrow key bindings. I moved it around on the screen. When i get in the area of 500 sprites, that's when i start to notice big lag/chunking in the movement of the player sprite. (again, no physics or collisions)
If there were a lightweight rendering, that would be really, really great, as it would solve pretty much all the concerns around performance that I have.
02/14/2006 (12:11 pm)
I turned off physics and collisions, and they dont move. (they are generated at random spots on the screen)the size of the sprite didnt seem to matter that much, though with super-super-small sprites i was able to get maybe 100 more sprites on the screen before lag out.
and for testing the lag, I just used the scroller-demo player, with the arrow key bindings. I moved it around on the screen. When i get in the area of 500 sprites, that's when i start to notice big lag/chunking in the movement of the player sprite. (again, no physics or collisions)
If there were a lightweight rendering, that would be really, really great, as it would solve pretty much all the concerns around performance that I have.
#3
- the sprites did have world limits set (though they wernt moving)
- no debug flags were turned on
- computer is a 3.4ghz p4 w 1gb ram, using an agp ati fire gl video card with 128mb ram.
- lag is when everything is static, except for the one "player" i mentioned, and moving that around the screen starts getting slow and choppy, that is my definition of "lag" (the player sprite is on a layer above the others, no collisions, etc)
--------------------------------------
- sprites needed: good question. This is my estimation for a 'high end 2d game':
an isometric tile based tactics game.
board size of 50x75 tiles = 3750 sprites
assuming we give a 3d layout, with 5 layers total, each layer above layer 1 maxing out at 25% density, would mean an extra 3750 sprites for layer 2 to 5.
total sprites needed for tiles:: 7500
assuming that the total number of objects (players, npcs, trees, etc) on the play field would be 1 per tile, that would be 3750 objects on the board.
assuming each object is made out of at most 7 sprites (mount points, person example: head, body, legs, arms, weapon, shield, feet. . . . tree example: base, trunk, branch1, branch2, leaf 1, leaf2, crown)
total sprites needed for objects: 26250
total sprites needed with "no lag": 33750 sprites
---------------------
so before you say NO WAY! this is obviously an extreme example, but one showing that these types of graphical capabilities could be used in a very practical way.
and yes, there are obvious hurdles to managing that many sprites both in the engine and in your game.
For me, it is a piece of cake to manage that number of sprites efficently in the game... so that leads me to the concern of the engine performance. if i can find a use for 33750 sprites, you can see how I am concerned that I get lagged out when i have only 500 sprites on the screen.
----------------------
edit:
a bit more practical example would be
isometric tactics game:
board size: 15x20, 5 layers, assume layer 1 is max capacity, layer 2-5 is 25% capacity = 15*20+(15*20*.25*4) = 15*20*2= 600 sprites for tiles
again using the assumption of 1 object per tile, and each object with 7 sprites (via mount points) that means 15*20*7 = 2100 sprites for objects
that means 2700 sprites total
I think that is a pretty good practical bar for a high-end computer.. ??
---------
plus of course, various particle effects, etc.
02/14/2006 (4:25 pm)
I forgot to answer your other questions:- the sprites did have world limits set (though they wernt moving)
- no debug flags were turned on
- computer is a 3.4ghz p4 w 1gb ram, using an agp ati fire gl video card with 128mb ram.
- lag is when everything is static, except for the one "player" i mentioned, and moving that around the screen starts getting slow and choppy, that is my definition of "lag" (the player sprite is on a layer above the others, no collisions, etc)
--------------------------------------
- sprites needed: good question. This is my estimation for a 'high end 2d game':
an isometric tile based tactics game.
board size of 50x75 tiles = 3750 sprites
assuming we give a 3d layout, with 5 layers total, each layer above layer 1 maxing out at 25% density, would mean an extra 3750 sprites for layer 2 to 5.
total sprites needed for tiles:: 7500
assuming that the total number of objects (players, npcs, trees, etc) on the play field would be 1 per tile, that would be 3750 objects on the board.
assuming each object is made out of at most 7 sprites (mount points, person example: head, body, legs, arms, weapon, shield, feet. . . . tree example: base, trunk, branch1, branch2, leaf 1, leaf2, crown)
total sprites needed for objects: 26250
total sprites needed with "no lag": 33750 sprites
---------------------
so before you say NO WAY! this is obviously an extreme example, but one showing that these types of graphical capabilities could be used in a very practical way.
and yes, there are obvious hurdles to managing that many sprites both in the engine and in your game.
For me, it is a piece of cake to manage that number of sprites efficently in the game... so that leads me to the concern of the engine performance. if i can find a use for 33750 sprites, you can see how I am concerned that I get lagged out when i have only 500 sprites on the screen.
----------------------
edit:
a bit more practical example would be
isometric tactics game:
board size: 15x20, 5 layers, assume layer 1 is max capacity, layer 2-5 is 25% capacity = 15*20+(15*20*.25*4) = 15*20*2= 600 sprites for tiles
again using the assumption of 1 object per tile, and each object with 7 sprites (via mount points) that means 15*20*7 = 2100 sprites for objects
that means 2700 sprites total
I think that is a pretty good practical bar for a high-end computer.. ??
---------
plus of course, various particle effects, etc.
#4
That sounds like a pretty good indication that this is a vertex processing bottleneck. However, since vertex processing is quite fast, it then sounds like either a state/texture change issue or a vertex transfer issue. But, since you're only transfering 500*4 vertices, that one seems rather unlikely. That leaves us with state changes.
Now, you may want to consider this: your hardware is a FireGL. That is a workstation-class card, and it uses different drivers from the standard Radeon drivers most gamers use. Workstation cards are used for very different things than game-quality cards; therefore, the drivers are optimized differently. The most aggregious thing that T2D does is texture swapping (a form of state change).
As Melv pointed out, T2D isn't optimized. So, there may be some fairly unfortunate things happenning under the hood with regard to changing textures and so forth. It might not be a bad idea to install GLIntercept and watch how many of what kinds of calls happen when T2D is running.
02/14/2006 (5:13 pm)
Quote:the size of the sprite didnt seem to matter that much, though with super-super-small sprites i was able to get maybe 100 more sprites on the screen before lag out.
That sounds like a pretty good indication that this is a vertex processing bottleneck. However, since vertex processing is quite fast, it then sounds like either a state/texture change issue or a vertex transfer issue. But, since you're only transfering 500*4 vertices, that one seems rather unlikely. That leaves us with state changes.
Now, you may want to consider this: your hardware is a FireGL. That is a workstation-class card, and it uses different drivers from the standard Radeon drivers most gamers use. Workstation cards are used for very different things than game-quality cards; therefore, the drivers are optimized differently. The most aggregious thing that T2D does is texture swapping (a form of state change).
As Melv pointed out, T2D isn't optimized. So, there may be some fairly unfortunate things happenning under the hood with regard to changing textures and so forth. It might not be a bad idea to install GLIntercept and watch how many of what kinds of calls happen when T2D is running.
#5
My confusion here (and perhaps I just haven't understood what you're doing) is why you'd use static-sprites for what seems to be the job of lightweight tiles.
To me that seems like the equivalence of using static sprites to render letters in a T2D word-processor.
Surely sprites would be used for characters and decals, not as substitutes for tiles in any game.
Have I misunderstood?
- Melv.
02/15/2006 (5:19 am)
Jason,My confusion here (and perhaps I just haven't understood what you're doing) is why you'd use static-sprites for what seems to be the job of lightweight tiles.
To me that seems like the equivalence of using static sprites to render letters in a T2D word-processor.
Surely sprites would be used for characters and decals, not as substitutes for tiles in any game.
Have I misunderstood?
- Melv.
#6
It's a rendering performance test. It's a test to see how T2D renders large numbers of sprites. Numbers that could be achieved in game situations by liberal use of particle systems and other effects.
02/15/2006 (12:36 pm)
Quote:My confusion here (and perhaps I just haven't understood what you're doing) is why you'd use static-sprites for what seems to be the job of lightweight tiles.
It's a rendering performance test. It's a test to see how T2D renders large numbers of sprites. Numbers that could be achieved in game situations by liberal use of particle systems and other effects.
#7
however for objects, that can/do move around on the board as characters, those cant really be tilesets.
so using my "practial iso game" example, I would do 600 sprites as tiles, but there are still the 2100 odd object sprites that I would want.
maybe i'm missing something here.. i didnt think that t2d tiles can be moved around arbitraily, am i wrong?
02/15/2006 (1:25 pm)
@Melv: for the tiles, then yes i could use the lightweight t2d tiles.however for objects, that can/do move around on the board as characters, those cant really be tilesets.
so using my "practial iso game" example, I would do 600 sprites as tiles, but there are still the 2100 odd object sprites that I would want.
maybe i'm missing something here.. i didnt think that t2d tiles can be moved around arbitraily, am i wrong?
#8
@Jason:
What I was referring to was the usage of "heavier" objects like sprites for typical "lightweight" tasks such as tiles. Sledgehammer to crack a nut and all that or in other words, the right tool for the right job. The tile-layers we use are not "sprites" for good reason; you don't want the processing bulk that comes with them; this is the reason why I'm interested in the cited example, that's all. I'm not questioning the fact that you need thousands of sprites ever, just that the example seems a little squewed.
I guess if you want to specify how many "sprites" that TGB can "render" then there's a need to clarify what exactly these "sprites" are doing. If you want worst-case, with them doing everything they can, then you can use that figure or you can turn everything off and use that one, your choice.
One of the things that was mentioned was that the sprites all had the "world limits" on. This'll make a big difference. For instance, what was the broad-phase bin-container size set to? (can be configured for each scenegraph) This can make an almost exponential effect when you start creating thousands of sprites, especially if they're moving, using world-limits or even worse, using the collision-detection system.
A really nice way to do this is to setup your test, whatever that might be and turn on the profiler. This will give you a damn good idea of what CPU work is going on. With the numbers that are being talked about; all it takes is one thing on that you didn't want and it all goes horribly wrong.
Either way, as I mentioned previously, we've got plenty of render-layer work to do (and other major improvements) which will address many of these issues but there are still many other performance improvements to be made and made they will be.
I'm actually travelling to GG in two weeks to discuss TGB and the future work we've got planned. :)
- Melv.
02/15/2006 (1:45 pm)
@Smaug: No offense but I'd have to be a bit daft not to understand the basic idea here. ;)@Jason:
What I was referring to was the usage of "heavier" objects like sprites for typical "lightweight" tasks such as tiles. Sledgehammer to crack a nut and all that or in other words, the right tool for the right job. The tile-layers we use are not "sprites" for good reason; you don't want the processing bulk that comes with them; this is the reason why I'm interested in the cited example, that's all. I'm not questioning the fact that you need thousands of sprites ever, just that the example seems a little squewed.
I guess if you want to specify how many "sprites" that TGB can "render" then there's a need to clarify what exactly these "sprites" are doing. If you want worst-case, with them doing everything they can, then you can use that figure or you can turn everything off and use that one, your choice.
One of the things that was mentioned was that the sprites all had the "world limits" on. This'll make a big difference. For instance, what was the broad-phase bin-container size set to? (can be configured for each scenegraph) This can make an almost exponential effect when you start creating thousands of sprites, especially if they're moving, using world-limits or even worse, using the collision-detection system.
A really nice way to do this is to setup your test, whatever that might be and turn on the profiler. This will give you a damn good idea of what CPU work is going on. With the numbers that are being talked about; all it takes is one thing on that you didn't want and it all goes horribly wrong.
Either way, as I mentioned previously, we've got plenty of render-layer work to do (and other major improvements) which will address many of these issues but there are still many other performance improvements to be made and made they will be.
I'm actually travelling to GG in two weeks to discuss TGB and the future work we've got planned. :)
- Melv.
#9
You can use active-tiles to do whatever you want although without understanding exactly what you wanted to do, I couldn't say whether you'd be best to use an active-tile or preferably a much more lightweight object than the static-sprite.
One of the downsides to TGB at the moment is the bulky inheritance from t2dSceneObject. Moving to a more component-based design is something that we're looking at. Simply creating a lightweight object that can be added to the scene without bringing along to the party the rest of the capabilities is something I'm keen to get working.
Ignoring the testing above for a minute, it does sound like TGB doesn't provide a light-enough stock object for your needs at this point.
- Melv.
02/15/2006 (1:53 pm)
*missed your post* :)You can use active-tiles to do whatever you want although without understanding exactly what you wanted to do, I couldn't say whether you'd be best to use an active-tile or preferably a much more lightweight object than the static-sprite.
One of the downsides to TGB at the moment is the bulky inheritance from t2dSceneObject. Moving to a more component-based design is something that we're looking at. Simply creating a lightweight object that can be added to the scene without bringing along to the party the rest of the capabilities is something I'm keen to get working.
Ignoring the testing above for a minute, it does sound like TGB doesn't provide a light-enough stock object for your needs at this point.
- Melv.
Associate Melv May
Are the sprites not moving or rotating?
Do they have all the collisions turn-off?
Do they have any world-limits set?
Is the debug-info being drawn for each sprite? e..g b/box etc (slow!)
What is considerable "lag"?
What is the computer spec?
How many sprites (of the above configuration) is acceptable to make games? e.g. what is the "pass" rate?
I'm wondering if TGB is being compared to some tech-demos for 2D engines that draw 5000 sprites or more using a VBO or some other construct. I can write an object that would do the same if lightweight rendering was all that was required. Even if just a simple position/bounce-movement was required.
Since the alpha releases, I put in place many "dirty" checks so that processing wasn't done when key features were not used such as the object not moving/rotation etc. This had a huge impact on the performance.
One thing to try would be to swap the static-sprites for t2dSceneObjects and look at the difference. This would at least remove the rendering side of things from the equation.
I'm trying my best not to sounds defensive here because, well, I'm not. :) There are obvious improvements we'll be making but just to let you know, the later alphas and betas have not focused on squeezing every bit of performance we can out of TGB but rather improving the support/stability of the product.
We've got major plans for the evolution of TGB. These are not for the v1.1 release though.
- Melv.