[Patch] GPU Configuration Registers

[HarryTuttle]

Star Wars Trilogy Arcade seems to be the only game that sets fixed shading as unsigned. Definitely can't depend on the specular attribute state 'cause the floor (grass+dirt) in Endor Forest level is not specular but is still unsigned fixed shaded.

So I started dumping to console the internal render config JTAG values and looked for something suspicious. However SWT is patched at load time to ignore JTAG so I looked at SWT Alternate (swtrilgya)... and it worked!

Maybe it's a coincidence but it's the only game that sets internalRenderConfig[0]'s LSB, all other games have that bit unset (= 0). So I just added the appropriate checks and a fall-back logic to set the correct values in those games that don't expose JTAG (currently only srally2 and swtrilgy, if I'm not mistaken).

[Bart]

Very interesting! I can merge this in tonight or tomorrow if Ian doesn't get to it by then.

[Ian]

Star Wars Trilogy Arcade seems to be the only game that sets fixed shading as unsigned. Definitely can't depend on the specular attribute state 'cause the floor (grass+dirt) in Endor Forest level is not specular but is still unsigned fixed shaded.

That's a good catch!
So star wars is the only game to set these values?

[HarryTuttle]

Apparently yes. I've not played every game till the end, but the most of them set the GPU configuration at startup, others change in-game (virtual on), in every case I've never encountered that bit set to 1 (except SWT).

[HarryTuttle]

I've got the feeling that only internalRenderConfig[0] is responsible for the light model tweaking, but I really cannot confirm that now.

I'm looking eventually for an "ambient+diffuse ceil clamp to 1" bit that could be present and set for every step 1.0 game. That clamping happens before getting multiplied with fragment's base color.

EDIT:
I forgot to say that I'm referring to the intensityClamp bool state present in the official build's fragment shader.

[Ian]

What other values are passed that we don't know yet what they do?

[HarryTuttle]

What other values are passed that we don't know yet what they do?

Lots of them and they usually are the same across games.

Leaving aside for a moment the cases of in-game configuration change I've observed that at start usually the two registers are set 4 times, each time on both registers the lower 4 bits can usually be: 0xA, 0x6, 0x3, 0x2 or 0x0.

The upper bits instead are set so that the value on internalRenderConfig[0] is usually double of internalRenderConfig[1]. For example when the first has 0x800000 the latter has 0x400000, first 0x20 and second 0x10 and so on...

Also on step 2.x games, except for Sega Rally and Star Wars Trilogy Arcade (and variants) internalRenderConfig[0] has bit 5 (0x20) set and internalRenderConfig[1] bit 4 (0x10) set.

There seems to be some kind of "pattern" but what does that mean? And I still have not found what can be linked to intensityClamp state in fragment shader, if ever exists such a bit.

[Ian]

I'm looking eventually for an "ambient+diffuse ceil clamp to 1" bit that could be present and set for every step 1.0 game.

It might have been the hardware didn't do floating point math at that stage of the graphics pipeline for step 1.0. My guess originally was that there could never be values over 1. Same for specular, as, as far as I know it didn't exist on the step 1.0 h/w.

[HarryTuttle]

I was about to write this into the "[Patch] Sun Shading" topic, anyway...

It might have been the hardware didn't do floating point math at that stage of the graphics pipeline for step 1.0

It seems that you're right about that hw level limitation, at least I did't find any link to GPU configuration bits. I believe that, regarding sunlight ceil clamping to "1", the current behavior could be summarized as below:

Code: Select all

-----------------------------------------
HW step level  | illuminated | luminous |
               | polygons    | polygons |
               | clamping    | clamping |
---------------+-------------+----------|
step 1.0       |     YES     |   YES    |
---------------+-------------+----------|
step 1.5       |             |          |
(sun shaded)   |     NO      |    NO(1) |
---------------+-------------+----------|
step 1.5       |             |          |
(fixed shaded) |     NO      |    NO(1) |
---------------+-------------+----------|
step 2.x       |             |          |
(sun shaded)   |     NO      |    YES   |
---------------+-------------+----------|
step 2.x       |             |          |
(fixed shaded) |     NO      |    ???(2)|
-----------------------------------------


NOTES:
(1) The current formula for luminous polys, visually confirmed, seems to be:

Code: Select all

// Pseudo-code
// Note the subtle difference for the "ambient" term

if (!fixedShaded) {
   ambient = 0.5;
   diffuse = 1.0;
}
else {
   ambient += 0.5;
   diffuse = 1.0;
}


(2) In this case I'm tempted to write "YES" it's clamped, some game needs that. However there're Virtua Striker 2 and its updated versions (98, 99, etc.) which are present also in step 1.5 "flavor". If I clamp the luminous fixed shaded value they will mismatch the lightness and saturation of the step 1.5 variant.

Look at the attract demo, for example, and pay attention to the billboard object displaying the team names along with game result, comparing to icuk7's video of Virtua Striker 2 it's clear that the value is unclamped. I wonder if he used the step 1.5 or 2.0 version, in the latter case it could be very probable that the game configures hardware clamping mode in real-time, but how?

[HarryTuttle]

[...] comparing to icuk7's video of Virtua Striker 2 it's clear that the value is unclamped. I wonder if he used the step 1.5 or 2.0 version [...]

My bad... it was well written in the video description he used the step 1.5 version... So at least I can confirm again the math for luminous objects (sun / fixed shaded) in that model step.

Also by looking at other Virtua Striker 2 (98, 99, etc.) videos on YouTube taken from real hardware it seems they use instead the clamped version of the lighting model for luminous polygons. If they use the step 2.x variant we can almost safely assume that luminous (sun / fixed shaded) is always clamped to "1" in that hw step version.

Stay tuned...