SpriteMapping layouts

[Sylus101]

(Had posted on dev-scene's forums but I'm not getting much help over there.)

I almost fully understand all of the elements from the SimpleSprite tutorial, except for one thing:The SpriteMapping_1D_32 enum that is passed to the oamInit() function. After reviewing a spot in patater's tutorial, I believe I understand the 1D vs 2D part where 1D is a linear feed of values that fill in the 8x8 sprite tiles, and I'm guessing 2D would be where the sprite array that would correspond to how the sprite would appear visually on screen.

What is the 32 byte (or more) boundary for?

[WinterMute]

On the GBA the sprite tile data is indexed by 16 color tiles - i.e. nibble per pixel or 8x8/2 = 32 bytes. For 256 color sprites each tile would consume 2 indices, thus halving the effective number of tiles.

The DS brought us extra VRAM and so the option to change the stride on the indexing was introduced to allow for more sprite tile data. We now have the ability to have the index offset into VRAM by 32,64,128 and 256 bytes which allows us to do interesting things with the start index of each sprite. A 64byte offset could be used for a 256 color 8x8 sprite which would allow us to use all 1024 indices rather than just the 512 even numbers on GBA. This could also be used for 8x16 or 16x8 16 color sprites.

[Sylus101]

I'm struggling a little bit to understand this, but I think I get the gist. I'll be using 256 color sprites of varying sizes mostly larger than 16X16. What would be a good default value for the boundary if I wasn't sure of the best way to maximize this option?

I suppose what I'm not understanding is whether this is a tile index or individual sprite object index. If the boundary were too small and I had a 32X32 sprite, would it be truncated? Overlap indices?

Okay, so I'm still a bit lost...

[dovoto]

1D vs 2D vs Tiled vs Bitmap:
There are 4 mapping modes on the DS for sprite graphics. Sprites graphics can be arranged as Bitmaps or as tiles, each of which can be 1D or 2D:

Tiled:
1D uses a linear "stack" of 8x8 tiles. Regardless of the color depth, the sprite graphics data is split into 8x8 pixel tiles and these tiles are arranged sequentially in memory. (this has nothing to do with the "boundary size"). If you have a 32x32 sprite it will stored as 16 8x8 tiles:

Code: Select all

 0  1  2  3
 4  5  6  7 
 8  9  10 11
12 13 14 15

In 2D mode graphics are still tiled but instead of the tiles being stored linearly they are stored more like:

Code: Select all

 0   1   2   3  4    5  ... 31
 32 33 34 35 36   37 ... 63
 64 65 66 67 68   68 ... 95
 96 97 98 99 100 101 ... 127

In 2D mode you would stick the first 4 tiles of your 32x32 tile sprite in tiles 0-3, the next 4 tiles would go in 32-35, the next four in 64-67, and the last in 96 through 99. 2D tile mode is something I never really got and you cannot change the boundary size which limits you to 32KB sprite memory in this mode.

Bitmap
In bitmap mode the graphics for each sprite are stored as a linear bitmap. 1D treats each sprite like its own linear bitmap where as 2D mode treats all of sprite memory like a 128 or 256 pixel wide bitmap. Only 16 bit color sprites are allowed in bitmap mode.

I honestly know of no use for 2D mapping in tile mode...in bitmap mode it might have some limited uses although the new sprite api cannot handle sprite graphics allocation in 2D mapping modes.

"Boundary size"
Boundary size is a poorly named term as it isn't a boundary at all. Its simply how the DS computes the offset into sprite graphics memory of the start of your sprite's graphics.

There are only 10 bits in each sprite's control register to specify where the graphics for a sprite begins.

10 bits gives us 1024 unique offsets into sprite graphics memory (2^10). The boundary size is simply how much we multiply this 10 bit offset by to specify the start of the sprite graphics (tiled or bitmaped, 2D or 1D). Because the boundary size specifies how fine of a grain your sprite graphics can be located in sprite graphics memory having a boundary size very big might leave empty holes if you have lots of small sprites. However, boundary size directly affects how much sprite graphics memory you can access:

A boundary size of 32 will allow you to address 32KB of vram (32bytes boundary * 1024 offsets), boundary size of 64 will allow 64KB of vram ect...

A good rule of thumb for picking the boundary size is to simply match it to the amount of vram you have allocated to sprites. If you have a 128KB vram bank allocated to sprite graphics using anything less than a boundary size of 128 will prevent you from accessing the entire bank for sprite graphics, anything more doesn't really get you anything either.

There are probably a few situations where this rule of thumb does not apply but none come to mind early in the morning.

[Sylus101]

Thanks dovoto, I believe I've finally got it. On to new ventures...

I suppose I may have a couple of other questions on the matter, but it's time to start applying and testing to see what I can do.