OAM question

[njj]

Could somebody please educate me on why the following is true.

I'm trying to allocate 'n' (see below) number of sprites as follows: oamAllocateGfx(&oamMain, SpriteSize_32x32, SpriteColorFormat_256Color);

32*32 sprite is 1024 bytes should be able to allocate 128 of these from the VRAM, vramSetBankB(VRAM_B_MAIN_SPRITE_0x06400000);

During some experiments I have noticed the following when playing about with the "SpriteMapping" parameter of oamInit().

With SpriteMapping_1D_32 I can only allocate up to 32 sprites.
With SpriteMapping_1D_64 I can only allocate up to 64 sprites.
With SpriteMapping_1D_128 I can only allocate the full 128 sprites.

There is obviously something going on here I don't understand. Could anybody explain it?

Cheers...

[vuurrobin]

I dont really know what the offset boundary does (never really had the need to look into it), but you can find an explanation here:
http://forums.devkitpro.org/viewtopic.php?f=6&t=230

...

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.

...

I just follow that rule of thumb ._.

[WinterMute]

To start with you're confusing OAM entries with sprite graphics tiles - you can have 128 hardware sprites on screen simultaneously which can use the same tile data in any combination you like really. What you're talking about here is a set of 128 sprites, all set to 32x32, each with unique tile data.

The SpriteMapping settings are used to change the size of the tile data referenced by a single index, the number at the end of the defines refers to the number of bytes each index offsets into VRAM.

SpriteMapping_1D_32 offsets 32 bytes per index which is the size of a single 8x8 16 color tile. What this means is that with the default mapping you can only use the even indexes for 256 color tiles thus dropping the number of unique indexes to 512.

SpriteMapping_1D_64 offsets 64 bytes which will allow you to use all 1024 available indexes for 256 color tiles and will skip 2 tiles worth of 16 color data.

SpriteMapping_1D_128 & SpriteMapping_1D_256 skip 128 and 256 bytes respectively.

a 32x32 sprite will require 16 8x8 tiles worth of VRAM space, 1024 bytes as you say, which means you need 128k for 128 unique sprite images. For this you need to use at least a 128 byte stride - simple rule of thumb here, the maximum VRAM memory you can access is 1024 (max index) * stride (or boundary value if you prefer).

Using SpriteMapping_1D_128 you skip 128 bytes per index, corresponding to 4 16 color tiles or 2 256 color tiles. For your 32x32 sprites you would use 16/2 or every 8th index for each unique 32x32 image. With SpriteMapping_1D_256 this will be 16/4 or every 4th index.

[njj]

To vuurrobin & WinterMute.

OK, thanks, I now understand the interactions between these different settings. I guess before I wasn't thinking in the NDS way. i.e. everything is based on tiles....