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.

C/C++ > diffrent sprites?

#20156 - CodeMasterMike - Mon May 03, 2004 10:12 am

I'm trying to use several diffrents sprites in my GBA project.
Meaning that I use diffrent headers, not the same.


Here, for every new sprite I use, I add 1 to 'usingSprite'.

Code:

pSpriteVar[usingSprite].attribute0 = COLOR_256 | MODE_TRANSPARENT | yOnScreen;
pSpriteVar[usingSprite].attribute1 = SIZE_64 | xOnScreen;
pSpriteVar[usingSprite].attribute2 = varOnScreen;


And down here are when I initialize the two objects

Code:

Spiders = new CSpider(1, 1, (8*8), alien3Data, alien3Palette, 1);
   
Barney = new CMainCharacter(80, 85, numbOnScreen, tank3Data, tank3Palette, 0);


(the last variable in the inparameter, is the 'usingSprite' value)

The problem is, that it draws out the same "picture" on the diffrent places,
I have no idea why it does this.
[/code]
_________________
Eating meat is not a choise, it's a instinct

#20157 - NoMis - Mon May 03, 2004 10:31 am

Seems your not changing the varOnScreen value which gos to attr2. Attr2 holds the character index where the actual sprite data beginns. If this value is the same on both sprites than this could be the mistake.

NoMis

#20158 - CodeMasterMike - Mon May 03, 2004 1:13 pm

No, I set the varOnScreen first in the function along with the x and y.

Code:

    xOnScreen = x;
    yOnScreen = y;
    varOnScreen = numbOnScreen;


I've tried to make a new project where I just use 2 classes and each class draws one sprite, but I still got the same problem

here is one of the classes called "TankClass"

Code:

Tank::Tank(int x, int y, int numb, const unsigned short* Data, const unsigned short* Palette, int number)
{
    xOnScreen = x;
    yOnScreen = y;
    varOnScreen = numb;
    usingSprite = number;
   
    //set the sprite palette
    for(int n = 0; n < 256; n++)
        SpritePal[n] = Palette[n];

    //copy the sprite image into memory
    for(int n = 0; n < (256*8); n++)
        SpriteData[n] = Data[(256*8) + n];

    //set the video mode--mode 2 with sprites
    SetMode(2 | OBJ_ENABLE | OBJ_MAP_1D);

    // Hide the sprites
    for(int n = 0; n < 128; n++)
    {
        pSpriteVar[n].attribute0 = 160;
        pSpriteVar[n].attribute1 = 240;
    }
   
    UpdateTank();

}

int Tank::UpdateTank()
{
   
    pSpriteVar[usingSprite].attribute0 = COLOR_256 | MODE_TRANSPARENT | yOnScreen;
    pSpriteVar[usingSprite].attribute1 = SIZE_64 | xOnScreen;
    pSpriteVar[usingSprite].attribute2 = varOnScreen;
   
    UpdateSpriteMemory();
    return 1;
}

int Tank::UpdateSpriteMemory()
{
    int n;
    unsigned short* temp;
   temp = (unsigned short*)pSpriteVar;

   for(n = 0; n < 128*4; n++)
        SpriteMem[n] = temp[n];

   return 1;
}



And here is when I create the object

Code:

    Tanken = new Tank(80, 40, 0, tank3Data, tank3Palette, 0);

_________________
Eating meat is not a choise, it's a instinct

#20161 - poslundc - Mon May 03, 2004 1:47 pm

You realize that when you initialize a sprite's tile data you are copying it to the same location in VRAM every time? Thereby overwriting any old sprites each time you load a new one?

Dan.

#20162 - Cearn - Mon May 03, 2004 1:54 pm

In Tank::Tank
Code:

    //copy the sprite image into memory
    for(int n = 0; n < (256*8); n++)
        SpriteData[n] = Data[(256*8) + n];

I'm assuming that this is supposed to copy the tile-data of the Tank's sprite into VRAM, right? (and it does this with every tank you make, seems a bit wasteful, but that's just me). But if you use this exact code for every class you have, you'll override the tiles in VRAM with every created sprite, since the destination always starts at SpriteData. You can check in VBA's tile viewer if this is indeed the case.

Also, in Tank::UpdateTank, if you simply OR the xOnScreen and yOnScreen into OAM, you're gonna get into trouble if you don't clip the positions to 9 and 8 bits, respectively, somewhere else.

EDIT: dammit! too late again.