#73883 - CyberSlag5k - Tue Feb 28, 2006 7:29 pm
Supposedly if you don't set the positions of all 128 sprites, you get this little artifact in the top left corner. I do exactly that, however:
| Code: |
void initializeSprites()
{
for(u16 i = 0; i < 128; i++)
{
sprites[i].attribute0 = 160;
sprites[i].attribute1 = 240;
}
} |
and I still get the little guy up there. That function is called before I really do anything with sprites:
| Code: |
int main()
{
SetMode(MODE_1 | OBJ_ENABLE | OBJ_MAP_1D);
s16 x = 100;
s16 y = 40;
initializeSprites();
|
So I think I've met that little requirement. The rest of my code is pretty simple. I'll post it if necessary, but it lines up almost exactly with code from jbajunkie and dovoto's tutorials.
Any ideas on what else can cause the little artifact up there?
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...
#73896 - Quirky - Tue Feb 28, 2006 8:35 pm
Do you copy your sprites array to OAM (sprite video ram) later? Also, the best way to disable sprites is to set the sprite double size flag without the rotation flag in attribute 0.
#73897 - CyberSlag5k - Tue Feb 28, 2006 8:37 pm
| Quirky wrote: |
| Do you copy your sprites array to OAM (sprite video ram) later? |
Yup.
| Quote: |
| Also, the best way to disable sprites is to set the sprite double size flag without the rotation flag in attribute 0. |
Not entirely sure I understand that, but I believe Dovoto's day 3 can elaborate.
THanks, Quirky!
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...
#73952 - nmain - Wed Mar 01, 2006 3:06 am
| Quirky wrote: |
| Do you copy your sprites array to OAM (sprite video ram) later? Also, the best way to disable sprites is to set the sprite double size flag without the rotation flag in attribute 0. |
I've heard that many times and still haven't gotten a straight answer as to why it is in any way "better" than moving them to y=160.
#73957 - tepples - Wed Mar 01, 2006 3:24 am
For one thing, sprites that are 64 pixels tall and double-size might wrap around to the top. For another, some methods of sprite allocation might want to distinguish between "not allocated" and "offscreen" (attribute 0 == 512 means deallocated).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#73964 - CyberSlag5k - Wed Mar 01, 2006 4:28 am
AHh, that's much nicer. I didn't know that. Thanks, Tepples :).
_________________
When you find yourself in the company of a halfling and an ill-tempered Dragon, remember, you do not have to outrun the Dragon...
#74126 - nmain - Thu Mar 02, 2006 5:24 pm
| tepples wrote: |
| For one thing, sprites that are 64 pixels tall and double-size might wrap around to the top. For another, some methods of sprite allocation might want to distinguish between "not allocated" and "offscreen" (attribute 0 == 512 means deallocated). |
Then you make it not 64 pixel tall double size? A single 16 bit write to attr0 will do that. Of course, a single 16 bit write to attr 0 can set y = 160, turn off affine, and turn on doublesize at the same time, for an ultimate hidden sprite ^__^. Still really can't see what makes one method of hiding any better than another.
#74499 - Ultima2876 - Sun Mar 05, 2006 1:58 pm
As with everything, it depends how you do it. If you want to take advantage of tepples' second point, it makes sense to set the DOUBLE SIZE thing.
#77342 - ion - Thu Mar 30, 2006 2:11 pm
HI all,
Want to reopen this thread as I'm having the same trouble.
| Code: |
void initialise_sprites(void)
{
int ii;
for(ii = 0; ii < 128; ii++)
{
oam_buffer[ii].attribute0 = (160 | OAM_HIDE);
oam_buffer[ii].attribute1 = 240;
}
}
|
So basically I make this call first, then update_oam() function. This is all called before anything else. I still seem to be getting artifacts in the top left corner of the screen. The artifact is actually part of oam_entry[1] i.e. second. this is odd.. can anyone enlighten me as to why this is still occuring.
ION
#77345 - ion - Thu Mar 30, 2006 3:07 pm
ok ok so I found the problem.. my update oam function was coded incorrectly.. here's the final and it works...
| Code: |
static inline void update_oam()
{
int ii;
for(ii = 0; ii < 128 * sizeof(OAMEntry) / 4 ; ii++)
{
((u32*)OAMMemory)[ii] = ((u32*)oam_buffer)[ii];
}
}
|
I was copying wrong sized chunks... oops...
ION