gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Problem with spritemem (seems to wrap around 32kb)

#92957 - Valmond - Sat Jul 15, 2006 11:19 pm

Hi everybody !

I'v run into this problem, and after well a whole day of checking & controling
I thought it was maybe time to ask the experts :)
BTW, the code is run in Dualis and on a real DSlite.

Well, I have written this VRam manager for sprites, I "register" all images
I want to use (once) and every frame I ask it to draw sprites on screen.
If the image is loaded in VRAM it "draws" it with a sprite, otherwise
it loads it and then draws it (frees up non used mem and so on).
So the problem is that when I draws more than 32 different images, the
33:d shows up like the first one.
I use 32*32 256color sprites for testing so those 32 images should just eat 32kb out of the 128kb in bank B...

I use
vramSetBankB(VRAM_B_MAIN_SPRITE); // 128kb
but if I change to
vramSetBankF(VRAM_F_MAIN_SPRITE); // 64kb
then it wraps around on a 16kb boundary.

I have tried to disable the VRam manager, just write the first image
to the first 32*32byte space and so on, but this doesnt change anything.

I also tried to write everything 2048 bytes further up but it just eated up
two sprites... (they became invisible, like if I hadn't written anything to them)


So it is like i have a short somewhere that wraps around... but I don't :-(
(except that with VRAM_F, it wraps on 14 bits)

I'v checked my code quite much, the defines in libnds too :p
but I'm stuck.

Does Sprite mem have special behaviour or should I go back
continuing searching my code ?



thanks for the time :)

/Valmond

#92985 - Valmond - Sun Jul 16, 2006 8:51 am

After a good nights sleep, I found half of the problem :)

When I'm setting the OAM values, the "Tiles" seems to be 32 bytes
per step, and not 64 bytes which I thought would have been quite natural (64byte for a 256col 8x8pixel tile).

So the lines :
Code:
 spriteEntry[i].attribute[2]=((0*32)&1023)|(SpritePriority[i]<<10);
 spriteEntry[i].attribute[2]=((1*32)&1023)|(SpritePriority[i]<<10);

points at the first and second 32x32 256col sprite in VRAM.

this seems wierd, why would you need steps smaller than one "8x8 tile" ?
Is this for 4-bit graphics and/or can you somehow increase the size
of these steps as you can't have more than 1024 ?


Thanks again for reading my miseries :)

/Valmond

#93013 - tepples - Sun Jul 16, 2006 3:27 pm

Valmond wrote:
why would you need steps smaller than one "8x8 tile" ? Is this for 4-bit graphics

Yes.

Quote:
and/or can you somehow increase the size of these steps as you can't have more than 1024 ?

Yes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#93024 - Valmond - Sun Jul 16, 2006 4:11 pm

Got it, thanks !

Works like a charm now :D

/Valmond

#96962 - walaber - Mon Aug 07, 2006 12:34 am

I`m having the same problem... I know from the (informative) link above that I need to set bits 20-21 of DISP_CR so that I can setup a different step (and access more sprire memory)... but I'm not sure exactly how to do this.

is DISP_CR just BG0_CR in this case?

[edit]okay, i got it. DISPLAY_CR :)
_________________
Go Go Gadget NDS!