--- In gbadev@y..., "Mike Wynn" <mike.wynn@L...> wrote:
> I have a very simple test program, that has 2 backgrounds and two
sprites
> but it does not work on any hardware, but runs fine on vba/ba
>
> the setup is simple, one bg(0) priority 3, bg(1) prio 2
> the sprites (OAM entryies 0,1) are such that 0 is a charactor, and
1 is the
> outline.
> initially oam[0] prio is 3 and oam[1] is 2;
>
> depending on if my code thinks the charactor is "obscured" it
changes the
> priority of oam[0]
> to be either 3 or 2, thus allowing bg(1) to either under or over
the char,
> but at all times the outline of the char is visible.

So if I understand this correctly, the order of things is like this
(priorities in parenthesis):

Top
oam1 (2)
bg1 (2)
oam0 (3)
bg0 (3)

but occasionally you can do this to show oam0 above bg1 and above
oam1:

Top
oam0 (2)
oam1 (2)
bg1 (2)
bg0 (3)


>
> this works fine on all the emulators I've tried, but up the
hardware, bg(1)
> is always under the charactor.
>
> I did see the same problem occur some times in my "torn desktop"
demo and in
> both it only occurs on
> real hardware, is there more to obj/bg priorites than meet the eye ?
>

I have encountered a similar problem, I think. If your sprites are
ovelapping (at the same x,y coords) then I definitely have
encountered this "gotcha". This is the explanation of the "feature"
as I see it:

On hardware, if there are sprites overlapping, and a sprite that
should be behind another due to natural z ordering in the sprite list
is actually in front due to priority ordering (i.e. it has a larger
spriteID, but the sprite with lower sprite ID has lower priority),
then the sprite that has the lower ID will be drawn to the same
priority as the one "on top" due to natural sprite z ordering. This
results in the BG ordering being screwed, because a sprite has been
given a higher priority than you were expecting...

It is clearer with a diagram, the first list above would actually
look like this on hardware:

Top
oam1 (2)
oam0 (3) <- drawn as if it has priority 2
bg1 (2)
bg0 (3)


The fix I did was sort for z ordering so that if a sprite of lower ID
has a priority value greater than one higher in the sprite list (i.e.
should be behind the higher one) and they overlap, then I swap the
OAM values (I swap sprite attrib 2 of the troublesome sprites).

Solution: Try swapping over your sprites 0 and 1 and it should fix
the problem, as you aren't going "against" sprite z ordering so much.

Seems a bit strange really - the only explanation I can think of is
that Nintendo intended Sprite Priority to be used relative to the
backgrounds only, not relative to other sprites, so you need to
carefully manage where abouts you put them in the sprite list and use
that as your sprite-to-sprite priority.