[Patch] Sun Shading

[HarryTuttle]

Where does spikeout use unsigned (0-255) fixed shading?

Sorry Ian, I misunderstood your first question, Spikeout doesn't have fixed shaded polygons, at least for what I saw. It's just that it doesn't use signed shade intensity. I'm now used to consider those signed/unsigned and clamp global settings valid for both NdotL and fixed shaded models.

[Bart]

I too believe there's some initialization settings done at beginning. Reading the devguide there're Device functions, like gamma settings, background color and other frame rate related ones. Maybe they used some undocumented function to tweak the light model math.

If you look at Real3D.cpp's texture upload code there is a comment about a texture type that was once thought to be a gamma table. However, the games never upload it. It was either an error on Ville's part when he noticed it or there is some other emulation bug in Supermodel preventing the games from uploading it.

The Fighting Vipers' init routine I posted the other day accesses the video board through the TAP device but I'm not sure what for and frankly, I don't think it's worth the time and effort to reverse engineer that function. The TAP interface can literally be used for anything the ASIC designers wanted. Usually it's intended for testing internal chip functionality but it can just as easily provide an interface to modify internal registers that are not exposed outside of the chip. We can maybe log what's being written to the TAP at that point (and check to see if it's reading anything and performing a test) if anyone deems it worthwhile. The problem is that it's going to be some nightmarish bit-stream and even if there is a setting in there, it could literally be anywhere. I would imagine that this procedure will look different from game to game and it will be hard to pick out what's going on.

[Bart]

That said... I now recall that in order to get my Model 3 code to boot on the real device, I actually had to write to the TAP port. I wasn't able to get the display to do anything until I did. What I ended up doing is dumping everything VF3 wrote and then duplicated those values. Some were obviously for testing and verification, and I removed those, but there is a lot there that is completely indecipherable in its purpose. If you'd like to see what it looks like, it's here, at the bottom, in jtag_init().

[HarryTuttle]

Ian, to recap, initial GPU configuration can be simulated with something like this:

Code: Select all

m_shadeIsSigned = false;
m_shadeFloorClamp = true;

// For these games Real3D treats shade as signed float
if (0
      // All step 1.5 games
      || m_gameName == "lemans24"
      || m_gameName == "lostwsga"
      || m_gameName == "scud"
      || m_gameName == "scuda"
      || m_gameName == "scudj"
      || m_gameName == "scudplus"
      || m_gameName == "vs215"
      || m_gameName == "vs215o"
      || m_gameName == "vs29815"
      || m_gameName == "vs29915"
      // Some step 2.x games
      || m_gameName == "dayto2pe"
      || m_gameName == "dirtdvls"
      || m_gameName == "dirtdvlsa"
      || m_gameName == "lamachin"
      || m_gameName == "magtruck"
      || m_gameName == "von2"
      || m_gameName == "von254g"
      || m_gameName == "von2a"
    ) {
   m_shadeIsSigned = true;
}

// For these games Real3D doesn't clamp shade floor values to zero
if (0
      // Some step 2.x games
      || m_gameName == "dayto2pe"
      || m_gameName == "lamachin"
      || m_gameName == "von2"
      || m_gameName == "von254g"
      || m_gameName == "von2a"
    ) {
   m_shadeFloorClamp = false;
}


Then the "get FixedShade" code can be summarized with this:

Code: Select all

#define INT8_TO_FLOAT(B) ((2.0f * (float)(B) + 1.0f) * (1.0f / 255.0f))
#define UINT8_TO_FLOAT(B) ((float)(B) * (1.0f / 255.0f))

if (ph.FixedShading()) {

   //==========
   float shade;
   //==========

   if (m_shadeIsSigned) {
      shade = INT8_TO_FLOAT((INT8)(ix & 0xFF));
   }
   else {
      shade = UINT8_TO_FLOAT((UINT8)(ix & 0xFF));
   }

   p.v[j].fixedShade = shade;                        // hardware doesn't really have per vertex colours, only per poly
}


Do you agree?

[Ian]

My code looks very similar
I need to test star wars with fixed shading to see if it does specular with it

[HarryTuttle]

I need to test star wars with fixed shading to see if it does specular with it

I think it does. I've checked today those polys, they're: Fixed Shaded & Flat Shaded & LightEnabled & SpecularEnabled. An interesting combination, consider that normally we've seen a lot of those type of polygons, the only difference being Sun Shaded instead of Fixed Shaded.

There're two problems however:
1) specular on flat shaded polys is currently broken, I'm still unsure how is really done;
2) we lack some good quality direct capture of SWT to compare with. Maybe icuk7...

[Bart]

There is a Star Wars machine here in New York but sadly, I wouldn't be able to get any better than a cell phone video of it.

[Ian]

Harry with flat shading have you tried storing the normal as a signed byte to essentially lose the extra precision, since the normals only get that much precision normally.

[HarryTuttle]

Harry with flat shading have you tried storing the normal as a signed byte to essentially lose the extra precision, since the normals only get that much precision normally.

Sorry Ian, I'm afraid I've not understood what you mean. Normals are already signed bytes in New3D.cpp.

EDIT:
You mean the polygon normal?

[Ian]

Yes in flat shading the normal comes from the 24bit polygon normal in the poly header. With regular lighting it comes from the 8bit values packed next to the vertex data. Maybe the hw is itself copying the poly normal to the vertex attributes thus reducing it's precision