[Patch] Sun Shading

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!

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 10:29 am

Ian wrote: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.
User avatar
HarryTuttle
 
Posts: 481
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Bart » Fri Aug 18, 2017 10:37 am

HarryTuttle wrote: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.
User avatar
Bart
Site Admin
 
Posts: 1995
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: [Patch] Sun Shading

Postby Bart » Fri Aug 18, 2017 10:40 am

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().
User avatar
Bart
Site Admin
 
Posts: 1995
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 11:44 am

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?
User avatar
HarryTuttle
 
Posts: 481
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 1:54 pm

My code looks very similar :)
I need to test star wars with fixed shading to see if it does specular with it
Ian
 
Posts: 1120
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 2:35 pm

Ian wrote: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... :)
User avatar
HarryTuttle
 
Posts: 481
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Bart » Fri Aug 18, 2017 4:03 pm

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.
User avatar
Bart
Site Admin
 
Posts: 1995
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 4:03 pm

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.
Ian
 
Posts: 1120
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 4:29 pm

Ian wrote: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?
User avatar
HarryTuttle
 
Posts: 481
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Sat Aug 19, 2017 7:17 am

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
Ian
 
Posts: 1120
Joined: Tue Feb 23, 2016 9:23 am

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 3 guests