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.

Coding > Sprite overlap problem

#1467 - Arek the Absolute - Sun Jan 19, 2003 4:46 am

This is a problem that's been bothering me for a while, mostly because emulators tend not to show it, so I can't solve it without running it on hardware. Anyway, here's the basics of it:

For starters, I have a rotation background (priority 3). On top of that, I draw one sprite, of a character, which is priority 2. This works fine, and shows like this:
[Images not permitted - Click here to view it]

Next, I add another sprite on top of this one. For example's sake, let's make it a textbox, which is just black, and overlayed on the sprite and the background. It's priority is 1. Again, this works fine, and looks like this:
[Images not permitted - Click here to view it]

Now comes the problem. I overlay another sprite on top of the textbox. This final sprite's priority is 0. However, wherever there is masking on the text, it masks through the textbox itself. Most emulators show it like this:
[Images not permitted - Click here to view it]
which is what I want. Unfortunately, on hardware it ends up looking like this instead:
[Images not permitted - Click here to view it]

Is it just that the GBA can't properly overlay that many sprites? I mean, I can fill the text sprites in so that there is no masking problem, but I just want to know if I'm doing something stupid here. Anyone have any advice? Thanks in advance!

-Arek the Absolute
_________________
-Arek the Absolute

#1469 - tepples - Sun Jan 19, 2003 6:09 am

Use the "priority" of a sprite to put it behind backgrounds, with prio 0 in front and prio 3 in back.

Use the order in OAM of a sprite to put it behind other sprites, with index 0 in front and index 127 in back.

Do not use prio to put a sprite behind other sprites. It won't work right. If a front (prio 0) sprite comes after a back (prio 3) sprite in the OAM, and those sprites overlap in (x, y), and there are background pixels between the sprites, results are implementation-defined[1]. If the 'A' in your illustration comes after the little girl in OAM, it may produce the misbehavior you're seeing.

So if you're using sprite prio, and you're not trying to pull extremely clever windowing tricks like some NES games used, make sure to sort your sprites by prio (all prio 0 sprites before prio 1 sprites before prio 2 sprites before prio 3 sprites) before writing them to OAM.

[1] "Implementation-defined" is a word often used in standards documents to mean "emulators will screw it up".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#1491 - Kay - Sun Jan 19, 2003 4:29 pm

Let expose sprite trouble under a different point of view.

A normal sprite takes 1 cycle to LCD hardware per pixel to display in normal mode. That meens a 8 pixel wide sprite will take 8 cycles to LCD hardware to display.
When using Rotation/Scaling 1 pixel takes about 3.25 cycles to display.
Add to this 1 extra cycle if sprite is alpha blended against BG.

LCD hardware has 954 (or 1210 if FORCE_HBLANK bit is cleared) cycles avaible per line to process sprites.

All undisplayed sprites have to be put offscreen by placing X,Y coordinates at bottom of screen area (X: - sprite_size,Y: 160+), have bits 10-11 set @ attribute 0, rotation/scaling bit cleared, and sized to 8x8 16 colors.

Nearest priority sprite is processed before and full line is rendered to internal display buffer. So a large sprite, i.e. 64 pixel wide in 256 colors double sized for rotation/scaling is used, this will take to LCD unit 128*3.25 = 416 cycles to process !

It's also possible that your farest priority sprite ran out of time to be propely dsiplayed, resulting in final display artefacts.


-- Kay

#1516 - Arek the Absolute - Sun Jan 19, 2003 7:16 pm

The problem seems to be solved! Thanks, everyone, and in particular tepples. That is to say, once I straightened out the order of the sprites, the problem dissappeared. Thanks again!
_________________
-Arek the Absolute