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.