Search code examples
xnaxna-4.0

Disadvantage to very long Texture2D objects in XNA?


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!


Solution

  • 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.