Critical Ocean Hunter issue

Having technical difficulties with Supermodel? Last-minute wardrobe malfunction? Get help here.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Re: Critical Ocean Hunter issue

Postby MakutaMaster962 » Thu Mar 16, 2017 1:10 pm

Ian wrote:It should definitely work.

OK, but I'm afraid I'll need some very detailed instructions on how to do this(a few screenshots included would also be nice). I'm currently running Supermodel 3 through EmuLoader version 8.2.9(just as an FYI).

EDIT: Well anyway, please keep me informed if/when you manage to make progress on fixing this issue, since Ocean Hunter isn't as enjoyable without the background fog effects, among other things.
MakutaMaster962
 
Posts: 14
Joined: Wed Mar 08, 2017 7:50 am

Re: Critical Ocean Hunter issue

Postby Bart » Mon Mar 20, 2017 9:01 am

Change "New3DEngine=1" to "New3DEngine=0" in the config file. You can also make this specific to Ocean Hunter by putting it in its own section:

Code: Select all
[oceanhun]
New3DEngine = 0
User avatar
Bart
Site Admin
 
Posts: 1827
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Critical Ocean Hunter issue

Postby MakutaMaster962 » Sat Apr 01, 2017 1:44 pm

Bart wrote:Change "New3DEngine=1" to "New3DEngine=0" in the config file. You can also make this specific to Ocean Hunter by putting it in its own section:

Code: Select all
[oceanhun]
New3DEngine = 0


:? Uh, but didn't you and/or Ian say some time ago, that development on the Legacy renderer for the emulator had stopped in favor of working on Ian's New 3d Engine?

Anyway, like I said a couple of weeks ago, playing Ocean Hunter with the Legacy renderer isn't as enjoyable as playing with the New 3d renderer.

See what I mean?
Attachments
oceanhun(New 3D engine).jpg
oceanhun(New3D engine)
oceanhun(New 3D engine).jpg (89.15 KiB) Viewed 263 times
oceanhun(Legacy 3D engine).jpg
oceanhun(Legacy 3D engine)
oceanhun(Legacy 3D engine).jpg (106.9 KiB) Viewed 263 times
MakutaMaster962
 
Posts: 14
Joined: Wed Mar 08, 2017 7:50 am

Re: Critical Ocean Hunter issue

Postby Bart » Sat Apr 01, 2017 2:06 pm

Unfortunately, we will have to just wait patiently until it is fixed. Ian has been doing an enormous amount of work and he's looking into all kinds of challenging stuff now, so let's appreciate that.
User avatar
Bart
Site Admin
 
Posts: 1827
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Critical Ocean Hunter issue

Postby Ian » Sat Apr 01, 2017 3:28 pm

Ocean hunter is full of funky issues like this. It might be because we trying to render data that shouldn't be rendered. Virtua fighter and Harley have similar issues. I've never spent much time looking at the issue. Could be a corner case bug in our node processing code.
Ian
 
Posts: 836
Joined: Tue Feb 23, 2016 9:23 am

Re: Critical Ocean Hunter issue

Postby Ian » Thu Apr 13, 2017 10:45 am

I had a bit more of a debug of this issue
Basically we are drawing bang in the middle of the memory being updated

Image

Swap = swap buffers

Hence the matrices are all trash. Daytona has the same issue. I really think that mame has the correct idea with the timing. The status bit is 1, during the v-blank period. Currently we are just flipping this thing randomly. It should be flipped back to zero after the vblank period. But currently we have wait till the next frame in order for that bit to be reset.
Ian
 
Posts: 836
Joined: Tue Feb 23, 2016 9:23 am

Re: Critical Ocean Hunter issue

Postby Bart » Thu Apr 13, 2017 12:55 pm

Ian wrote:I had a bit more of a debug of this issue
Basically we are drawing bang in the middle of the memory being updated

Image

Swap = swap buffers

Hence the matrices are all trash. Daytona has the same issue. I really think that mame has the correct idea with the timing. The status bit is 1, during the v-blank period. Currently we are just flipping this thing randomly. It should be flipped back to zero after the vblank period. But currently we have wait till the next frame in order for that bit to be reset.


That's what we currently do. The bit is flipped only once per frame. Check out CReal3D::BeginVBlank(). Are you sure that the write to 0x88000000 isn't the bigger issue? Presumably, after the game finishes writing to memory, it triggers a frame update. We would need to sync to that.
User avatar
Bart
Site Admin
 
Posts: 1827
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: Critical Ocean Hunter issue

Postby HarryTuttle » Thu Apr 13, 2017 1:24 pm

I've spot a couple of other things in Ocean Hunter.

The first is a fog issue, it really is a general fog emulation issue, but in Ocean hunter is more visible. Currently it should be done per pixel and not per vertex. In future with properly emulated quads (not only texture coordinates, but also vertex color and normal) maybe it could be no more necessary. However here it is:

Left: arcade; middle: Supermodel's bad fog, right: Supermodel's correct fog
oh01.jpeg
oh01.jpeg (219.4 KiB) Viewed 152 times

You can see that per vertex calculation, being less precise, reveals more objects in distance where they should be already fogged instead. In particular, on the left part of the middle image, you can see a fully fogged column base standing on a not fully fogged sand plane.

For the second issue I'll post later, I'm preparing some screenshots.
Last edited by HarryTuttle on Thu Apr 13, 2017 2:11 pm, edited 1 time in total.
User avatar
HarryTuttle
 
Posts: 295
Joined: Thu Mar 09, 2017 8:57 am

Re: Critical Ocean Hunter issue

Postby HarryTuttle » Thu Apr 13, 2017 1:56 pm

The second issue, again a general one but in this game is more visible, is a vertex normal issue (gl_Normal in vertex shader) or maybe the normal matrix passed (gl_NormalMatrix in vertex shader).

The problem is that the vertex normal components, if I understood how things work in 3D, should be in the interval -1 to 1, however for some model this is not the case, they go way beyond and, as you can see in the images below, some model has a very bright shade.

And that's not all, in these examples the effect is mitigated by the fact that I always normalize the vertex direction vector (gl_NormalMatrix * gl_Normal), not doing so those models will be grossly overbrighten.

In theory normalization should not be necessary if the normal xyz components lie in the above interval, and they should produce a correct shade intensity.

Left: arcade, Right: Supermodel
oh01.jpeg
oh01.jpeg (196.46 KiB) Viewed 146 times

Left: arcade, Right: Supermodel
oh02.jpeg
oh02.jpeg (224.82 KiB) Viewed 146 times


Finally, as a test, in vertex shader I've added something like this pseudo-code:
Code: Select all
if (length(vertexDirectionNormal) > one) {
  vertexDirectionNormal *= 0.1;
}

And the sunlight shade was very much in line with arcade counterpart.
User avatar
HarryTuttle
 
Posts: 295
Joined: Thu Mar 09, 2017 8:57 am

Re: Critical Ocean Hunter issue

Postby Ian » Thu Apr 13, 2017 2:07 pm

About the fog, it would have definitely been done per vertex. However with the hardware nativity probably rendering quads that complicates attribute interpolation.

Bart when games sync with the status bit, they do this
00000001110
They keep polling until it flips back to 0 again. So when vblank ends.

This is impossible for us. The bit only flips back to 0 when a new 'frame' starts. I think this is why our timing is messed up.
Also we probably should swap our own buffers at that point when we say vblank happens.
Ian
 
Posts: 836
Joined: Tue Feb 23, 2016 9:23 am

PreviousNext

Return to The Fitting Room

Who is online

Users browsing this forum: No registered users and 2 guests