topgear overdrive texture bug

[olivieryuyu]

[Squall-Leonhart]

this is a sprite, not a texture.

[gonetz]

@olivieryuyu is it a regression? And what is wrong in upper right corner? It looks the same with al rdp.

[weinerschnitzel]

Looks like some textures are getting clamped to the right.

There is also the right hand side of the speedometer needle that has some artifacts that look like they belong on the left.

Does the use screen coords branch help?

The top of the speedometer looks to be at wrong coords or maybe a different case.

[olivieryuyu]

the one on the upper right corner is indeed correct

It is a regression compared to gliden64 4 at least

[ghost]

@olivieryuyu Is this a bug with master or with branch use_screen_coords?

[Jj0YzL5nvJ]

Is this a bug with master or with branch use_screen_coords?

Both.

Bisected to 4834359ec1ad031210fb6ade6c9d50e953b20d0e

[gonetz]

@standard-two-simplex could you check that issue? 2D look ugly with current master and with "use_screen_coords" branch even in native resolution.

[ghost]

Yes, I will look into it. See if I can find out anything.

[ghost]

I might have a clue about why the issue is happening.

The game apparently uses LOD to render the 2D HUD. In spite of this, I think the texture has only one mip-map level. It might be possible that the clamp wrap mirror shader uses unintended clamping bounds when LOD is enabled.

I believe the changes in use_screen_coords only made the issue more visible, but it was introduced in LOD related code in 4834359, as it has already been pointed out.

[gonetz]

Yes, speedometer textures use LOD. However, track icon with cars positions also has plenty of errors in compare with PR 4.0: It does not use LOD.

[gonetz]

The problem is in UTextureEngine::update() :

    aTexClamp[t][0] = (pTile->flrs - pTile->fuls + 1.0f) * pTexture->hdRatioS - 1.0f;
    aTexClamp[t][1] = (pTile->flrt - pTile->fult + 1.0f) * pTexture->hdRatioT - 1.0f;

flrs and flrt are 7.0, but fuls and fult are 0.5 lrs and lrt are 7, uls and ult are 0.

If use integer tile's coordinates

    aTexClamp[t][0] = (pTile->lrs - pTile->uls + 1) * pTexture->hdRatioS - 1.0f;
    aTexClamp[t][1] = (pTile->lrt - pTile->ult + 1) * pTexture->hdRatioT - 1.0f;

this particular issue is completely fixed. I'm not sure, is it the correct fix in general.

Update: here the fix a6e736e45

[ghost]

If use integer tile's coordinates this particular issue is completely fixed. I'm not sure, is it the correct fix in general.

I checked angrylion's sources and he computes clampdiffs using only the integral part. Besides, texel 7 must be used in those textures, and I can't think of another way of making that subtraction at least 7. On top of that, the function clampWrapMirror is meant to handle integral coordinates (even though they are in floating point format) so it makes sense passing an integer to vClamp.

So I would say your guess is probably correct.

[gonetz]

Ok, thanks! I put that fix to master and rebased your screen coordinates branch. @olivieryuyu could you test that the issue is fixed in the master?

[olivieryuyu]

fixed :)