2-cell vertical scrolling + horizontal scrolling

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

sheath
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Mon May 17, 2010 11:46 pm

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
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Tue May 18, 2010 3:21 pm

Chilly Willy wrote:Why? Specifically coded effects for small on-the-rail sections of a game do not equal generic true 3D polygons. :lol:
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
Newbie
Posts: 9
Joined: Wed Apr 07, 2010 6:00 pm
Location: Linköping, Sweden

Post by TheMVRules » Wed May 19, 2010 3:27 pm

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. :)
Sega Genesis Mr. Knows All

Huge
Very interested
Posts: 197
Joined: Sat Dec 13, 2008 11:50 pm

Post by Huge » Wed May 19, 2010 6:00 pm

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

HardWareMan
Very interested
Posts: 732
Joined: Sat Dec 15, 2007 7:49 am
Location: Kazakhstan, Pavlodar

Post by HardWareMan » Thu May 20, 2010 3:45 am

TheMVRules wrote: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
Very interested
Posts: 141
Joined: Wed Aug 15, 2007 1:44 pm
Location: Texas
Contact:

Post by sheath » Thu May 20, 2010 5:47 am

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
Very interested
Posts: 3034
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu May 20, 2010 11:40 am

sheath wrote: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
Very interested
Posts: 859
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Re: 2-cell vertical scrolling + horizontal scrolling

Post by Eke » Thu Jun 10, 2010 1:07 pm

TascoDLX wrote:
Charles MacDonald wrote: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
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Re: 2-cell vertical scrolling + horizontal scrolling

Post by fox68k » Thu Jul 29, 2010 1:26 pm

Eke wrote:
TascoDLX wrote:
Charles MacDonald wrote: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
Very interested
Posts: 859
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Thu Jul 29, 2010 1:44 pm

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
Very interested
Posts: 859
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Fri Jul 30, 2010 9:59 am

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
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Post by fox68k » Fri Jul 30, 2010 12:01 pm

Eke wrote: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
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Post by fox68k » Fri Jul 30, 2010 12:56 pm

Eke wrote: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
Very interested
Posts: 859
Joined: Wed Feb 28, 2007 2:57 pm
Contact:

Post by Eke » Fri Jul 30, 2010 1:20 pm

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
Interested
Posts: 13
Joined: Wed Apr 01, 2009 1:22 pm

Post by fox68k » Sun Aug 01, 2010 5:57 pm

Just for the record, Cuty works fine on 1.3.0.
Eke wrote: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

Post Reply