A fast, easy to use, free, and community supported 2D game engine
M2281
Member
What are the main differences between these two approaches, I was looking over the performance tests and they specify that an Atlas has the best performance, but there is no mention of a TileMap.
Which of the two is faster?
Do AtlasSprites have to be the same size like the TMX?
Ultimately we have large fast moving levels, and need performance.
bradparks
Member
Each "layer" in a TMXTileMap is derived from an AtlasSpriteManager.... So using a TMX tile map is basically using an AtlasSpriteManager/AtlasSprite approach...
The big difference with a tilemap approach is that you can have much larger levels than the max size of a single texture, since the texture(tilesheet) is loaded into memory once, and then used to build the scene as required... You can have really large levels easily....
M2281
Member
I was under the impression you could use AtlasSpriteManager in a similar manner to a TMXTileMap, without the map, in other words you would manually create each sprite and place it in the scene, so the only size limitation would be the 1024 max sheet size but the AtlasManager could be of any size?
BTW I just found the TMXLayer located in TMXTileMap.h should have caught that earlier.
-Thanks
M2281
Member
@Matt
Thanks for the info, looking at the Texture2D code it looks like a 100x50 would become 128x64.
Just out of curiosity
I wonder if this eats up a little more memory on the video card?
It also appears that the over size pix are probably just empty.
Anyone curious about this it happens around line 200 in Texture2D.m
M2281
Member
I would say there may be an advantage looking at the code, but it would depend on the size, we have chose to use power of 2 for all game tiles, whenever possible.
If someone more versed on openGL could chime in, I would love to know what the raw memory difference is for an image 128x128 vs 129x129?
The memory in the GPU is allocated in powers of 2. So 128x128 image would use the memory efficiently, while 129x129 would be taking up space in a 256x256 allocated memory space and hence waste about 3/4 of the space.
If you have some odd dimensions for images, combine them into a tightly packed image that fits a power of 2 image efficiently, then use AtlasSpriteManager and AtlasSprites to render them.
In regards to whether the wasted space would have an impact on performance, I have no idea. Need a Graphics/OpenGL guru to fill us in on that.
bradparks
Member
hey guys! I think we can all agree that the size of the image itself is important, and should be a power of 2 for both width and height.
What's still in contention is whether or not having an AtlasSprite of any size would have any negative performance implications...
From my basic understanding of AtlasSprites/AtlasSpriteManager, the entire spritesheet is in memory all the time, and AtlasSprites are simply copied to the display from the rect that it's defined from. Since the spritesheet itself is already in memory once, it doesn't cost any more memory to draw the same AtlasSprite 10 times or 20 times, since it's still in memory the one time....
Of course it'll still be slower to draw 20 sprites than 1, since that means more screen display has been changed, and thus the GPU has more work to do, but I don't think it costs any more memory....
Just to chime in here. It'll cost a little more memory on the heap due to the reallocation for new vertex points.
But we gain a sizeable speed benefit by reducing the amount of calls to the opengl pipeline.
So rather than a consecutive amount of glDrawArrays or glDrawElements. We batch up all our vertex data and do one call.
glDrawArrays/glDrawElements is more performance heavy than a reallocation of vertex data.
@bradparks: The AtlasSprite can be of any size. It can also be bigger than the texture (see tests/Texture2dTest.m).
To reduce memory, it's important that the texture (the .png file) has a size that is power of 2.
eg:
image.png with a size of 60x32 -> will be expanded to 64x32
image.png with a size of 200x100 -> will be expanded to 256x128
image.png with a size of 520x300 -> will be expanded to 1024x512 (<--- YOU ARE WASTING A LOT OF MEMORY!)
You must log in to post.
