VDP Plane Priority Bug in Dgen-SDL
Posted: Sat Sep 15, 2012 12:30 am
I'm new here. Hello.
I have been trying to track down an annoying VDP bug in dgen-sdl. I first asked on assemblergames and they pointed me here.
I hope it is OK to just paste my original post:
Look at the attached screenshot. Notice the player sprite is partially over the scores.
The plane priority on the emulator is as follows:
---8<---
// Draw, from the bottom up
// Low priority
draw_plane_back1(line);
draw_plane_back0(line);
draw_window(line, 0);
draw_sprites(line, 0);
// High priority
draw_plane_front1(line);
draw_plane_front0(line);
draw_window(line, 1);
draw_sprites(line, 1);
---8<---
I think plane 0 is plane A here and 1 = B.
What we are seeing here is a low priority sprite rendering over the low priority window plane. It looks wrong and is (this doesn't happen on the real thing).
By drawing the window planes last, ie:
---8<---
// Draw, from the bottom up
// Low priority
draw_plane_back1(line);
draw_plane_back0(line);
draw_sprites(line, 0);
draw_window(line, 0);
// High priority
draw_plane_front1(line);
draw_plane_front0(line);
draw_sprites(line, 1);
draw_window(line, 1);
---8<---
then the game *appears* correctly.
Yet if we consult some docs (http://emu-docs.org/Genesis/Graphics/genvdp.txt):
---8<---
(back) (front)
A > B > C > D > E' > F' > G'
' = Denotes high priority
A = Backdrop color
B = Low priority plane B
C = Low priority plane A
D = Low priority sprites
E = High priority plane B
F = High priority plane A
G = High priority sprites
---8<---
And we are given some info about the interaction of window too:
---8<---
The window plane operates differently from plane A or B. It can be thought
of a 'replacement' for plane A which is used under certain conditions.
That said, plane A cannot be displayed in any area where plane W is
located, it is impossible for them to overlap.
---8<---
This implies the following plane ordering to me:
---8<---
Backdrop color
Low priority plane B
Low priority plane A
Low priority window
Low priority sprites
High priority plane B
High priority plane A
High priority window
High priority sprites
---8<---
This is exactly the ordering that causes the issue in the first place?!
Can someone clarify this. Should the window always be on top? Any ideas what this is all about?
I have been trying to track down an annoying VDP bug in dgen-sdl. I first asked on assemblergames and they pointed me here.
I hope it is OK to just paste my original post:
Look at the attached screenshot. Notice the player sprite is partially over the scores.
The plane priority on the emulator is as follows:
---8<---
// Draw, from the bottom up
// Low priority
draw_plane_back1(line);
draw_plane_back0(line);
draw_window(line, 0);
draw_sprites(line, 0);
// High priority
draw_plane_front1(line);
draw_plane_front0(line);
draw_window(line, 1);
draw_sprites(line, 1);
---8<---
I think plane 0 is plane A here and 1 = B.
What we are seeing here is a low priority sprite rendering over the low priority window plane. It looks wrong and is (this doesn't happen on the real thing).
By drawing the window planes last, ie:
---8<---
// Draw, from the bottom up
// Low priority
draw_plane_back1(line);
draw_plane_back0(line);
draw_sprites(line, 0);
draw_window(line, 0);
// High priority
draw_plane_front1(line);
draw_plane_front0(line);
draw_sprites(line, 1);
draw_window(line, 1);
---8<---
then the game *appears* correctly.
Yet if we consult some docs (http://emu-docs.org/Genesis/Graphics/genvdp.txt):
---8<---
(back) (front)
A > B > C > D > E' > F' > G'
' = Denotes high priority
A = Backdrop color
B = Low priority plane B
C = Low priority plane A
D = Low priority sprites
E = High priority plane B
F = High priority plane A
G = High priority sprites
---8<---
And we are given some info about the interaction of window too:
---8<---
The window plane operates differently from plane A or B. It can be thought
of a 'replacement' for plane A which is used under certain conditions.
That said, plane A cannot be displayed in any area where plane W is
located, it is impossible for them to overlap.
---8<---
This implies the following plane ordering to me:
---8<---
Backdrop color
Low priority plane B
Low priority plane A
Low priority window
Low priority sprites
High priority plane B
High priority plane A
High priority window
High priority sprites
---8<---
This is exactly the ordering that causes the issue in the first place?!
Can someone clarify this. Should the window always be on top? Any ideas what this is all about?
