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 > Sprite won't display properly

#124648 - Stuk - Sat Apr 07, 2007 4:27 pm

I seem to be encountering a few problems learning to code for the DS :)

This time I can't get a 16x16 sprite to appear properly. The left of the image is how it appears in emulators and on the DS, and the right is how it should appear (without the magenta eventually :) ):
[Images not permitted - Click here to view it]
For this I've set the sprite attributes to be 32x32 just to show that the data is there, but not in the right place. When set to 16x16 just the top red and green parts are shown.

This is the code I'm using to display the sprite:
Code:

   //sprite attribute memory
   SpriteEntry *spritesMain = new SpriteEntry[128];
   //rotation attributes overlap so assign then to the same location
   SpriteRotation *spriteRotationsMain = (SpriteRotation *)spritesMain;

   initOAM(spritesMain, spriteRotationsMain);

   int x = 10, y= 110, loc = 32;

   spritesMain[0].attribute[0] = ATTR0_COLOR_256 | ATTR0_ROTSCALE_DOUBLE | y;
   spritesMain[0].attribute[1] = ATTR1_ROTDATA(0) | ATTR1_SIZE_32 | x; //Set to 32 for debugging, should be 16
   spritesMain[0].attribute[2] = loc;

   //copy in the sprite palettes
   dmaCopy(ball_pal_bin, SPRITE_PALETTE, ball_pal_bin_size);

   //copy the sprite graphics in obj graphics mem
   dmaCopy(ball_img_bin, &SPRITE_GFX[loc * 16], ball_img_bin_size);

   updateOAM(spritesMain);


And this is how I've set up the memory:
Code:

   videoSetMode(MODE_0_2D | DISPLAY_BG0_ACTIVE| DISPLAY_SPR_ACTIVE );
   videoSetModeSub(MODE_0_2D | DISPLAY_BG0_ACTIVE);

   vramSetMainBanks(VRAM_A_MAIN_BG, VRAM_B_MAIN_BG, VRAM_C_SUB_BG, VRAM_D_LCD);
   vramSetBankE(VRAM_E_MAIN_SPRITE);


initOAM() clears the attributes for all sprites. Does anybody have any ideas on what might be going wrong? I wondered if I should be using a different display mode, but on switching this to MODE_5_2D everything broke :). I could have another stab at it if that is the problem.

Any help would be appreciated,
Stuk

Last edited by Stuk on Sat Apr 07, 2007 4:57 pm; edited 1 time in total

#124650 - Dark Knight ez - Sat Apr 07, 2007 4:36 pm

You have no copy for the sprites array to OAM?
_________________
AmplituDS website

#124653 - Stuk - Sat Apr 07, 2007 4:56 pm

Oops, forgot to include the trailing updateOAM(spritesMain) in my first post (now updated) which does this:
Code:
void updateOAM(SpriteEntry *spriteEntry) {
   DC_FlushAll();
    dmaCopy(spriteEntry, OAM, 128 * sizeof(SpriteEntry));
}

#124662 - tepples - Sat Apr 07, 2007 5:24 pm

There are two things that could cause that issue:
  1. Size is 32 (where it should be 16).
  2. Shape is wide (where it should be square).

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

#124665 - Stuk - Sat Apr 07, 2007 5:39 pm

tepples wrote:
1. Size is 32 (where it should be 16).

Like I mentioned, I've set it to 32 for debugging, just to show the data has been copied somewhere. When it is set to
spritesMain[0].attribute[1] = ATTR1_ROTDATA(0) | ATTR1_SIZE_16 | x;
Then I get this: [Images not permitted - Click here to view it]

tepples wrote:
2. Shape is wide (where it should be square).

I've tried that as well:
spritesMain[0].attribute[0] = ATTR0_SQUARE | ATTR0_COLOR_256 | ATTR0_ROTSCALE_DOUBLE | y;
gives exactly the same results. I assume "square" is default.

Thanks for the help so far :)

In case it helps some of the other code I'm using is in this topic, although obviously updated slightly for the addition of sprites.

#124669 - tepples - Sat Apr 07, 2007 5:54 pm

Stuk wrote:
tepples wrote:
2. Shape is wide (where it should be square).

I've tried that as well:
spritesMain[0].attribute[0] = ATTR0_SQUARE | ATTR0_COLOR_256 | ATTR0_ROTSCALE_DOUBLE | y;
gives exactly the same results. I assume "square" is default.

You're correct that square is the default. It's more likely that the value of the variable "y" is overwriting the bits intended for square/wide/tall. Have you tried following the suggestion in FAQ question "Why do my sprites become corrupt when I move them off the top or the left side of the screen"?
Code:
spritesMain[0].attribute[0] = ATTR0_SQUARE | ATTR0_COLOR_256 | ATTR0_ROTSCALE_DOUBLE
                              | (y & 0x00FF);

And have you tried it with 16-color and non-rot/scale sprites?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#124674 - Stuk - Sat Apr 07, 2007 6:31 pm

Anding 0x00FF and 0x01FF to y and x respectively made no difference. This is occurring over the whole screen, not just at the top or left.

Using a 16 colour image again made no difference.

And do I only need to remove ATTR0_ROTSCALE_DOUBLE to make sure I'm not using rot/scale sprites?
Code:
   spritesMain[0].attribute[0] = ATTR0_SQUARE | ATTR0_COLOR_256  | (y & 0x00FF);
   spritesMain[0].attribute[1] = ATTR1_ROTDATA(0) | ATTR1_SIZE_16 | (x & 0x01FF);


I've also just realised that I've done this earlier:
Code:
    BG0_CR     = BG_32x32 | BG_COLOR_256 | BG_MAP_BASE(0) | BG_TILE_BASE(1);
    SUB_BG0_CR = BG_32x32 | BG_COLOR_256 | BG_MAP_BASE(2) | BG_TILE_BASE(3);

Would that affect the 16x16 sprite? Or am I just being silly now? :)

#124691 - LiraNuna - Sat Apr 07, 2007 8:42 pm

Is your sprite tiling layout set to 1D?

DISPLAY_SPR_1D

Else the tile location might point to a different tile
_________________
Private property.
Violators will be shot, survivors will be shot again.

#124694 - Stuk - Sat Apr 07, 2007 8:52 pm

LiraNuna wrote:
Is your sprite tiling layout set to 1D?

DISPLAY_SPR_1D

Ahh hah!! Joy :D

So in conclusion this is the change that needed to be done:
Code:
videoSetMode(MODE_0_2D | DISPLAY_BG0_ACTIVE| DISPLAY_SPR_ACTIVE | DISPLAY_SPR_1D);
                                                                ^^^^^^^^^^^^^^^^
Your help is very much appreciated, thank you. *Very happy*

Now lets see if I can do something decent with this new knowledge :)

#124704 - beamer30 - Sat Apr 07, 2007 9:56 pm

before i post i just want to say im n00b so thats why i'm asking this question:

wouldn't it be easier to just use PAlib, or is there a certian reason your opening sprites that way?

#124706 - Stuk - Sat Apr 07, 2007 10:04 pm

Indeed I did think of resorting to PALib, but I want to learn about the hardware as it is, rather than have everything done for me through a layer of abstraction.

This way might be more difficult, but hell, it's a learning experience... and I want to be "hardcore" :P

#124708 - beamer30 - Sat Apr 07, 2007 10:09 pm

ok thanks i was just wondering hop you "hardcore" trining goes well

#124716 - tepples - Sat Apr 07, 2007 11:30 pm

As far as I know, PAlib is DS-only. Going directly to the hardware and building your own abstractions on top of that makes it easier to develop GBA and DS versions of a work in parallel.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.