Sega bass fishing - bad polys

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
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!

Sega bass fishing - bad polys

Postby Ian » Sun Sep 02, 2018 5:44 am

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.

And this

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

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

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.

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

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

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

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.

And let's see what it looks like

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.


Nice :) And that is how I fixed this bug.
Posts: 1647
Joined: Tue Feb 23, 2016 9:23 am

Re: Sega bass fishing - bad polys

Postby sonic32 » Sun Sep 02, 2018 11:34 pm

Great Works Ian, Thanks :o
User avatar
Posts: 124
Joined: Tue Dec 20, 2011 11:43 am
Location: Slovakia

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 3 guests