#43749 - revengero - Thu May 26, 2005 6:14 am
Hi, I was wondering if anyone was having issues with sprites that are stored in slots after 32 in the OAM in mode 4. It seems that if I put a sprite anywhere between 0 and 31 it displays fine, but after 32 it disregards any attributes ive set and sets its own. It also sped up game play somehow... anyone have any clues?
#43750 - poslundc - Thu May 26, 2005 6:44 am
Are you certain that you are spacing your OAM entries out at the correct intervals? If you are accidentally putting them in every fourth slot (possibly because of faulty pointer arithmetic), it would function correctly up to 32 but with wasted space between the entries. Check the OAM viewer in VBA to make sure this isn't the case.
Also, make sure you aren't referencing anything past the first half (16K) of VRAM, since only the first half is available in Mode 4. I don't know if this could cause the problem you're describing or not, as I've never tried it.
Dan.
#43784 - tepples - Thu May 26, 2005 8:14 pm
| poslundc wrote: |
| Also, make sure you aren't referencing anything past the first half (16K) of VRAM, since only the first half is available in Mode 4. |
You mean only the second half of sprite cel VRAM is available in Mode 4, right?
| Quote: |
| I don't know if this could cause the problem you're describing or not, as I've never tried it. |
Consensus is that sprites that reference the first half of sprite cel VRAM just don't show up.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#43800 - poslundc - Thu May 26, 2005 9:25 pm
| tepples wrote: |
| poslundc wrote: | | Also, make sure you aren't referencing anything past the first half (16K) of VRAM, since only the first half is available in Mode 4. |
You mean only the second half of sprite cel VRAM is available in Mode 4, right? |
That's right; I stand corrected. Which means that would be unlikely to be the problem unless you are overrunning the 16K of VRAM entirely.
Dan.
#43807 - ScottLininger - Thu May 26, 2005 11:07 pm
Dan's suggestion could still be valid, though it sounds like revengero's problem isn't with the sprite cell (aka pixel) data, but with the OAM attributes.
If there is some pointer math problem in his OAM setting or his OAM structs that spaces the entries out, as Dan described, it could appear that you only have 32 sprites to play with.
revengero, another possibility is that you are trying to update the OAM memory outside of VBLANK. If memory serves, OAM is "read-only" except during the VBLANK period. Most people maintain a "shadow" copy of OAM in some other portion of RAM. During run time, the shadow copy is updated, and then when VBLANK occurs, they copy over the shadow version into the physical OAM.
If your "update OAM" code is too slow, it might only be copying over 32 sprites worth of attributes before vBLANK ends.
-Scott
#43845 - FluBBa - Fri May 27, 2005 8:10 am
OAM and VRAM is available outside of VBlank, you only get waitstates when the screen is rendering.
_________________
I probably suck, my not is a programmer.
#44089 - revengero - Mon May 30, 2005 4:31 am
Ok figured out the problem. In OAM, a TOTAL of 32 instances of the rotation scaling combos can be stored. In my init sprite function, I was setting the rotation flag automatically for all 128 sprites. This was giving it too much info and ended up overwriting parts of memory elsewhere, thus causing lots of screwy errors! so beware, you can only have 32 sprites capable of rotation/scaling!
#44090 - tepples - Mon May 30, 2005 4:43 am
True, you can only have 32 independent rot/scale sprites, but you can have more than 32 rot/scale sprites if several sprites share one matrix. This is useful if you're only using rotation or only using scaling, as you can just preload a set of representative matrices.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.