Supermodel Forum

That's great work Harry, I'll push these later tonight
I had wondered before about the previous logic but it had appeared to work well enough. The only place the microtextures looked off, was right before the track joins the main circuit on the advanced course in daytona power edition. But I never found any good quality arcade footage to compare against.

Ian wrote:But I never found any good quality arcade footage to compare against.

Thanks Ian! I based my work from Abe's videos of Daytona 2 BOTE attract sequence, when it explains how to drive, just before passing between the big side rocks. Well, here:
(Actual Supermodel footage)

Harry, are bitwise glsl operators available in glsl 1.2? Thought they were introduced with gl 1.3 which is OpenGL 3.0. Also is your maths correct. Using the bit shifting microtexturescale comes out as 1,2,4 and 8. But if you shift 128, or 1000,0000 (in binary) right 8 places you get zero? Which will give us a divide by zero error in the shader.

Disclaimer it's late and typing on my phone so could have messed up some understanding

Ian wrote:But if you shift 128, or 1000,0000 (in binary) right 8 places you get zero? Which will give us a divide by zero error in the shader

Damn! I'm going to check tomorrow Anyway just saw this in the SDK, pro_tables.hh:

Code: Select all

#define MAX_MICROTEXTURE_LOD   (4)

Probably is a value to clamp the microtexturescale shifting. That said, bitwise ops for ints work here, but I'm not sure on older hw. I used them because probably they're faster than divisions.

Anyway I've updated the microtexture code on the SVN with your findings. Hopefully I didn't break anything Scaling relative to the base texture size makes a lot more sense I think.

Ian, your last commit contains a math error . My patch behaved more like this:

in <New3D.cpp>

Code: Select all

#define MAX_MICROTEXTURE_LOD 4
float microTexScale[] = { 1, 2, 4, 8 };
 
currentMesh->microTextureID = ph.MicroTextureID();
currentMesh->microTextureScale = std::min(MAX_MICROTEXTURE_LOD, microTexScale[ph.MicroTextureMinLOD()]);


and in <R3DShader.cpp>

Code: Select all

vec2 scale    = baseTexSize / ( 128.0 / pow(2.0, microTextureScale) );


Otherwise we get different visual results. I've borrowed that macro directly from the SDK, I think that was the intended behavior to avoid a division by zero.

Let's check .. It's always possible i screwed something up

Using yours:
float microTexScale[] = { 1, 2, 4, 8 };
( 128.0 / pow(2.0, microTextureScale) );

128 / (2^1) = 64 = 2x scaling
128 / (2^2) = 32 = 4x scaling
128 / (2^4) = 8 = 16x scaling
128 / (2^8) = 0.5 = 256x scaling

Using svn version

128 / (2) = 64 = 2x scaling
128 / (4) = 32 = 4x scaling
128 / (8) = 16 = 8x scaling
128 / (16) =8 = 16x scaling

I suppose the question is. For MicroTextureMinLOD() using the value 2 is the correct scaling 8x or 16x ? What's the visual difference in daytona ?
I assumed also that
#define MAX_MICROTEXTURE_LOD (4)
referred simply to the number of LODs there were. Not a direct clamp on the value.

Ian wrote:For MicroTextureMinLOD() using the value 2 is the correct scaling 8x or 16x ? What's the visual difference in daytona ?

The correct one is 16x. The difference is in the pattern showed here (the big side rocks), MicroTextureMinLOD() == 2:

With 8x you'd get "bigger" patterns.

This is from an Abe's video:

This is 8x


And 16x


So yeah i'd say you are definitely correct here!

Obviously, as you've noticed before, we've to address the case when MicroTextureMinLOD() == 3, I choose to clamp it using that macro as a safety check, but currently I still haven't encountered any such condition.