[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 Ian » Thu Aug 17, 2017 4:16 pm

Harry,
do you have any examples on step 2.0 h/w where the fixedshade value is not zero ?
I tried that virtua on game and it only seems to use 0
Ian
 
Posts: 1638
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Thu Aug 17, 2017 4:24 pm

Ian wrote:I tried that virtua on game and it only seems to use 0


That game uses signed and unclamped shade, so behaves like Machineguns. Once I added global GPU configuration bits in my build, and after I've tested all the games, I've compiled <New3D.cpp> with this (extract):
Code: Select all
   m_shadeIsSigned = false;
   m_shadeFloorClamp = true;

   // For these games Real3D treats shade as signed float
   if (0
       || 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
       || m_gameName == "dayto2pe"
       || m_gameName == "lamachin"
       || m_gameName == "von2"
       || m_gameName == "von254g"
       || m_gameName == "von2a"
      ) {
      m_shadeFloorClamp = false;
   }

As you can see I set some defaults then add all the exceptions.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 1:25 am

// For these games Real3D treats shade as signed float


You can add scud to that list as well, since it's max value is 127 not 255.

Am I correct that only star wars uses unsigned values? Is it also true that only star wars sets the specular flag on those polys?
Ian
 
Posts: 1638
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 6:56 am

Ian wrote:You can add scud to that list as well, since it's max value is 127 not 255.

That list is meaningful only for step 2.x because only that hw revision seems to be capable to do that. Step 1.5 doesn't have signed float, the 127 is treated as "1", I also had visually confirmed that behavior, if you force it as-signed you'll have a lot of (wrong) black polygons in Scud (incidentally I tried that yesterday).

EDIT (regarding Scud, and step 1.5 fixedShade intensity):
Code: Select all
shade = (float)(ix & 0x7F) / 127.0f;

That's from <New3D.cpp>. Notice the 0x7F, I've verified that shade value never goes beyond 127. So it can't be an unsigned byte treated as signed. I remember also that you've disassembled the fixed shade function for step 1.5 and checked that value.

That's why I initially set those two sane default that go well for almost every case...
Code: Select all
m_shadeIsSigned = false;
m_shadeFloorClamp = true;

...and then add the exceptions.

Ian wrote:Am I correct that only star wars uses unsigned values? Is it also true that only star wars sets the specular flag on those polys?


No, Spikeout and Spikeout F.E. are also unsigned, in short: all step 2.x games except those in the list are unsigned, obviously unsigned implies "zero clamp", the latter being meaningful only when dealing with signed shade.

EDIT:
Star Wars uses specular effect where is appropriate to simulate a metallic reflections. There's no connection between specular bit set and fixed shading. It's no coincidence the "shininess" term in SWT is usually "2" or even "3", which produce the most accentuated highlight bright spot.

Probably, since we know already that fixed shading intensity is a drop-in replacement for "NdotL", they wanted to use specular even on those polygons, which makes totally sense to me since specular math reuses the shade (= intensity) value resulting from either NdotL math or passed directly as fixedShade value.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 8:55 am

That list is meaningful only for step 2.x because only that hw revision seems to be capable to do that. Step 1.5 doesn't have signed float, the 127 is treated as "1", I also had visually confirmed that behavior, if you force it as-signed you'll have a lot of (wrong) black polygons in Scud (incidentally I tried that yesterday).


I am treating it as a signed value and it looks perfect.
Scud uses 0-127 as a float it's 0.0 - 1.0
Signed bytes are -128 -> 127 or -1.0 to 1.0
Scud just never passes negative numbers

But yeah, the SDK clamps the values so they are never negative.

Star wars is using 0-255 unsigned bytes for the fixed shaded values?
Ian
 
Posts: 1638
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby HarryTuttle » Fri Aug 18, 2017 9:46 am

Ian wrote: am treating it as a signed value and it looks perfect.
Scud uses 0-127 as a float it's 0.0 - 1.0
Signed bytes are -128 -> 127 or -1.0 to 1.0
Scud just never passes negative numbers

Excellent, so we can simplify even more the shading formula. ;) It means that we've to choose between signed and unsigned byte. In this perspective Scud was incidentally already configured with the defaults:
Code: Select all
m_shadeIsSigned = false;
m_shadeFloorClamp = true;

So now, looking at my code, it should be included in the fist exception list (for m_shadeIsSigned) together with all step 1.5 games.

Ian wrote:Star wars is using 0-255 unsigned bytes for the fixed shaded values?

Yes.
Last edited by HarryTuttle on Fri Aug 18, 2017 11:28 am, edited 1 time in total.
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 9:56 am

Where does spikeout use unsigned (0-255) fixed shading?
Ian
 
Posts: 1638
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

Postby Bart » Fri Aug 18, 2017 9:57 am

The need for game-specific exceptions is odd. Something must be missing here. I wonder if some sort of lookup table was involved on the hardware? If so, maybe it is uploaded at the beginning. I need to look at what the heck Fighting Vipers 2 (and others) are writing at the very beginning. For example, there are deliberate transfers to texture memory during what otherwise looks like initialization code. Maybe something interesting is being uploaded at the beginning that we've missed all along...
User avatar
Bart
Site Admin
 
Posts: 2335
Joined: Thu Sep 01, 2011 2:13 pm
Location: Santa Clara, California

Re: [Patch] Sun Shading

Postby Ian » Fri Aug 18, 2017 10:03 am

Hey Bart,
yeah it's odd. The two daytonas use different light models. I checked the ROM polys for the cars, and the poly headers between the two games are identical. The roms models are the same as far as I can see, so it's a good comparison. The viewports are almost identical too. It's possible something in the culling nodes, but I can't find anything.

Something somewhere is configuring the light model on the GPU.
Ian
 
Posts: 1638
Joined: Tue Feb 23, 2016 9:23 am

Re: [Patch] Sun Shading

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

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

PreviousNext

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 4 guests