Super Mario 64: Texture pixels appear to be swapped with adjacent pixels

[jgcodes2020]

Summary

This is the title screen.

Notice how the background texture has this weird striping effect. Same for the "PRESS START" text.

OS info

• OS: ArcoLinux
• Display protocol: Wayland (Mupen runs via XWayland)
• Desktop environment: KDE 5.25.1
• Plugin version: commit 3266c1 (built from source via AUR)
• CPU: Intel i7-1165G7
• GPU: Intel Tiger Lake GT-2 (Iris Xe graphics)
• RAM: 16 GB

[Narann]

Hello,

More info is needed (OS, hardware, etc).

[jgcodes2020]

I have edited that on.

[Narann]

Thanks, I have no idea where this problem could come from.

It could come from how texture is loaded in memory, but that seems unlikely because this code runs from years.

It could come from how the old OpenGL pipeline is supported by your driver. Are you using Mesa? Intel has often troubles and regressions on this.

Glide64 is a very old code base. Can I suggest to use GlideN64? It's (a lot) more demanding, but has less problems.

If you also have this problem with GlideN64, there is something wrong with your driver.

[jgcodes2020]

The bug is not present in GlideN64. I will leave this issue open in case anyone decides they want to fix it.

[HybridDog]

Since updating some weeks ago, I have the same problem with gles2glide64. When I use software rendering or zink, the textures also look wrong, so I doubt that it is caused by the intel driver.

I've collected traces of the OpenGL operations using apitrace for gles2glide64 and rice: apitrace_data.zip I've created the traces with apitrace trace mupen64plus CaribbeanNights.v64. To replay a trace with apitrace, it is possible to execute for example apitrace replay rice_recording.trace --min-frame-duration=100000 or use qapitrace.

For zink or software rendering I set the MESA_LOADER_DRIVER_OVERRIDE=zink or, respectively, LIBGL_ALWAYS_SOFTWARE=1 environment variables.

Here are some screenshots:

gles2glide64:

rice:

mupen64plus configuration: mupen64plus.cfg mupen64plus output with gles2glide64: gles2glide64_output_messages.txt operating system: Arch Linux mupen64plus version: 2.5-21 (installed with pacman) mesa version: 22.1.3-1 (installed with pacman) CPU: Intel Core i5-6200U GPU: Intel Skylake GT2 [HD Graphics 520]

The "Caribbean Nights" demo used for the screenshots and traces is from http://www.nesworld.com/article.php?system=n64&data=n64homebrew

#

GlideN64 is too slow for me. According to that page, it should be possible to use parallel-rdp for mupen64plus but I couldn't figure out the installation procedure for my system.

[Jj0YzL5nvJ]

Better late than never.

mupen64plus version: 2.5-21 (installed with pacman)

That version is more than 7 years old. No distribution offers optimal versions of mupen64plus, the only way to get good support is to compile the code yourself. You can use this script if you want, I update it regularly.

That homebrew is interesting, it runs fine with Glide64mk2 but not with GLideN64.

[HybridDog]

Thanks for the script. The default mupen64plus version from pacman is indeed 2.5.0. After I replaced it with a new mupen64plus 2.5.9 from the mupen64plus-git aur package the problem still happened.

Later, I updated my system, including the new sdl2 2.24.0-1, and then tried your script and ./m64p-test/m64pp. However, now all my mupen64plus versions stopped working, even if I delete mupen64plus.cfg. mupen64plus shows this error message: ‪ Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid ‪ I doubt that it's caused by your script. Perhaps the problem is related to SDL.

#

GlideN64 is too slow for me.

By the way, by now I found some settings for GlideN64 which are helpful for me, e.g. to get a reasonable performance:

• BufferSwapMode = 1 This setting significantly improved the performance for me. It is explained at http://gliden64.blogspot.com/2016/11/new-public-release-part-iii.html.
• UseNativeResolutionFactor = 1 The game is rendered in low resolution and then upsampled; this can be helpful for 2D games with pixel art to prevent smoothing and can be bad for 3D games.
• EnableHybridFilter = False Upsampling without oversampling leads to a sharper image, which I prefer.
• EnableHWLighting = False A setting to switch between Gouraud shading (False, the default and more accurate emulation) and Phong (True).

[Jj0YzL5nvJ]

Later, I updated my system, including the new sdl2 2.24.0-1, and then tried your script and ./m64p-test/m64pp. However, now all my mupen64plus versions stopped working, even if I delete mupen64plus.cfg. mupen64plus shows this error message:

Core Error: SDL_SetVideoMode failed: Parameter 'pitch' is invalid

I doubt that it's caused by your script. Perhaps the problem is related to SDL.

Yes: mupen64plus/mupen64plus-core#969

GlideN64 is too slow for me.

Try with:

export MESA_GL_VERSION_OVERRIDE="3.3COMPAT" MESA_GLSL_VERSION_OVERRIDE="330" MESA_EXTENSION_OVERRIDE="-GL_ARB_buffer_storage"

[Langerz82]

I got this same issue that 2D user interfaces appear corrupted and it looks like 1 row of pixels are normal and off odd row of pixels is shifted across.

platform: Linux amlogic 4.9 arch: aarch64 version: 95229fed6d19a4a2cb7f9927d268073682d68c53 OPENGLES driver: opengl-meson mupen64plus standalone version.

Also I should mention the fragment_depth_shader_object does not compile by the default build, it says that gl_FragDepth is not a declared variable.

Here are some SS's https://imgur.com/a/2bAoabV