I am using a Texture2D object as a tilesheet. It's one-dimensional- one tile tall and however many tiles long.
I'm just curious if there's any disadvantage (Aside from being more difficult to edit, I guess) to having them laid out like this as opposed to a more compact way, e.g. instead of 64x1 tiles, make it 16x16. It wouldn't be very hard to change it, but I figure why bother if there's no hurt in having a long image!
The only real disadvantage is that you'll hit the maximum width (2048 on the Reach
profile, 4096 on HiDef
) of the texture with fewer sprites.
This isn't really a problem because, when it happens, it's so trivial to add support for more rows.
Seeing as you've asked the question, there is one obscure, performance-related thing that is at least interesting to be aware of, even though you almost never need to worry about it.
A texture's pixel data is stored in CPU memory in a row-by-row order. So if your tiles are stored horizontally, you try and read or write the pixels for a single tile (ie: GetData
and SetData
), you will be accessing many small, spread-out sections of memory. If you stored your tiles vertically, then each tile would occupy a single large section of memory - this has better cache coherency and can be copied with fewer operations (ie: it's faster).
This is not a problem on the GPU, where textures are stored with a layout such that all nearby pixels (not just the ones to the left and right) are stored nearby in memory.