[Regression] Mario Kart 64 - Glitchy gfx in Title screen and other menus

[IronYoshi64]

On GLideN64 rev. be851a3, the version that comes with Project64 3.0, has horrible glitchy graphics in all the Mario Kart 64 title and menus. I using all default settings that are provided with the version, besides the windowed mode and fullscreen mode sizes.

Here are some pictures of what they look like:

[IronYoshi64]

Ok. I found out that the WTL version doesn't have the "Enable native-res bounds for texture coordinates" option in its UI and can't be disabled through the custom ini either, so its always forced on.

For Mario Kart 64, currently using the QT version 15668b9, I found out the best settings for the plugin, which are these:

graphics2D\enableNativeResTexrects=0
graphics2D\enableTexCoordBounds=1

This removes the extreme blurriness and glitchy lines on the menus.

[oddMLan]

The current master of GLideN64 has a lot of regressions and hasn't been tested enough and I advised zilmar to include the version before the texture coords refactor (1d90610) for 3.0 release but ran out of time because he wanted to push the release on the anniversary date. This is partly my fault for reporting there was an issue so late, but hopefully a hotfix will be pushed to release this weekend.

[fzurita]

Yeah, I see the exact same issue in Android too.

[IronYoshi64]

Yeah, I see the exact same issue in Android too.

Oh ok. Good, I glad I not only one that has this issue, so its definably a regression or some certain settings need to be tweaked by default.

[fzurita]

It's the default in GLideNUI:
https://github.com/gonetz/GLideN64/blob/master/ini/GLideN64.custom.ini#L155

Does the WTL version of the plugin load GLideN64.custom.ini?

[IronYoshi64]

The WTL version does load the custom.ini settings file, but like I said, the "Enable native-res bounds for texture coordinates" option is completely missing and apparently in WTL, its always forced on no matter what. I even tried to manually add the settings that I already posted above and it does not work.

[fzurita]

@standard-two-simplex Even forcing enableTexCoordBounds to 1, it graphics don't look correct for Mario Kart 64 in Android. The only way I can get them correct is by setting the native resolution factor to 1.

[fzurita]

Ok, I think I see part of the problem. EnableNativeResTexrects doesn't work well with EnableTexCoordBounds. Once I disable EnableNativeResTexrects things work well again.

@gonetz Any idea why that could be?

[ghost]

The problem seems that bUseTexRectDrawer in GraphicDrawer::setTextureRectangle() is a strict condition while the scale definition in URasterInfo::update() only checks for enableNativeTexrects != 0.

Disabling this line seems to fix the issue. I don't understand why the condition is so strict, so I don't know if this is the correct fix.

GLideN64/src/GraphicsDrawer.cpp

Line 1236 in 15668b9

&& bUseBilinear

[ghost]

Ok. I found out that the WTL version doesn't have the "Enable native-res bounds for texture coordinates" option in its UI and can't be disabled through the custom ini either, so its always forced on.

It is actually always disabled and can't be enabled through the custom ini.

I found out the best settings for the plugin, which are these:
graphics2D\enableNativeResTexrects=0
graphics2D\enableTexCoordBounds=1

There is a bug with the compatibility between enableNativeResTexrects and the new texture coordinate correction, which I cited above. It should be possible to fix.

[fzurita]

@standard-two-simplex I'm seeing this exact same problem with the fast path at 1x native resolution factor. Do you have any clues? I'm having a hard time figuring out where the issue is.

Additional details: native resolution texrects are disabled and texture coordinate bounds are disabled. The accurate path doesn't have this problem.

Using native resolution texrects does fix it, but being at 1x native resolution factor doesn't work when it should.

[fzurita]

@standard-two-simplex Apparently just getting rid of this condition and always setting the vectorOffset to 0.0 fixes the issue at 1x:

GLideN64/src/Graphics/OpenGLContext/GLSL/glsl_CombinerProgramUniformFactoryFast.cpp

Line 39 in e9a6f25

const float vertexOffset = isNativeRes ? 0.5f : 0.0f;

At other native resolution factors, you still need the native res texrects options.

[ghost]

Do you have any clues?

I'm not very sure what was reverted and what was not. It seems to me that texture coordinates are normalized in the fast path, but the offsets (uTextureOffset) are not. That should cause big glitches, why is it not? Are this uniforms affecting the scene in any way?

As I recall, there used to be a 0.5 shift in the old texture filter.

"  mediump vec2 offset = fract(texCoord*texSize - vec2(0.5));				\n"

The vertex offset replaces that more accurately and also takes in to account the non bilinearly filtered textures, like it was the case of Ogre Battle dialog boxes or BAR menus.

If you remove the vertex shift, you may want to test it well for both bilinear and point sample textures. You can check Zelda OOT Hud and start menu for bilinear (blurry with an incorrect shift) and the pictures in this thread (#1047) for point sample.

[gonetz]

Apparently just getting rid of this condition and always setting the vectorOffset to 0.0 fixes the issue at 1x

Confirmed. With vertexOffset = 0.5f, both filtered and unfiltered textures look incorrect in native res, fast texture path.