#18689 - Mephisto - Thu Apr 01, 2004 1:46 am
I want to sort sprites according to its y coord, without using the priority flag (only 4 levels).
So i tried to put my temporary OAM in the right order in the spriteOAM_RAM : here is the point, sprites appears in the right order as wanted, but their rot/scaling data are somehow fucked up !
I do not understand at all what i must update when i put OAM in another order in the spriteOAM_RAM.
help plz !!!!
Another problem, when i use rot/scaling, i must refresh all sprites, if not sprites are not drawn correctly ...
#18690 - dagamer34 - Thu Apr 01, 2004 1:54 am
Please post the code you are using. I can only guess that you are using DMA to copy all 4 attributes in a OAM entry instead of the first three that are used by sprites.
_________________
Little kids and Playstation 2's don't mix. :(
#18691 - Mephisto - Thu Apr 01, 2004 2:24 am
WaitVBLANK();
for (i = 0, j = 0; i < nbobjets; i++)
{
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute0;
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute1;
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute2;
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Unused;
}
//FinalResult is pointers array of sprite_struct, sorted by y-coord
#18693 - tepples - Thu Apr 01, 2004 2:32 am
Try this:
| Code: |
WaitVBLANK();
for (i = 0, j = 0; i < nbobjets; i++)
{
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute0;
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute1;
SpritesOAM_RAM[j++] = FinalResult[i]->SpriteOAM->Attribute2;
j++; /* skip writing to Unused, which actually contains rot/scale data */
}
|
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#18694 - Mephisto - Thu Apr 01, 2004 2:43 am
ok i must not update the fourth attribute ... ok thx
#18695 - Mephisto - Thu Apr 01, 2004 3:21 am
baaah !! sprites are not drawn, only black squares.
Must i refresh all spriteOAM_RAM ?
And i do not understand why mustnt i refresh fourth attribute since those sprite are rotated and scaled ...
#18696 - LOst? - Thu Apr 01, 2004 5:36 am
| Mephisto wrote: |
baaah !! sprites are not drawn, only black squares.
Must i refresh all spriteOAM_RAM ?
And i do not understand why mustnt i refresh fourth attribute since those sprite are rotated and scaled ... |
At least there are black squares....
Have you set up the sprite data in VRAM and made OAM point to it? (or maybe it's messed up afterwards?)
Last edited by LOst? on Thu Apr 01, 2004 2:28 pm; edited 1 time in total
#18704 - Lupin - Thu Apr 01, 2004 11:56 am
You should also check if you set up the correct value to rot/scale data. You can use these defines to make setting up sprites a bit easier:
| Code: |
typedef struct tagOAMEntry
{
u16 attribute0;
u16 attribute1;
u16 attribute2;
u16 attribute3;
}OAMEntry,*pOAMEntry;
typedef struct tagRotData
{
u16 filler1[3];
u16 hdx;
u16 filler2[3];
u16 hdy;
u16 filler3[3];
u16 vdx;
u16 filler4[3];
u16 vdy;
}RotData,*pRotData;
vu16* OAM = (vu16*)0x7000000; //the address of OAM
OAMEntry sprites[128]; //My sprite array
pRotData rotData = (pRotData)sprites; //My rotation and scaling array
|
1 Rotdata entry takes 4 attribute 3 elements (so you can not have independent rotation for all sprites). I think that code comes from one of the thepernproject.com tutorials (i suggest you looking there for more info). Sprites are sometimes a bit tricky, i also had the black-box problem, but i somehow solved it :)
_________________
Team Pokeme
My blog and PM ASM tutorials
#18705 - Cearn - Thu Apr 01, 2004 12:39 pm
Like the others have said, the OAM attributes and the Rot/Scale elements are interlaced, if you look at the code that Lupin gave you'll see that each RotData is 4 OAMEntries long, and the filler of OAMEntry (attribute3) is placed exactly where the actual RotData dat would be, and vice versa. I have a diagram of it here (scroll down to table 1). If you were to switch, say OAMEntry[0] and and OAMEntry[1], you would also switch pa and pb of RotData[0] if you updated the attribute3 of the OAMEntries. That's a bad idea (see Tepples' post). But you still need to update the RotData, of course, justdon't do it at the same time as the sorting. If you don't update it at all, the real RotData elements will be 0 and the first pixel of each sprite will be used for the whole sprite, which is probably why it's all black.
#18718 - Mephisto - Thu Apr 01, 2004 3:02 pm
Cearn thanks a lot, i understand all now, i ll try it soon ^^ thank u!!
#18727 - Mephisto - Thu Apr 01, 2004 11:33 pm
Yes it works pretty well thank you.
But i have another question, i read there was 32 rotations available at a time, but it seems to be limited by 8.
when i try to use the 9th it uses the first.
#18730 - tepples - Fri Apr 02, 2004 3:43 am
| Mephisto wrote: |
Yes it works pretty well thank you.
But i have another question, i read there was 32 rotations available at a time, but it seems to be limited by 8.
when i try to use the 9th it uses the first. |
Perhaps you're mistakenly ANDing out the two high order bits somewhere, probably in a header file. I've rotated 32 sprites independently.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.