Vertical Scroll VDP bug in Dgen, any ideas?
Moderators: BigEvilCorporation, Mask of Destiny
Vertical Scroll VDP bug in Dgen, any ideas?
Hi,
As you guys know, I have been plugging away at VDP bugs in dgen. Here is another I would appreciate your opinions on.
In some games planes which should be scrolling vertically corrupt. Blocks of the plane are missing. Games that seem broken in this way:
Sonic 3 - Gumball bonus stage
Gunstar Heroes - Rocket Level
Psycho PInball - High scores screen
Here are some screenshots:
It is most noticable on Gunstar Heroes, where bits of the rocket are missing:
Here I guess something should have obscured the boss until later:
Psycho Pinball High Score Screwup -- He scrolls in vertically and then snaps in the wrong place, like this:
I am assuming this is all the same bug, but I am not sure. Not that this is not a regression introduced by the recent sprite masking changes in dgen. It was like this before.
Anyone have any ideas? Another corner case in the VDP I bet
As you guys know, I have been plugging away at VDP bugs in dgen. Here is another I would appreciate your opinions on.
In some games planes which should be scrolling vertically corrupt. Blocks of the plane are missing. Games that seem broken in this way:
Sonic 3 - Gumball bonus stage
Gunstar Heroes - Rocket Level
Psycho PInball - High scores screen
Here are some screenshots:
It is most noticable on Gunstar Heroes, where bits of the rocket are missing:
Here I guess something should have obscured the boss until later:
Psycho Pinball High Score Screwup -- He scrolls in vertically and then snaps in the wrong place, like this:
I am assuming this is all the same bug, but I am not sure. Not that this is not a regression introduced by the recent sprite masking changes in dgen. It was like this before.
Anyone have any ideas? Another corner case in the VDP I bet
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Vertical Scroll VDP bug in Dgen, any ideas?
I know that Gunstar Heroes stage uses vertical column scrolling on that stage to draw the plane and I think Sonic 3 might as well, so I'd look into that.
Gunstar Heroes also uses it in Black's base to wiggle the repeating background pattern and on the option screen background to curve the horizon if you want other locations to check.
I guess I'd look how the offset into the name table is calculated for column scrolling and verify it isn't going out of bounds. As a reference remember that the offsets into the name table wrap after 8K, so when games set weird sizes like 128x128 or 64x128, the real playfield size is truncated. E.g. 128x128 becomes 128x32, 64x128 becomes 64x64, and so on.
I assume you have some kind of debugging feature where you can see the tilemaps and verify the missing data is really present in the name table, and it's just the scrolling that is wrong?
Gunstar Heroes also uses it in Black's base to wiggle the repeating background pattern and on the option screen background to curve the horizon if you want other locations to check.
I guess I'd look how the offset into the name table is calculated for column scrolling and verify it isn't going out of bounds. As a reference remember that the offsets into the name table wrap after 8K, so when games set weird sizes like 128x128 or 64x128, the real playfield size is truncated. E.g. 128x128 becomes 128x32, 64x128 becomes 64x64, and so on.
I assume you have some kind of debugging feature where you can see the tilemaps and verify the missing data is really present in the name table, and it's just the scrolling that is wrong?
Thanks for the info. Adding debugging features is exactly what we are doing. I think you are right. Some kind of sprite and tile browser is what we need.
(OT):
This week we have been adding VDP debugging features.
We have added the ability to turn on and off planes and sprites. Zamaz just send me a diff that implements sprite boxing, which I am quite excited by for some reason.
Check it out:
It's really interesting to see how the games are cobbled together
(OT):
This week we have been adding VDP debugging features.
We have added the ability to turn on and off planes and sprites. Zamaz just send me a diff that implements sprite boxing, which I am quite excited by for some reason.
Check it out:
It's really interesting to see how the games are cobbled together
Re: Vertical Scroll VDP bug in Dgen, any ideas?
Well it would appear that this is certainly a problem in dgen/sdl. If we (zamaz and I) understand you correctly, this logic (is it correct) should fix that:Charles MacDonald wrote: I guess I'd look how the offset into the name table is calculated for column scrolling and verify it isn't going out of bounds. As a reference remember that the offsets into the name table wrap after 8K, so when games set weird sizes like 128x128 or 64x128, the real playfield size is truncated. E.g. 128x128 becomes 128x32, 64x128 becomes 64x64, and so on.
Code: Select all
if ((xsize * ysize) > 4096)
ysize = (4096 / xsize);
Code: Select all
32x64 would give 32x64
32x128 would give 32x128
64x32 would give 64x32
64x64 would give 64x64
64x128 would give 64x64
128x32 would give 128x32
128x64 would give 128x32
128x128 would give 128x32
However, the problems I describe do not appear to be affacted by this change, so perhaps we are looking at something else here?
Hmmmm....
The above change badly breaks Street Racer and Sonic 3 (probably others too).
FWIW, here is the code that we are dealing with:
http://dgen.git.sourceforge.net/git/git ... .h;hb=HEAD
It is not pretty I warn you. It's a header file that is included with various different macros set so as to re-use code. Why the original author did not use functions, I don't know.
FWIW, here is the code that we are dealing with:
http://dgen.git.sourceforge.net/git/git ... .h;hb=HEAD
It is not pretty I warn you. It's a header file that is included with various different macros set so as to re-use code. Why the original author did not use functions, I don't know.
So, I seem to have fixed this issue by implementing column scrolling mode in the VDP.
However, there are a couple of thiings which don't match up with the VDP docs. Namely, it seems that something strange happens with the leftmost columns. Digging in the genplus gx code, I found the following comment in vdp_render.c
Can anyone explain this to me?
Does anyone know any other corner cases related to vscroll?
For the brave, here is my diff that implements column vscroll in dgen:
https://sourceforge.net/tracker/?func=d ... id=1070826
I am not sure it is 100% correct...
However, there are a couple of thiings which don't match up with the VDP docs. Namely, it seems that something strange happens with the leftmost columns. Digging in the genplus gx code, I found the following comment in vdp_render.c
Code: Select all
/* Left-most column vertical scrolling when partially shown horizontally */
/* Same value for both planes, only in 40-cell mode, verified on PAL MD2 */
/* See Gynoug, Cutie Suzuki no Ringside Angel, Formula One, Kawasaki Superbike Challenge */
Does anyone know any other corner cases related to vscroll?
For the brave, here is my diff that implements column vscroll in dgen:
https://sourceforge.net/tracker/?func=d ... id=1070826
I am not sure it is 100% correct...
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
I think the problem has to do with the way horizontal scrolling is implemented internally. The VDP renders 2 extra columns before the first column of the display. If the low 4-bits of the horizontal scroll value are zero, these extra columns are completely unused. Otherwise a portion of them is borrowed when displaying the first two columns. I don't know where the vertical scroll value for the two extra columns come from, but I would guess it's either effectively column 62/63 (in which case it's probably always zero since that's out of bounds for VSRAM) or 38/39.
That's mostly conjecture based on VRAM access patterns. I plan on doing some tests soon to confirm (unless Nemesis or someone else has beaten me to it anyway).
That's mostly conjecture based on VRAM access patterns. I plan on doing some tests soon to confirm (unless Nemesis or someone else has beaten me to it anyway).
-
- Very interested
- Posts: 292
- Joined: Sat Apr 21, 2007 1:14 am
Re: Vertical Scroll VDP bug in Dgen, any ideas?
Err, uh, just read data from the name table with the offset wrapping at 8K, like this:Right?
Dragon Slayer I and II rely on it.uint16 data = vram[(table_base & 0xE000) + (offset & 0x1FFF)];
About that first column, we had a thread about it earlier:
viewtopic.php?t=737&postdays=0&postorder=asc&start=30
Eke describes how column 0 behaves in both width settings.