[Patch] Fixed Shading

[Ian]

With the current code. Just trying to find some test cases for myself. The beginners oval in dirt devils has a very similar issue.

[Ian]

I have a feeling the shade value might be something like this

shade = std::max(shade,1-vpAmbient);

Magical truck and la machine guns are both step 2.x games. Both use fixed shading and both seem to use very similar or the same render states for the polys. LA machine guns definitely uses the full range of colours. Ie the fixed shade colour for black 0x80 comes as out as black! Where as in magical truck it comes out at like 50% brightness.

The difference is in LA machine guns the vpAmbient is 1, and in mag truck its like 50%.

That's my current thinking currently but not tested it yet

Edit:
Not sure this works either. Scud sets an ambient vp value of 0 so that can't work.
I wonder if we are missing something obvious like gamma correction. I know the hw can do it.

[HarryTuttle]

Not sure this works either. Scud sets an ambient vp value of 0 so that can't work.
I wonder if we are missing something obvious like gamma correction. I know the hw can do it.

Scud seems to have a global shade multiplier of 1.5f for everything self illuminated, that's the only way to correctly render the torches inside the cave level (medium), some elements of the first course like water and maybe other things that I can't remember right now.

However, yes, that could simply be the gamma correction feature in action. Right now only step 1.5 games seem to show that particular condition.

[Ian]

One thing I did notice between lamachineguns and mag truck is the shininess bits are set
In LA machin, 1 bit is set, in mag truck both are set

Don't know if they are simply no-ops or if they actually effect fixed shading at all

I had a look for gamma tables but couldn't find anything In the SDK they write to the memory address
write_to_ls(0x20000004, &a1, 1, a2);

But as far as I know nothing is ever written there

[HarryTuttle]

One thing I did notice between lamachineguns and mag truck is the shininess bits are set
In LA machin, 1 bit is set, in mag truck both are set

Don't know if they are simply no-ops or if they actually effect fixed shading at all

Interesting... I might have another go to fixed shading after all, I'm thinking also about that "1-Ambient" possibility. I've some idea of where I can use that.

I'll let you know.

[Ian]

Gonna have a closer look at some of those previous examples you posted
Never really tested starwars, didn't know it even used fixed shading. Might have some interesting test cases

[Ian]

Harry, do you have a save state for this ?

[Ian]

Harry, do you have a save state for this ?

Well I finally managed to make a play through to this save point ..

I see the problem. The shading is totally fubar here.

As far as I can work out, in this scene the correct formula should be

float shade = ((ix & 0xFF) / 255.f) + offset;

instead of

float shade = (((ix + 128) & 0xFF) / 255.f) + offset;

The latter treats the value as signed, and adds 128 to make it unsigned. The latter is already treated as unsigned ..
Either that or there is some offset added here. At least this seems to match what Harry has found. This looks totally broken for LA Machine guns though. The lighting is inverted with this.

[HarryTuttle]

As far as I can work out, in this scene the correct formula should be

float shade = ((ix & 0xFF) / 255.f) + offset;

instead of

float shade = (((ix + 128) & 0xFF) / 255.f) + offset;

The latter treats the value as signed, and adds 128 to make it unsigned. The latter is already treated as unsigned ..
Either that or there is some offset added here. At least this seems to match what Harry has found. This looks totally broken for LA Machine guns though. The lighting is inverted with this.

Sorry for the save states but I have deleted them due to continuous changes to the RunMainBoardFrame function I'm working to, infact they're now incompatible.

For the fixed shading formula: I've resolved it in both SWT and LAM cases. I've also taken in consideration the TranslatorMap bit (but not the related offset value bits).

This is what I've found for step 2.x games (all values are for illuminated objects, self-illuminated have always shade = 1):

when TranslatorMap == 0:
- for 0 < ambientLight <= 0.5 the normal value is UnSigned and added to ambient value itself
- for ambientLight > 0.5 the normal value is Signed and added to 0.5 constant

when TranslatorMap == 1:
- the normal value is Signed and added to 1.0 constant regardless of ambient value

[Ian]

Does that work in all cases?
What my brain struggles with, what if they are lit polys in there too. The interpretation of the fixed shaded ones would flip if you changed the vp ambient, which makes little sense.