19

Sega bass fishing - bad polys

 6 years ago
source link: https://www.tuicool.com/articles/hit/YN3aYn3
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Not sure if this is too technical or not .. but this is how I found/fixed this particular issue.

Sega bass fishing is honestly not a game I've ever really played, other than letting attract mode run. I spotted this particular bad poly issue in a video Tadex made about the game on youtube.

Oh god what is this.

aQnAFvF.jpg!web

And this

2MfeArz.jpg!web

Original thoughts were it might either bad matrices or some kind of floating point NaN bug in the cpu emulator. Daytona has a matrix bug caused by the matrices not being completely sent before the game starts to reference them due to some timing issue.

Checking the matrices everything looks okay

na6jqmB.png!web

Next step is to check the actual vertex data in the meshes and check everything looks okay.

VzYzA33.png!web

Nothing out of the ordinary showed up.. Hm how to find this bad poly. Okay .. let's make a few simple modifications to the code and turn the renderer into a colour picker. Many opengl CAD programs that do object selection draw each object in a unique colour then read back this value at mouse x/y location. They do this on the back buffer, then the results are cleared so you never see them. We can do the same just in a more visible fashion.

Drawing each poly in a unique colour gives us this.

3Q7VneJ.png!web

Use good old MS paint to find this bad poly number based upon its colour

vIFRFbQ.png!web

82, 2, 0

Okay let's put a breakpoint in the code for this condition so I can see these bad polys.

za6VZnr.png!web

Finally I can see what's going on. The first vertex (x/y/z position) is uninitialised.

IrMNzaJ.png!web

Why? Because the first vertex in the mesh has the sharing attribute set. This means it shares the vertex data from the previous polygon. But there is just one problem, it's the first polygon in the mesh! It can't share with anything. So this poly is clearly illegal, but the h/w draws it normally anyway. How?? Hmm ...

First idea was that the hardware could start by zeroing the shared poly data, so instead of random garbage it initialises to 0.

EbYJ3iV.png!web

And let's see what it looks like

E3aQNz3.jpg!web

Nope, still broken.

Hmm, I wonder if it could be sharing vertex data ... with the previous mesh. Insane but who not. In our code the shared values live on the stack in the local function. As soon as the function has returned these values are gone. I doubt the HW works like this. Anyway let's try simply moving the shared data out of the function and just make it global.

iq2Mf2R.jpg!web Nice eEv6Vnn.gif

And that is how I fixed this bug.


Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK