#69590 - RavenWorks - Tue Jan 31, 2006 5:54 pm
What's the best way to remove a sprite I no longer want displayed? I'm writing a system that's going to rewrite all the sprite VRAM each frame (is this a bad idea?), and I'm just not sure what to do with all the sprite entries past the last one I need... should I fill them with zeroes, set their x to 241, set them to invisible, or something else entirely? (Does it even matter much?) I just don't want the extra unused sprites to be a problem, because I'm planning on using the hblank interrupt.
#69593 - Mucca - Tue Jan 31, 2006 6:29 pm
Disable rotation/scaling, and set double-size flag on. This is the hardware signal to disable the sprite. Processing of sprites with these attributes, while still consuming a few cycles, is cheaper than processing a sprite with an offscreen position, or one with all transparent tiles, and in the case of the later, allows you to fill your sprite VRAM and not have to retain a transparent tile.
#69614 - tepples - Tue Jan 31, 2006 8:32 pm
| RavenWorks wrote: |
| I'm writing a system that's going to rewrite all the sprite VRAM each frame (is this a bad idea?) |
As long as you use DMA or CpuFastSet() to fill sprite cel VRAM each frame, then it's not a bad idea at all. See my white paper on the topic.
| Quote: |
| and I'm just not sure what to do with all the sprite entries past the last one I need... should I fill them with zeroes, set their x to 241, set them to invisible, or something else entirely? |
I second what Mucca said: set them to invisible. The absolute easiest way to do this is attribute 0 = 512. Almost as good is to put them off the bottom of the screen (set attribute 0 to 160), which is what NES programs used.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#69623 - nmain - Tue Jan 31, 2006 9:20 pm
| Mucca wrote: |
| Disable rotation/scaling, and set double-size flag on. This is the hardware signal to disable the sprite. Processing of sprites with these attributes, while still consuming a few cycles, is cheaper than processing a sprite with an offscreen position, or one with all transparent tiles, and in the case of the later, allows you to fill your sprite VRAM and not have to retain a transparent tile. |
The only cost at rendering time for OAMs I know of is the per-scanline sprite limit; ~1200 sprite pixels per scanline, with affinely scaled sprites costing ~3x as much. What costs does placing a sprite at y=160 have above disabling rotate/scale and setting double size for that sprite?
#69624 - wintermute - Tue Jan 31, 2006 9:21 pm
| tepples wrote: |
| Almost as good is to put them off the bottom of the screen (set attribute 0 to 160), which is what NES programs used. |
not quite, sprites on the GBA can wrap around and reappear on the top if they're higher than 46 pixels.
#69625 - tepples - Tue Jan 31, 2006 9:28 pm
| wintermute wrote: |
| tepples wrote: | | Almost as good is to put them off the bottom of the screen (set attribute 0 to 160), which is what NES programs used. |
not quite, sprites on the GBA can wrap around and reappear on the top if they're higher than 46 pixels. |
How, if you're not turning double size on?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#69656 - wintermute - Tue Jan 31, 2006 11:53 pm
| tepples wrote: |
| wintermute wrote: | | tepples wrote: | | Almost as good is to put them off the bottom of the screen (set attribute 0 to 160), which is what NES programs used. |
not quite, sprites on the GBA can wrap around and reappear on the top if they're higher than 46 pixels. |
How, if you're not turning double size on? |
32x64 and 64x64 sprites?
#69659 - tepples - Wed Feb 01, 2006 12:09 am
Wouldn't a 32x64 pixel sprite whose y coordinate is 160 be not-displayed on lines 160 through 223?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#69692 - HyperHacker - Wed Feb 01, 2006 8:04 am
Just FYI, I'm pretty sure Mario Kart actually does this. When another racer comes on the screen, it adds a sprite for their image. If you now start sliding and smoke starts coming off your tires, more sprites are added for the smoke. Now if the other racer leaves the screen, their sprite is removed and the smoke sprites get bumped up to where they used to be. It seems like it would be quite difficult to do, but apparently it works!
#69697 - nmain - Wed Feb 01, 2006 9:38 am
| HyperHacker wrote: |
| Just FYI, I'm pretty sure Mario Kart actually does this. When another racer comes on the screen, it adds a sprite for their image. If you now start sliding and smoke starts coming off your tires, more sprites are added for the smoke. Now if the other racer leaves the screen, their sprite is removed and the smoke sprites get bumped up to where they used to be. It seems like it would be quite difficult to do, but apparently it works! |
The fzero games do a similar thing: the OAMs are changed each frame so that the ones in use are the lowest numbered ones, starting from 0 on up skipping none. I know that if you overflow your sprite rendering cycles on a scanline, the lowest numbered sprites will be visible, and the higher numbered ones won't; so if you anticipate overflow, best to put the important sprites at the lower end; but I don't understand how using the low number OAMs helps if you're hiding sprites by putting them at y = 160..
#69698 - keldon - Wed Feb 01, 2006 9:43 am
If you really cannot do this when they are 64px high, change its size - it's not getting displayed anyway
#69724 - wintermute - Wed Feb 01, 2006 3:07 pm
| tepples wrote: |
| Wouldn't a 32x64 pixel sprite whose y coordinate is 160 be not-displayed on lines 160 through 223? |
True, I have no idea what I was thinking of when I came up with the 46 pixel figure. Just ignore me :P