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.

Coding > Help with sprite and background

#111584 - Vengyr - Fri Dec 08, 2006 1:03 am

I'm trying to get a double background. One thats pretty much static that maybe scrolls a little. And one that is actually the map you play on. I know you need several backgrounds to be able ro realize this.

But for some reason I can't get a double background to work. And after that I will get a second problem wich I already have with one background right now...

I can't seem to get a sprite and a background on my screen. I already tried to logical or the BG1_ENABLE with it. But still it will only show the sprite. Could anyone please help me.

Here are my header files and the code I have thus far
source

#111598 - DiscoStew - Fri Dec 08, 2006 4:52 am

From the source, I see you trying to set Mode 2, which is 2 affine backgrounds. Note however, that these 2 backgrounds for this mode are BG2 and BG3, so whatever you do with the other 2 backgrounds, BG0 and BG1, nothing will happen. Other than that, you need to set up those backgrounds.

One thing you'd should do, imo, is update the headers that you have. There are headers out there that show a lot more of what's available.
_________________
DS - It's all about DiscoStew

#111605 - Vengyr - Fri Dec 08, 2006 7:16 am

Thanks for the info and we use limited header files seeing it's a school project. And dont need everything thats availible

#111617 - gmiller - Fri Dec 08, 2006 1:48 pm

Your sprite movement function:
Code:

void InputKey()

{

if(keyDown(KEY_DOWN))
   {
      sprites[0].attribute0 = sprites[0].attribute0 + 1;
   }

if(keyDown(KEY_UP))
   {
      sprites[0].attribute0 = sprites[0].attribute0 - 1;
   }

if(keyDown(KEY_LEFT))
   {
      sprites[0].attribute1 = sprites[0].attribute1 - 1;
   }

if(keyDown(KEY_RIGHT))
   {
      sprites[0].attribute1 = sprites[0].attribute1 + 1;
   }

}



Is dangerous in its manipulation of the attributes. You should be using bitwise operators not arithmetic one. Bit limiting the fields is also a requirement to keep from setting bits in other fields.

for example:
Code:

u32 holder;
u32 value;

// to increment the current x value in attribute 0
value = (u32)sprites[0].attribute1; // copy to 32bit value
holder = value & 0x1FF; // Get the low order 9 bits
holder++;  // do 32 bit math (native for ARM
value &= ~(0x1FF); //clear the current low order 9 bits
value |= (holder & 0x1FF); // put in the new 9 bit value
sprites[0].attribute1 = (short) value; // save the new value


Note: since the native registers of the ARM are 32 bit doing manipulation of shorts (or chars) creates extra ARM instruction to force 16 bit values in the 32 bit registers so doing the manipulation in 32 bit "holders" is more efficient. The load from shorts (or chars) to 32 bit and the store from 32 bit to short (or chars) can be done in the load and store assembly instruction so it is generally no cost (to performance and size).

Generally the extraction, manipulation and insertion of the OAM fields can be cumbersome for some fields. But to insert a new bit value requires a clear of the current value using '&' 'and' and an appropriate bit mask (to clear just the selected bits) and then '|' 'or' in the new value bit limited to avoid setting unintentional bits. You should never use the math operators on bit fields because of the dangers to other bits outside of the range of the field you are trying to change.

This is an issue that students struggle with all of the time and it burns them frequently.

Also your copy of data into OAM is not using DMA and it should.