#8808 - whodoo - Sun Jul 20, 2003 5:50 pm
right now Im doing like this
u16* OAM = (u16*)0x7000000;
OAMEntry sprites[128];
the OAMEntry struct contains 4 u16 variables... then, after VBlank, I just copy the stuff from sprites to OAM..
WaitForVsync();
Copy everything from sprite to OAM with DMA..
everything works..
but if I do something like
OAMEntry *sprites = (OAMEntry*)0x7000000, so that when I change a sprite the change will directly go into the memory(so I dont have to copy it), the sprites are moving faster and the program?s acting grazy..why?s that?
#8809 - johnny_north - Sun Jul 20, 2003 6:07 pm
Accoring to the specs and faqs, you can only write to the actual OAM memory in the vblank. This means that if you have a gob of sprites that have to have different attributes chaged every frame, you must do it all in the vblank. I've never actually tried your suggested approach, but it would seem to limit greatly what you can do with sprites.
If you have a special case thing going, by all means. But if you don't, make it easier on yourself and just use the copy method. If you're running into speed issues, look to optimize where it counts. After all, vblank doesn't last for ever, and other things are more appropriate for it. map changes, updating sound buffers etc...
BTW using DMA 3 would speed this along if you're not already using it.
#8811 - whodoo - Sun Jul 20, 2003 6:17 pm
I tried to use the seconds method.. and I changed the sprite-info after VBlank.. still the same result?..why?..cuz
watiforvsync();
changesprites(); // directly to mem
would be the same stuff as:
changesprites();
watiforvsync();
copysprites();
?..but it only works good with the last code
#8813 - johnny_north - Sun Jul 20, 2003 6:27 pm
In both examples you are changing actuall OAM memory "in" the vblank. You have a number of cycles to do this. You don't have to do this right at the begining of the vblank. The key is doing it during the vblank period.
Make sure you set your pointer correctly.
#8814 - whodoo - Sun Jul 20, 2003 6:31 pm
yeah the pointer is set right.. but.. in both cases I do change the OAM-memory in the VBLank..but when I dont "copy" it from sprites the program?s acting crazy
#8815 - whodoo - Sun Jul 20, 2003 6:37 pm
the things is, the program?s running faster or something...the sprites are moving very fast and stuff
#8822 - ampz - Sun Jul 20, 2003 11:58 pm
| johnny_north wrote: |
After all, vblank doesn't last for ever, and other things are more appropriate for it. map changes, updating sound buffers etc...
|
You are absolutely right, vblank does not last forever, so let's not waste it updating sound buffers. It is much more logical to do that directly after vblank. Right?
#8823 - johnny_north - Mon Jul 21, 2003 1:20 am
I'll grant you that. I suppose there's more than one way to update a sound buffer.
#8827 - tepples - Mon Jul 21, 2003 4:01 am
| ampz wrote: |
| johnny_north wrote: | After all, vblank doesn't last for ever, and other things are more appropriate for it. map changes, updating sound buffers etc...
|
You are absolutely right, vblank does not last forever, so let's not waste it updating sound buffers. It is much more logical to do that directly after vblank. Right? |
Sound needs a timer to tell when a given buffer is done playing, and vblank is the easiest timer to base that on (provided your buffer size is four times a factor of 70224). Vcount would work just as well, but it's a bit more complicated to set up a timer that updates sound buffers on vcount if there are different tasks to do at different vcounts.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#8897 - ampz - Wed Jul 23, 2003 1:41 pm
| tepples wrote: |
| ampz wrote: | | johnny_north wrote: | After all, vblank doesn't last for ever, and other things are more appropriate for it. map changes, updating sound buffers etc...
|
You are absolutely right, vblank does not last forever, so let's not waste it updating sound buffers. It is much more logical to do that directly after vblank. Right? |
Sound needs a timer to tell when a given buffer is done playing, and vblank is the easiest timer to base that on (provided your buffer size is four times a factor of 70224). Vcount would work just as well, but it's a bit more complicated to set up a timer that updates sound buffers on vcount if there are different tasks to do at different vcounts. |
Yes, but as I said, a very convenient place to do it is immediately after vblank. The result is the same as if you do it at the beginning of vblank.