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 > Page Flipping and Sprites

#105384 - strat - Sun Oct 08, 2006 9:43 am

Whulp, here I yam.

Now, when page flipping in mode 4, how would you get the sprite onto the offscreen buffer? OAM doesn't seem to have any bits for that, and of course writing pixels directly would defeat the purpose of OAM.

A couple of page flipping experiments told me the sprite is automatically on the screen buffer no matter what page is flipped.

#105405 - gmiller - Sun Oct 08, 2006 2:28 pm

Are you rying to hide the sprite on one buffer and show it on another and are you doing this on a GBA?

The rest of this is for the GBA, the DS is similar in some ways but not exactly the same.

Assuming GBA then the sprotes are not associated with a buffer so hiding them is just a global things not a buffer assciated thing. There are ways to hide sprites that differ based on whether the sprite is rotational/non-rotational or just using the x/y coordinates.

Since the x coordinate in OAM is 9 bits wide you get a value from 0 to 511. The y coordinate is OAM is 8 bits wide so the values are 0 to 255. You can position the sprite off the screen by setting the x/y coordinate out of the Display area of 240x160. The location of the coordinates is the upper left had corner for non-rotational sprites and the center for for rotational.

Hopes this helps for GBA, if you wanted DS some of this might apply but I am not that familar with the DS flavor of this.

#105425 - poslundc - Sun Oct 08, 2006 5:28 pm

strat wrote:
A couple of page flipping experiments told me the sprite is automatically on the screen buffer no matter what page is flipped.


As gmiller said, sprites are on a different plane than backgrounds. If you choose to use a double-buffered mode for your backgrounds, that doesn't affect sprites.

For sprites, you just need to make sure to make changes to them during the VBlank period at the end of every draw cycle, so that you don't get any tearing or other artifacts by making changes while the screen is updating.

To turn a sprite entry off, set its "double" flag (bit 9 of attribute 0) and clear its "rotation/scale" flag (bit 8 of attribute 0). This is the "official" way to mark an OAM entry as unused.

(Putting it offscreen works, but if it's done horizontally instead of vertically it will hurt the number of sprite rendering cycles you have on the scanlines it occupies, and if it's done vertically it won't work for large sprites.)

Dan.

#105499 - tepples - Mon Oct 09, 2006 12:00 am

poslundc wrote:
To turn a sprite entry off, set its "double" flag (bit 9 of attribute 0) and clear its "rotation/scale" flag (bit 8 of attribute 0). This is the "official" way to mark an OAM entry as unused.

Translation: just set the attribute 0 to a value of 512 (0x0200).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#105510 - poslundc - Mon Oct 09, 2006 2:35 am

tepples wrote:
Translation: just set the attribute 0 to a value of 512 (0x0200).


Er, yeah. :D

Dan.

#105660 - thegamefreak0134 - Tue Oct 10, 2006 5:34 pm

Well, wouldnt he walt to actually preserve the rest of the attribute, in which case he would need to first mask out that bit and or 512 to it? Perhaps not though.

On your thought, you would simply need to keep a second OAM array to store your sprite info, assuming you want different screens on the different buffers. Then, simply copy the OAM array you are going to use for the buffer you want to display. The GBA cant directly draw sprites to the buffers that I am aware of, it draws them as it draws the actual screen, so you must tell it what to do every frame.

If you want to actually use them as a buffer, you shouldnt really need to worry about the sprites untill you are ready to flip anyway. Your question leaves a lot to be asked. Could you clarify a little?

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

#105751 - strat - Wed Oct 11, 2006 6:38 pm

Basically, a moving sprite should look as clear as when it's still. But the sprites in my program blur so I'm trying to figure out why that is. Last night though, after playing around with the VBA settings I realized part of it is the emulator. Now I understand why you need to test on real hardware.

#105782 - thegamefreak0134 - Wed Oct 11, 2006 9:51 pm

If you test with the screen at x2 or x3 (how you can test at x1 is beyond me) then you should enable simple2x (filter options), which forces the screen to look all pixely regardless of what the windows API wants it to look like. The normal setting blurs based on a windows setting, and that tends to vary from computer to computer in my experience.
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

#105787 - tepples - Wed Oct 11, 2006 10:06 pm

strat wrote:
Basically, a moving sprite should look as clear as when it's still. But the sprites in my program blur so I'm trying to figure out why that is. Last night though, after playing around with the VBA settings I realized part of it is the emulator. Now I understand why you need to test on real hardware.

Game Boy Player blurs things too on a composite monitor, and so does a real GBA when things are in motion.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.