Max Sprite Count
by John Cooney · in Torque Game Builder · 11/06/2005 (10:10 am) · 7 replies
I'm trying to build an Isometric engine for T2D. I've got a 30x30 grid of fxStaticSprite2D objects, which I use as ground tiles. If I try to make that number much higher (say 64x64 or 128x128) I get serious framerate issues, despite the fact that the sprites aren't on screen.
I hope I'm not asking something that's already been covered, but what's the maximum number of fxStaticSprite2D objects that T2D can handle?
Failing that, I created just the 30x30, and set them to rearrange themselves under the camera so that the same 30x30 tiles would always be under the camera (but with different textures, to simulate a larger map). To do that, I had to make an update function that rearranges the tiles as the camera moves.
Unfortunately, if I keep the camera moving, I will very quickly get hitching in the map, and it will even stop updating until I stop the camera. Is there some huge penalty for the fxStaticSprite2D setPosition function?
I hope I'm not asking something that's already been covered, but what's the maximum number of fxStaticSprite2D objects that T2D can handle?
Failing that, I created just the 30x30, and set them to rearrange themselves under the camera so that the same 30x30 tiles would always be under the camera (but with different textures, to simulate a larger map). To do that, I had to make an update function that rearranges the tiles as the camera moves.
Unfortunately, if I keep the camera moving, I will very quickly get hitching in the map, and it will even stop updating until I stop the camera. Is there some huge penalty for the fxStaticSprite2D setPosition function?
#2
That said, 128 x 128 is a whopping 16,384 sprite objects and if you've got physics enabled (and even if you don't) the overhead of the sprite object might just be too much to have all those in memory at once. I do know that it has been demonstrated that the coming 1.1 release has some optimizations in this area (Melv had a plan with a screen busting at the edges with scores of animated, physic-enabled sprites) so perhaps that will help.
Then again, it might just be better implemented the way you have already worked around this issue by re-using the same subset of tiles, or perhaps instead of shuffling them around you could destroy those that get beyond a certain distance from the camera center (and create new ones as you approach) since sprite construction/destruction is fairly efficient.
EDIT: Ah, Melv's quicker on the draw than I. :)
11/06/2005 (11:54 am)
I don't know what theoretical or hard limits exist (and I'm sure the former at least depends greatly on the hardware you run it on), but one thing you might look at is the bin settings. You can see how efficient the binning is by turning on the debug window (t2dSceneGraph.setDebugOn(255) will turn on all debug features) and then adjust the binning to more efficiently handle your particular implementation. You can do this via the fxSceneGraph2D.initialise() call.That said, 128 x 128 is a whopping 16,384 sprite objects and if you've got physics enabled (and even if you don't) the overhead of the sprite object might just be too much to have all those in memory at once. I do know that it has been demonstrated that the coming 1.1 release has some optimizations in this area (Melv had a plan with a screen busting at the edges with scores of animated, physic-enabled sprites) so perhaps that will help.
Then again, it might just be better implemented the way you have already worked around this issue by re-using the same subset of tiles, or perhaps instead of shuffling them around you could destroy those that get beyond a certain distance from the camera center (and create new ones as you approach) since sprite construction/destruction is fairly efficient.
EDIT: Ah, Melv's quicker on the draw than I. :)
#3
Even if they're 32-bits for the X,Y, and ID, that's 12 bytes per tile, or 196k for 128x128. The only reason that it would be too difficult to manipulate that big a structure would be if there's a lot more overhead to using a fxStaticSprite2D. So I guess my question is, "Is there a more basic object that can be used to render a sprite?"
I've read both the ISO resources, and I notice that they both had to alter the engine to make it run (without giving us code to show it). So, I'm getting the message here that T2D out of the box, just can't do it. I mean, if I'm going to get into the engine, why not just create a single full-screen sprite, and alter the texture that it uses once per frame? That way, I can use all the code that's worked on systems as far back as the 486.
I'm not trying to sound snarky here, but is 900 polygons REALLY that much? In the 3D Torque engine, I've got character models with three times that many polys.
11/06/2005 (1:44 pm)
I guess my problem is that I've made Iso engines in several different formats before (I've even done PocketPC handhelds, now that's limited). But I've never had this much trouble coming up with a tile system before. I realize that 128x128 is a lot of sprites, but we're talking about sprites here! You store a bitmap ID, an X and a Y, and you're done. Even if they're 32-bits for the X,Y, and ID, that's 12 bytes per tile, or 196k for 128x128. The only reason that it would be too difficult to manipulate that big a structure would be if there's a lot more overhead to using a fxStaticSprite2D. So I guess my question is, "Is there a more basic object that can be used to render a sprite?"
I've read both the ISO resources, and I notice that they both had to alter the engine to make it run (without giving us code to show it). So, I'm getting the message here that T2D out of the box, just can't do it. I mean, if I'm going to get into the engine, why not just create a single full-screen sprite, and alter the texture that it uses once per frame? That way, I can use all the code that's worked on systems as far back as the 486.
I'm not trying to sound snarky here, but is 900 polygons REALLY that much? In the 3D Torque engine, I've got character models with three times that many polys.
#4
You are correct, off-the-shelf 1.02 is not designed to provide isometric support. I don't recall anything that leads me to believe 1.1 will provide it either (though some things I've heard will make it easier to implement as an extension). I'm not sure that isometric functionality is even hinted at either in the marketing materials or the docs, so this shouldn't be too much of a surprise. That said, it wouldn't be a tremendous effort to strip down or re-purpose the tile object or fxStaticSprite2D object to be much leaner and use them the way you're looking to.
It comes down to using the right feature for the job; in 3D Torque a DTS might have 2700 polies, but is every polygon an encapsulated sub-object individually and entirely responsible for its own collision, rendering and physics? That's kind of the whole parallel picture here if drawn all the way out.
11/06/2005 (2:01 pm)
900 polygons is a pittance. 900 (or 5,000 or 16,000...) fxStaticSprite2D objects however, is a different story. fxStaticSprite2D is not just a bit-bag for bitmap ID and X/Y coords. As Melv said, what you're describing is more of a tile object (which doesn't carry the weight of a physics implementation and other script-heavy support stuff).You are correct, off-the-shelf 1.02 is not designed to provide isometric support. I don't recall anything that leads me to believe 1.1 will provide it either (though some things I've heard will make it easier to implement as an extension). I'm not sure that isometric functionality is even hinted at either in the marketing materials or the docs, so this shouldn't be too much of a surprise. That said, it wouldn't be a tremendous effort to strip down or re-purpose the tile object or fxStaticSprite2D object to be much leaner and use them the way you're looking to.
It comes down to using the right feature for the job; in 3D Torque a DTS might have 2700 polies, but is every polygon an encapsulated sub-object individually and entirely responsible for its own collision, rendering and physics? That's kind of the whole parallel picture here if drawn all the way out.
#5
Thanks for your help, guys.
11/06/2005 (2:16 pm)
Okay, well, I'll see if I can get the tile objects to do this. I'd really like to do it without engine changes, because I want the system to be portable to new T2D engines.Thanks for your help, guys.
#6
11/06/2005 (2:20 pm)
@JohnQuote:I've read both the ISO resources, and I notice that they both had to alter the engine to make it run (without giving us code to show it).T2D isometric tile rendering and picking in C++
Associate Melv May
I will say though that you're going about this the wrong way. Real tiles are normally lightweight, low-overhead objects and don't really exist in their own right. That's why you can render buckets of them without a problem. Static-sprites have a much higher overhead (particularly in v1.0.2) and you cannot really use them for tiles nor would you want to; they're too "fat"! It's kinda like cracking a nut with an elephant; well perhaps a rhino.
When you start to go to 64x64 or 128x128 you're obviously creating 4096 or 16,384 sprites just for ground tiles.
These threads may be of use...
T2D ISO#1
T2D ISO#2
- Melv.