Page 2 of 8

Re: Critical Ocean Hunter issue

PostPosted: Thu Mar 16, 2017 1:10 pm
by MakutaMaster962
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.

Re: Critical Ocean Hunter issue

PostPosted: Mon Mar 20, 2017 9:01 am
by Bart
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

Re: Critical Ocean Hunter issue

PostPosted: Sat Apr 01, 2017 1:44 pm
by MakutaMaster962
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?

Re: Critical Ocean Hunter issue

PostPosted: Sat Apr 01, 2017 2:06 pm
by Bart
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.

Re: Critical Ocean Hunter issue

PostPosted: Sat Apr 01, 2017 3:28 pm
by Ian
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.

Re: Critical Ocean Hunter issue

PostPosted: Thu Apr 13, 2017 10:45 am
by Ian
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.

Re: Critical Ocean Hunter issue

PostPosted: Thu Apr 13, 2017 12:55 pm
by Bart
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.

Re: Critical Ocean Hunter issue

PostPosted: Thu Apr 13, 2017 1:24 pm
by HarryTuttle
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 435 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.

Re: Critical Ocean Hunter issue

PostPosted: Thu Apr 13, 2017 1:56 pm
by HarryTuttle
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 429 times

Left: arcade, Right: Supermodel
oh02.jpeg
oh02.jpeg (224.82 KiB) Viewed 429 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.

Re: Critical Ocean Hunter issue

PostPosted: Thu Apr 13, 2017 2:07 pm
by Ian
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.