Tilengine - The 2D retro graphics engine forum

Full Version: Sprite sheet design considerations?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I'm wondering what considerations should be made when choosing how to lay out your sprite sheets.

In a 3D engine, the bitmaps are loaded into texture memory, and if it's a spritesheet, you simply change the UV of your quad "sprite" to map to a different location in the sprite sheet, to change what "frame" it's showing.  But because it's using texture memory, it's most efficient to make sure your sprite sheet sizes are in powers of 2.  Then it would make sense to pick the smallest size you need for a particular sprite or type of sprites, and cram as much frames into that box as you can, to avoid having to jump up to the next power of 2.

But in this 2D engine, it may not work that way.  

If it's all up to me, then I would just have a separate sprite sheet for each different character.  Grouped that way, a character could re-use its own sprite frames, and there is no need to make one huge complicated sprite sheet with every character on it, getting lost in which character animations start at which index. 

The only consideration I can think of is for drawing out your map in Tiled map editor.  The sprite sheet should contain every tile in the map, so you can paint with one tileset while making a level, and maybe have different "themes", so you can make it a snow level just by switching sprite sheets, and all the grass would now have snow on it, etc.

Are there any other considerations I should make? Is there any resource saving by packing more sprites into one sheet?  Making sheets of a certain size?  Perhaps the palette of the 8-bit .png file is of importance, eg. would there be some reason to group them by what palette they use...
Tilengine is software based, so there aren't penalties about the number of sheets or set dimensions. By the way, the limitation of needing power of two textures was abandoned long time ago. OpenGL 2.0 and later requires compatible hardware to support NPOT textures (non power of two):
https://www.khronos.org/opengl/wiki/NPOT_Texture

Regarding spritesheets, it's up to your management habits. I tend to put all the frames of each character in its own spritesheet. All frames share the same 8-bit palette, of course.

Tilesets should be grouped in a way that allows you to build an entire layer with just one tileset. Tiled editor allows you to have a single layer built with various tilesets at once, but tilengine allows just one active tileset per layer. But a single tileset can be used in different levels with the same theme. For example think about the Sonic levels. The first three levels (Green Hill Zone) have the same theme but different layout. So you'd have a single tileset used in three tilemaps (one per level).
Regarding non-power of two & 3D engines, my understanding is they will load it, but they will simply waste memory by loading them into the next power of two memory size up that fits... eg. a 64x65 texture will be loaded into a 128x128 memory space. So you still want to obey the restriction when optimising.

Ah you echoed my current thoughts about how I will approach spritesheet / tileset management. It's basically up to you to group them the way that suits your development Smile
AFAIK non power of two textures were introduced to prevent the waste of space and/or image rescaling associated with classic textures. But I'm not a chipset designer so I can't tell you first hand how they're implemented, but just what the system exposes. In any case, in tilengine there isn't any kind of memory or performance penalty for using arbitrary sized bitmaps, for sure!