2-cell vertical scrolling + horizontal scrolling

[sheath]

There are a few obvious differences between the F1/Kawasaki engine and the SVP VR engine.

In favor of VR, we have on the fly view changes, accurate race replays from numerous angles, and fully 3D car models in all modes.

In favor of F1/Kawasaki, we have consistently higher framerates, and a "turbo mode" that makes it all run even faster with less detal.

We are also comparing Genesis hardware versus a chipped game that cost $100 on its own. Also, in the US I never heard of the F1/Kawasaki game whereas Virtua Racing was competing with Mario Kart for popularity. For "traditional" 2D racer simulations, the F1/Kawasaki games are unsurpassed save Super Monaco GP.

For "fully" polygonal 3D, Virtua Racing on Genesis is only surpassed by Virtua Racing Deluxe on 32X and then VR on Saturn.

[Huge]

Why? Specifically coded effects for small on-the-rail sections of a game do not equal generic true 3D polygons.

I only watched the youtube videos, I did not try the game. If they are indeed effects and not actual 3d (hard to imagine how they would do that, based on the videos alone), then that is just the more impressive. It would absolve VR and leave it at the dust at the same time.

[TheMVRules]

Some other real polygon 3D games for the MD are are Hard Drivin', Race Drivin', F-15 Strike Eagle II, F-16 Interceptor and F-117 Night Storm. However those games runs in 10-15 FPS, that's without extra processors but it's still impressing for a home console system manufactured in 1988.

[Huge]

Ex-Ranza (Ranger X) has wireframe polygon cutscenes.

[HardWareMan]

Some other real polygon 3D games for the MD are are Hard Drivin', Race Drivin', F-15 Strike Eagle II, F-16 Interceptor and F-117 Night Storm. However those games runs in 10-15 FPS, that's without extra processors but it's still impressing for a home console system manufactured in 1988.

How about MIG29?

[sheath]

Piecemealing the list won't cause this thread to end soon if it is going to remain on the topic of polygons. But I'll toss two in:

Abrams M1 Battletank
LHX Attack Chopper

As has been mentioned in this thread, these games very notably run in the 5-10 frames per second range, but also manage to play very well.

[Stef]

Piecemealing the list won't cause this thread to end soon if it is going to remain on the topic of polygons. But I'll toss two in:

Abrams M1 Battletank
LHX Attack Chopper

As has been mentioned in this thread, these games very notably run in the 5-10 frames per second range, but also manage to play very well.

More 5 FPS than 10 FPS i would say, but again that's not that bad when we think about the 7.7Mhz 68000 and the tile video processor which is really mis-designed to do that type of "bitmap" rendering.

[Eke]

Just curious, are you testing this with Genesis Plus? I did a lot of research to make sure the leftmost column scrolled like it does on the real hardware for 40 cell mode. But now that I think about it, I may have not tested 32-cell mode and assumed the same rules apply...

I checked. Genesis Plus works fine for Kawasaki (32-cell) but not for Gynoug (40-cell) -- partial column on the left is wrong.

Just so it's clear, Kawasaki (and presumably F1) renders one or two cell-wide columns of patterns with some vertical offset, likely based on the current scroll values (i.e., it's altering the pattern not the scroll values). I haven't seen the code yet, but it's clearly compensating for a predictable bug.

Eke, I like your theory about the unused VSRAM entries in 32-cell mode. It might be worth checking out.

Ok, just to clear up, now that I have my Everdrive MD (wonderful piece of hardware btw), I have tested those 3 games to see exactly how they behave and surprisingly, Gynoug indeed has its left column dismissed when vertical+horizontal scrolling happens.

So this means that all current emulators (well except the good old genesis plus) are wrong and that the VDP does not apply vertical scroll to the left-most column when it is partially displayed.

[fox68k]

Just curious, are you testing this with Genesis Plus? I did a lot of research to make sure the leftmost column scrolled like it does on the real hardware for 40 cell mode. But now that I think about it, I may have not tested 32-cell mode and assumed the same rules apply...

I checked. Genesis Plus works fine for Kawasaki (32-cell) but not for Gynoug (40-cell) -- partial column on the left is wrong.

Just so it's clear, Kawasaki (and presumably F1) renders one or two cell-wide columns of patterns with some vertical offset, likely based on the current scroll values (i.e., it's altering the pattern not the scroll values). I haven't seen the code yet, but it's clearly compensating for a predictable bug.

Eke, I like your theory about the unused VSRAM entries in 32-cell mode. It might be worth checking out.

Ok, just to clear up, now that I have my Everdrive MD (wonderful piece of hardware btw), I have tested those 3 games to see exactly how they behave and surprisingly, Gynoug indeed has its left column dismissed when vertical+horizontal scrolling happens.

So this means that all current emulators (well except the good old genesis plus) are wrong and that the VDP does not apply vertical scroll to the left-most column when it is partially displayed.

Hi Eke,

there is yet another game with this issue. It is Cutie Suzuki no Ringside Angel.
When a fighter falls out to the left side of ring, the first column gets misaligned. By adding the first VSRAM entry, it looks fine. However, the scrolling values (6, 12) indicate fine scrolling should be applied and therefore the entry is not used. It works fine on GPGX 1.3.0, but not on 1.4.0. I have tried the game on a japanese MD-1 and the first column is aligned.

Could you please investigate what is going on?

Thank you.

[Eke]

According to the code, it does not seem 1.3.0 applied vertical scroll value to the left column when fine horizontal scrolling is used. Did you tried Gynoug on this old version as well ? If left column is disfigured in this one but not in that other game, then it's probably a bug somewhere else in current code

EDIT: I verified and this game displays corrupted column when characters get out of the ring (both side), in any version of genesis plus so it's definitively something related to vscroll. I also verified that this game works fine on my MD2 while gynoug is displaying a corrupted column.
This is very weird as the game does not seem to do anything special or different than Gynoug (it uses H40 as well by the way, but uses fullscreen hscrolling while Gynoug uses line-by-line hscrolling). I tried different combinations (scroll value only applied to one plane, etc), without success, I think this is some kind of VDP feature that works differently under very specific condition (maybe the range for hscroll fine value ?) that we have yet to figure

[Eke]

One thing I noticed about the wrestling game is that it uses two 64x64 planes in a way that plane A is for the left character playground, while Plane B is for the right character. The 2 planes are horizontally scrolled independently and can overlap (with A being displayed over).

Now, the interesting thing is that, if you look at the written VSRAM values:

- column 0-9 of plane A all have the same value, which is the same as value for column 10-19 of plane B. The value used is in range 0-? and is incremented by 2 each frame when vertical scrolling is required.

- column 0-9 of plane B all have the same value, which is the same as value for columns 10-19 of plane A. The value used is always the value used above + 0x100

Basically, this is used to display black pixels on the left side of plane B and the right side of plane A.


Now, my theory:

Maybe the VDP is parsing VSRAM backward when looking for partial left-column vscroll value (since technically, it's column -1) : first it gets VSRAM last entry (plane B column 19) for plane A, then gets VSRAM next to last entry (plane A column 19) for plane B. In that case, this would work just fine with this game.

Gynoug, on the opposite, uses different vscroll values for each column (plane A and plane B) to create some kind of wave effect. Emulating the above behavior still make the left-most column being incorrectly scrolled when partially visible. Also, if you look at this game carefully on real hardware, when the left column is dismissed, the vscroll value is not fixed which confirms that the VDP still apply some kind of scrolling (and it seems similar to the last column of plane B vscroll, plane B being the water background, but I could not tell for sure)

In games using H32 mode (Formula One, Kawasaki Super Bike), those two last VSRAM entries are unused and remain cleared, which will disable vertical scroll for the left-most column and games would display fine.

[fox68k]

According to the code, it does not seem 1.3.0 applied vertical scroll value to the left column when fine horizontal scrolling is used. Did you tried Gynoug on this old version as well ? If left column is disfigured in this one but not in that other game, then it's probably a bug somewhere else in current code

EDIT: I verified and this game displays corrupted column when characters get out of the ring (both side), in any version of genesis plus so it's definitively something related to vscroll. I also verified that this game works fine on my MD2 while gynoug is displaying a corrupted column.
This is very weird as the game does not seem to do anything special or different than Gynoug (it uses H40 as well by the way, but uses fullscreen hscrolling while Gynoug uses line-by-line hscrolling). I tried different combinations (scroll value only applied to one plane, etc), without success, I think this is some kind of VDP feature that works differently under very specific condition (maybe the range for hscroll fine value ?) that we have yet to figure

I was not sure about the right side, that is why i stated just left to avoid confusion.
I have not tried Gynoug on the old version, but it probably works as expected as GP implements this properly as you said in another post. I will check anyway.

[fox68k]

One thing I noticed about the wrestling game is that it uses two 64x64 planes in a way that plane A is for the left character playground, while Plane B is for the right character. The 2 planes are horizontally scrolled independently and can overlap (with A being displayed over).

Now, the interesting thing is that, if you look at the written VSRAM values:

- column 0-9 of plane A all have the same value, which is the same as value for column 10-19 of plane B. The value used is in range 0-? and is incremented by 2 each frame when vertical scrolling is required.

- column 0-9 of plane B all have the same value, which is the same as value for columns 10-19 of plane A. The value used is always the value used above + 0x100

Basically, this is used to display black pixels on the left side of plane B and the right side of plane A.


Now, my theory:

Maybe the VDP is parsing VSRAM backward when looking for partial left-column vscroll value (since technically, it's column -1) : first it gets VSRAM last entry (plane B column 19) for plane A, then gets VSRAM next to last entry (plane A column 19) for plane B. In that case, this would work just fine with this game.

Gynoug, on the opposite, uses different vscroll values for each column (plane A and plane B) to create some kind of wave effect. Emulating the above behavior still make the left-most column being incorrectly scrolled when partially visible. Also, if you look at this game carefully on real hardware, when the left column is dismissed, the vscroll value is not fixed which confirms that the VDP still apply some kind of scrolling (and it seems similar to the last column of plane B vscroll, plane B being the water background, but I could not tell for sure)

In games using H32 mode (Formula One, Kawasaki Super Bike), those two last VSRAM entries are unused and remain cleared, which will disable vertical scroll for the left-most column and games would display fine.

I have put your theory in practice and it does work for Cuty, Gynoug and F1. Also, it does make sense to me it is wrapping VSRAM accesses.

[Eke]

yes, I did too and Gynoug seems to display more like real hardware now as well, we would need some test program to be sure but for the moment I would make as if this theory is accurate.

just curious, are you working on the DC port or is it another emulator project ?

[fox68k]

Just for the record, Cuty works fine on 1.3.0.

just curious, are you working on the DC port or is it another emulator project ?

It is a Gens port for DC. Needless to say, yours is the most accurate Genesis emulator ever and it is very fast as well. Simply brilliant. But i did not know about your project when i started. shrug