Tiling textures in a composite sprite?
by Jonathan Brockman · in Torque 2D Beginner · 10/24/2014 (7:00 am) · 5 replies
Hey all.
I'm working on a game that includes a procedurally generated 2d tile map. I'm using composite sprites for this, and after load, it works well. The problem is the load time is extremely slow, and I'm hoping to improve this.
The default map size is 200 x 200, 1 meter tiles. that means 40000 sprites. I was hoping to combine sprites into single larger sprites, for instance 1 2x200 sprite for a road instead of 400 1x1 sprites. However, for that to work sprite textures would need to tile. I can't find a way to make this work.
Is it doable? Is this way going to increase starting performance?
I'm working on a game that includes a procedurally generated 2d tile map. I'm using composite sprites for this, and after load, it works well. The problem is the load time is extremely slow, and I'm hoping to improve this.
The default map size is 200 x 200, 1 meter tiles. that means 40000 sprites. I was hoping to combine sprites into single larger sprites, for instance 1 2x200 sprite for a road instead of 400 1x1 sprites. However, for that to work sprite textures would need to tile. I can't find a way to make this work.
Is it doable? Is this way going to increase starting performance?
#2
You could even just create a simObject with a function that creates the desired composite sprite from its own taml, or something like that. this way only the composite sprites that you are going to be using will be created.
Just starting out with torque so sorry if this is completely wrong.
10/25/2014 (6:14 am)
I might be wrong here, and sorry if my language isn't quite right, but couldn't you create a simSet with taml that contains all the possible composite sprites as children? Then have a function in the simSet to retrieve or copy whichever composite sprite you want. You could even just create a simObject with a function that creates the desired composite sprite from its own taml, or something like that. this way only the composite sprites that you are going to be using will be created.
Just starting out with torque so sorry if this is completely wrong.
#3
SpriteBatch - an object that manages a collection of SpriteBatchItem objects.
SpriteBatchItem - a single "sprite" inside of the CompositeSprite.
With this in mind, you don't want to create a list of individual SpriteBatchItems - in fact, I think you'd have to modify the engine to allow you to do so. The individual images are already tracked by the resource management system.
I'm unclear from the original poster's stated issue ("The problem is the load time is extremely slow, and I'm hoping to improve this.") whether he's generating the map at load, or if he's generated the map, saved it and is loading the CompositeSprite object from TAML. My initial suggestion is to generate once (for a new game) and save the CompositeSprite to TAML, then load it with the rest of the scene content. Unless you're just splattering random tiles all over I think procedurally generating the map is taking up a bit of time. If you can skip this step at level load you should see a noticeable time savings.
10/25/2014 (8:40 am)
CompositeSprite - Single SceneObject that manages a SpriteBatch object.SpriteBatch - an object that manages a collection of SpriteBatchItem objects.
SpriteBatchItem - a single "sprite" inside of the CompositeSprite.
With this in mind, you don't want to create a list of individual SpriteBatchItems - in fact, I think you'd have to modify the engine to allow you to do so. The individual images are already tracked by the resource management system.
I'm unclear from the original poster's stated issue ("The problem is the load time is extremely slow, and I'm hoping to improve this.") whether he's generating the map at load, or if he's generated the map, saved it and is loading the CompositeSprite object from TAML. My initial suggestion is to generate once (for a new game) and save the CompositeSprite to TAML, then load it with the rest of the scene content. Unless you're just splattering random tiles all over I think procedurally generating the map is taking up a bit of time. If you can skip this step at level load you should see a noticeable time savings.
#4
I do like the idea of building single images out of chunks as well. I may investigate that avenue at some point in the future.
Cheeers!
10/27/2014 (5:12 am)
Thanks for the replies all. World Generation itself is actually pretty quick, its really the adding all the sprites that is taking the time. That said, even if I can't cut a road down to a single sprite, there are still optimizations I can do that should help. I do like the idea of building single images out of chunks as well. I may investigate that avenue at some point in the future.
Cheeers!
#5
10/27/2014 (6:18 am)
Have you tried multiple CompositeSprites - build 100x100 chunks and arrange those? It may be that the monolithic approach is causing the issue. 
Torque Owner Richard Ranft
Roostertail Games
Have you tried saving out the generated composite sprite and then loading it to see if it makes any difference? I'm guessing you don't want to procedurally create your map every time you load a game (just when starting a new game) so you'll want to do that anyway sooner or later.
Additionally, you could theoretically add a system to the engine that would allow you to generate a single image for the whole map, or to just take 100x100 sprite chunks and create images for those, then create a new composite sprite using the larger chunks instead of the smaller images. Again, this might work well with a save/load game system.
Hope that helps point you in the right direction!