[Issue]:

[master1274]

Describe the bug

In the latest builds, I observe a regression in the game Gex 3 - Deep Cover Gecko (U) on the plugin GlideN64 (any accurate). Black screen, the sound of the running game sounds. Device Shield Tablet, Android 7.0, armeabi-v7a.

Steps to reproduce

Game launch

Expected behavior

Availability of video

Relevant log output

No response

Add screenshots

No response

[fzurita]

This could be a shader cache issue. Go to tools in the app and choose to clear the shader cache. Then try the game again.

[master1274]

Clearing the shader cache did not solve the problem. It turns out that the problem in this game on my device appeared a very long time ago. I checked previous versions of the app. Everywhere found the same problem. We managed to get normal display on a very old version Mupen64Plus FZ_3.0.222 (beta) I was interested in the community, in current versions arm64-v8a there is no problem with this game.

[fzurita]

Ok, from that it sounds like it was an update to GLideN64 that caused the problem.

You could try creating a custom profile of GLideN64 and try toggle different options on and off to try to track down the problem.

[master1274]

Ok, I'll try. But there are a lot of options. Maybe from this video, as a developer, you will understand the direction of what exactly I should switch? https://drive.google.com/file/d/1lmWjOYZZIiqN_JAP7Lv36RYJLwLFqyQs/view?usp=drivesdk

[master1274]

В режиме интерпретатора с кешем изображение есть, конечно, игра медленная. Я не думаю, что это можно назвать discovery ошибкой.

[fzurita]

It's really hard to say. It looks like either a texture format issue or a shader compilation issue.

Did you say that non accurate profiles work ok?

Is that's the case, if you make a copy of the accurate profile or medium profile, you can then see what options are set by editing it.

There is not much different between medium and accurate. You can then just try making a copy of medium and try enabling each option at a time that is present in the accurate profile until you find the option that causes the issue.

[master1274]

Inaccurate profiles also have exactly the same problem. Therefore, I have nothing to compare in their settings.

[fzurita]

Gotcha, so it's always broken no matter what. My previous comment still applies. A texture format issue or shader compilation issue.

Your best bet would be to make a bug upstream here:
https://github.com/gonetz/GLideN64/issues

But, without access to the device, it's unlikely to every get fixed.

In the bug, you can mention which device you have.

[master1274]

Shield Tablet 32GB/LTE, Tegra K-1, Android 7.0, ARMv7, 320 dpi(1920х1200), OpenGL ES 3.2, Vulkan 1.0, Core 4x ARM Cortex-A15 - 2218 MHz.
null.txt

[master1274]

Exactly the same problem on the device Redmi 8A, Android 10 (64-bit processor, 32-bit instruction set). The problem is general in nature of the dynamic recompiler armeabi-v7a. Because it doesn't exist in interpreter mode. Can you move the issue upstream to the appropriate branch?

[fzurita]

This is the first time I hear that it doesn't happen in interpreter mode. This only happens in interpreter while using GLideN64?

[master1274]

It is very difficult for me to communicate on the topic of emulation through Google Translate. The problem occurs on different devices ARMv7.

[master1274]

If there is no 32-bit device to test the problem, then you can catch the problem by installing the emulator assembly with the library only armeabi-v7a on the 64-bit device

[fzurita]

Yeah, a device would had been an issue if it only affected tegra GPUs.

This seems to be a dynarec issue. So obtaining a device is not an issue. This is unfortunately not an area I'm an expert in. It's an upstream issue.

I will make an issue upstream, but not sure when it will get fixed.

[master1274]

gonetz/GLideN64#2781
Is there really no confirmation in the universe that the game is completely broken for emulation, on the current version of the core, on all 32-bit ARM devices?

[fzurita]

I created an upstream issue: mupen64plus/mupen64plus-core#1024

It will be tracked there if anyone decides to fix it there.