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.

Beginners > OAMSpriteNum >= 33 problem

#9925 - hnager - Fri Aug 22, 2003 12:05 am

I have an array of pointers to sprites (reflectors[]) which are placed on stage by moving a cursor and hitting the A-button...first i check to see if a sprite has already been placed in the cursor's position and then (if not) increment a variable (currOAM) which I'm using for OAMSpriteNum, it all works great until that variable >= 33... I should mention the attributes:

sprites[currOAM].attribute0 = COLOR_256 | SQUARE | ROTATION_FLAG | reflectors[curr]->getY();
sprites[currOAM].attribute1 = SIZE_16 | ROTDATA(currOAM) | reflectors[curr]->getX();
sprites[currOAM].attribute2 = 0;

When it gets to that point the sprites show up as a solid colored block and anything after is shown in the same way...why would that happen? I can post more of the source if it would help.

#9927 - yaustar - Fri Aug 22, 2003 1:11 am

Have you checked eithier with Visual BOy Advance 1.6 or Mappy if the sprites from 33 onwards have been loaded into Memory?
_________________
[Blog] [Portfolio]

#9931 - hnager - Fri Aug 22, 2003 3:01 am

If you don't mind - explain more about how to do that...how/why would that happen?

#9933 - tepples - Fri Aug 22, 2003 3:14 am

There are only 32 rotation data registers in OAM. You'll have to either use fewer rotated sprites or quantize your sprites to one of 32 rotations. If your game design does not allow fewer rotated sprites, use the classic NES/Genesis/Super NES trick of pre-rotated sprite cels.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.


Last edited by tepples on Fri Aug 22, 2003 3:25 am; edited 1 time in total

#9934 - hnager - Fri Aug 22, 2003 3:19 am

aha - that explains it. I could bring in the pre-rotated sprites as I really only need them in 4 possible rotations...but would it also be possible to utilize 4 rotation datas for each of the positions as dynamically point them to th e correct data when I change their state?

#9936 - tepples - Fri Aug 22, 2003 3:28 am

If their rotations are quantized to four positions, you can definitely use only four rotation data registers and point each sprite to one of those registers.

But if you only have four positions, you might as well pre-rotate them because you can only fit about 300 pixels' worth of rotated sprites on one line, as opposed to about 1000 pixels of unrotated sprites. Pre-rotated sprites have additional flexibility in lighting.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#9943 - hnager - Fri Aug 22, 2003 12:45 pm

Thanks again tepples - I'm not sure i understand what you mean by pixels-per-line though...

#9950 - tepples - Fri Aug 22, 2003 7:42 pm

Every sprite has a width. If the widths of the sprites on a scanline total more than the maximum total width that the hardware supports, the hardware begins to disable sprites on that scanline. This is why players often saw sprite flicker on the NES, as the NES supported only 64 sprite pixels per scanline.

The point is that you'll be able to fit more sprites and larger sprites on the screen without flicker if you use non-rotated sprites.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.