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 > attribute0 resets?

#4281 - fezz1k - Wed Mar 26, 2003 2:10 pm

hey there..

something weird is happening with my code. i've programmed in c/c++ for years, but for my first gba attempt, i figured i'd make a tetris clone. when setting up my sprites (one for each of the types of block types), the attribute0 setting for the fifth sprite always reset itself. this was driving me crazy, and i couldn't get started with any real progress, because i couldn't figure out why it was doing this. lo and behold, if at the end of the function where i set all this stuff up, i manually just set it once again, everything works fine. so i'm continuing my work on this, but i still can't figure out for the life of me what's happening! perhaps someone else could clue me in?

thanks

this is the code that's been ruffling my feathers (you can see at the end where i set the attribute again.. with that line commented, it is like i never set it at all):
Code:

void LoadSprites() { // should probably return a value, but not as concerned the info won't be there w/ roms
   char snum; // sprite we are dealing with.  each represents a block type, 0-6
   int lcv;
   s16 x,y;
   //u16* charMem = (u16*)0x6010000;
   //u16* objpalMem = (u16*)0x5000200;

   for (lcv=0;lcv<23;lcv++) {
      OBJPaletteMem[lcv]=palette[lcv];
   }
   y=160; // init offscreen, since all 6 will technically always be there
   x=240;

   for (lcv=0;lcv<128;lcv++) {
      OAMdata[lcv]=obj0[lcv];
   }
   for (lcv=0;lcv<256;lcv++) {
      OAMdata[lcv+128]=obj1[lcv];
   }
   for (lcv=0;lcv<256;lcv++) {
      OAMdata[lcv+384]=obj2[lcv];
   }
   for (lcv=0;lcv<128;lcv++) {
      OAMdata[lcv+640]=obj3[lcv];
   }
   for (lcv=0;lcv<256;lcv++) {
      OAMdata[lcv+768]=obj4[lcv];
   }
   for (lcv=0;lcv<256;lcv++) {
      OAMdata[lcv+1024]=obj5[lcv];
   }
   for (lcv=0;lcv<256;lcv++) {
      OAMdata[lcv+1280]=obj6[lcv];
   }

   snum=0; // line block  |
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_16 | x;
   sprites[snum].attribute2 = 0;

   snum=1; // backwards L  |_
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_32 | x;
   sprites[snum].attribute2 = 8;

   snum=2; // forwards L  _|
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_32 | x;
   sprites[snum].attribute2 = 24;

   snum=3; // square piece []
   sprites[snum].attribute0 = COLOR_256 | SQUARE | y;
   sprites[snum].attribute1 = SIZE_16 | x;
   sprites[snum].attribute2 = 40;

   snum=4; // squiggle left \
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_32 | x;
   sprites[snum].attribute2 = 48;

   snum=5; // squiggle right /
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_32 | x;
   sprites[snum].attribute2 = 64;

   snum=6; // easy fit piece _+_
   sprites[snum].attribute0 = COLOR_256 | WIDE | y;
   sprites[snum].attribute1 = SIZE_32 | x;
   sprites[snum].attribute2 = 80;

   sprites[4].attribute0 = COLOR_256 | WIDE | y;  // don't ask me why i have to do this (again), but i do.

}

#4282 - peebrain - Wed Mar 26, 2003 3:45 pm

I always have weird shit like that happen to me too. I think GCC screws it up from fancy optimization or something (I could be wrong though). I'd be interested in the solution to this problem.

~Sean
_________________
http://www.pbwhere.com

#4322 - I.C.E - Thu Mar 27, 2003 11:03 pm

I would suggest checking the following:

1. If you have multiple object files which you are linking check if all are up do date
2. Check if some data structure is exceeding the GBA memory limits (nm)

By the way how is your sprites structure exactly defined?
_________________
To this day, many C programmers believe that "strong typing" just means pounding extra hard on the keyboard.
- Peter van der Linden

#4328 - fezz1k - Fri Mar 28, 2003 6:47 am

I'm not linking multiple objects, and (as far as I can tell), nothing is too big for the GBA's memory (as loading the sprites was one of the first things the program was doing, I really hadn't put all that much of anything into memory when this started happening). Once again, though, admittedly.. this is my first GBA program, so I might be entirely wrong. The sprites[] structure is defined like the dovoto tutorials:
Code:
typedef struct tagOAMEntry
{
   u16 attribute0;
   u16 attribute1;
   u16 attribute2;
   u16 attribute3;
}OAMEntry,*pOAMEntry;

OAMEntry sprites[128];

#4329 - Quirky - Fri Mar 28, 2003 8:47 am

Could it be something to do with you using s16s for the x, y coordinate? Shouldn't have an effect as they are all < 255, but you need to be careful not to overwrite bits that you aren't using in OAM. Here's a link to the cowbite spec, which details the sprite entries:

http://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#OAM (sprites)

Check your WIDE and SIZE definitions too, that they aren't too big/small and overwriting where they shouldn't. Also, when do you copy your sprites from ram to oam? Could it be that you don't copy this sprite value across when you expect? Have you tried not positioning the sprites when you define their behaviour, then moving them later? Might help narrow down the problem - better to understand why something goes wrong than fudge it and hope it doesn't crop up again![/code]