Vertical Scroll VDP bug in Dgen, any ideas?

[vext01]

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

[Charles MacDonald]

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?

[vext01]

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

[vext01]

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.

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:

Code: Select all

  if ((xsize * ysize) > 4096)                                                   
      ysize = (4096 / xsize);

This is saturation, not truncation. This means:

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

Right?

However, the problems I describe do not appear to be affacted by this change, so perhaps we are looking at something else here?

Hmmmm....

[vext01]

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.

[vext01]

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

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 */

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...

[Stef]

There is a bug in genesis VDP (only fixed in genesis 3 VA3 as far i remember) which affect the column scroll mode.
The leftmost column is not affected by scroll table value as it should be, don't remember the details but i believe that only a few bits from the real value is taken in account.

[Mask of Destiny]

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).

[Charles MacDonald]

Right?

Err, uh, just read data from the name table with the offset wrapping at 8K, like this:

uint16 data = vram[(table_base & 0xE000) + (offset & 0x1FFF)];

Dragon Slayer I and II rely on it.

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.