Blank frames in certain games

[kohlrak]

I'm on EndeavorOS, using wine-9.13. Games made with the Pixel Game Maker MV engine (i'm pretty sure it's the ones who made the RPGMaker engines) have parts where the screen goes white. Most of the games, it's only a small section of the game where it occurs, but I am aware of one game that has a free demo that consistently manifests the issue after simply selecting "new game." Unfortunately, the game is considered "adult." The behavior does not manifest itself in windows. I've tried this numerous times in the past, tried fresh prefixes, tried dxvk in winetricks, other versions of directx via winetricks, etc. I have run out of ideas. Nothing sticks out aside from a warning from libpng, but the warning is being spit out even in other games when the error is not occurring.

DEMO FOR ADULT GAME

It's important to note that you have to prefix wine with LANG="ja_JP.UTF8" to get the thing to run and not crash.

[DarkShadow44]

I can confirm the issue and created an issue for you: https://bugs.winehq.org/show_bug.cgi?id=57018

[kohlrak]

I can confirm the issue and created an issue for you: https://bugs.winehq.org/show_bug.cgi?id=57018

Thank you, sir. Trying to see what's going on here reading your own code here, it's basically ignoring the alpha channel? Does your solution throw away the whole texture or just the alpha'd bits (asking to see how it applies to other things since I don't know shader languages)? I've seen white borders on things in other games.

[kohlrak]

Now that i'm home and try your workaround, I can't get it to apply. When using export MESA_SHADER_READ_PATH it doesn't seem to apply. On a hunch i tried using MESA_SHADER_DUMP_PATH, and i noticed a bunch of similarly named files (are these files named with a two letter prefix then a memory address?), but none of them matched your original filename (i'm kinda not surprised). Since this appears to be a driver issue as you state since it's fixed with a shader, how exactly do you apply this workaround for those of us whom are affected?

[DarkShadow44]

I didn't check what the shader is really doing, I just took the original and replaced one line to make it compile. It shouldn't change behavior at all, just makes the shader usable.

[kohlrak]

I didn't check what the shader is really doing, I just took the original and replaced one line to make it compile. It shouldn't change behavior at all, just makes the shader usable.

Oh, i see now. That's an int, not a float and it needs a float for that variable I assume. Yeah, this by consequence looks like a mesa issue or something I only incidentally discovered through wine, but i'm not sure how to reliably fix the issue (is this something within the scope of wine to address as a compatibility issue?). I can manually search for it after dumping shaders, but that's not something everyone else can do easily.

[DarkShadow44]

Yes, apparently there's no implicit conversions. AFAIK there should be, if the shader defines a shader version later than 120. If I understood the guys in IRC correctly.
Not 100% sure if we should report this to mesa as an issue, but maybe we should.

[kohlrak]

Yes, apparently there's no implicit conversions. AFAIK there should be, if the shader defines a shader version later than 120. If I understood the guys in IRC correctly.
Not 100% sure if we should report this to mesa as an issue, but maybe we should.

It's certainly a bug somewhere, but it's a question of who's jurisdiction the bug is actually in. Does this happen outside of games with wine? If so, then where did the shaders come from? Is it from the game engine? MESA? The drivers? Given these issues are specifically showing up on linux, and judging from what i'm seeing here, i'm partial to believing it is specifically MESA's territory.

[DarkShadow44]

Yeah me too, but then again, it doesn't work with AMD proprietary drivers either. On windows it does though... It's weird and I don't get it.

[kohlrak]

Yeah me too, but then again, it doesn't work with AMD proprietary drivers either. On windows it does though... It's weird and I don't get it.

Ok, so where are these shaders generated/stored at? I'm from the good ol' days where we use glTranslate3f and functions like that. Are these generated on the fly or are these basic functions and fragments that are stored as firmware in some obscure directory?

[DarkShadow44]

They are shipped with the program which passes it to the graphics driver.

[kohlrak]

They are shipped with the program which passes it to the graphics driver.

Must be hiding in a DLL or something then. You stated that if the shader defines a shader version 120 or later that it should compile just fine. grep tells me it's 130 that is specified. So either it's ignoring values, or since the shaders are separate, the shaders are assuming the compiler will read the #version from one and apply it to all of them. If that assumption is the correct behavior, then it's a bug on MESA's end. I can only fathom a guess without debug output, but based on what you're telling me, what's actually happening is that for all shaders that don't have #version specified, it defaults to a lower number.

EDIT: If my assumption is right, this is a much bigger bug than we realize.

[DarkShadow44]

Yes, the shader is somewhere in the exe, the dlls, or any of the assets. But that shader I posted doesn't specify a version.

[kohlrak]

Yes, the shader is somewhere in the exe, the dlls, or any of the assets. But that shader I posted doesn't specify a version.

The one you posted does not, but two shaders dumped actually do. So googling how to set the default there is a MESA_GLSL_VERSION_OVERRIDE variable, but setting it to 130 like specified does not seem to actually solve the problem. Apparently this doesn't actually set the value, but makes some function report that value. I even deleted the shader cache to try that and still no dice.

[DarkShadow44]

Well, you can always use MESA_SHADER_DUMP_PATH and MESA_SHADER_READ_PATH to work around the issue.

[DarkShadow44]

Not sure if you checked the mesa issue, but maybe the game gets added to a workaround list. I personally hate such lists, because I'd rather have it fixed once and for all, but I kinda doubt they'll do that.
You might want to find all similar games, check if the same workaround helps, and report that to the same issue so they can all be listed...

[kohlrak]

Well, you can always use MESA_SHADER_DUMP_PATH and MESA_SHADER_READ_PATH to work around the issue.

Not sure if you checked the mesa issue, but maybe the game gets added to a workaround list. I personally hate such lists, because I'd rather have it fixed once and for all, but I kinda doubt they'll do that.
You might want to find all similar games, check if the same workaround helps, and report that to the same issue so they can all be listed...

The problem here is that this is one of many games with this issue (and the easiest one to spot). Of course I can do that, thanks your instruction i know now what to look for, but it requires manual searching per game. What's worse is, it is not only manual searching per game, but your fixed file does not work: when i used the DUMP, that same file had a completely different name on my computer, meaning we'd have to write a script to automatically detect what file it is and patch it for people. And that assumes that it's the only shader that's experiencing problems. Most people google problems and don't sign up for the forums. I had finally had enough of it hence joining. I'm thinking about getting a new computer, and I want to skip getting windows entirely, because I don't want to deal with the major data reliability threat that is windows 11, that's what pushed me over the edge. (I'm also dealing with the child window rendering issue, but my googling tells me we aren't going to see that solved in the near future.)

But if you were to say it's not a wine issue, and thus it's outside of the scope here (unless wine passes the shaders to the compiler differently than other things), you would be absolutely correct. You identified the problem as the shader version number which is not specified in the affected file, but two other files it's set to a specific version that is not affected. Another potential fix would be to write a script that forced all shaders to specify the highest version found when searching all the files, by adding lines to all the shaders.

[DarkShadow44]

I took the issue to mesa at https://gitlab.freedesktop.org/mesa/mesa/-/issues/11625, but since what the program does is technically against spec mesa doesn't want fix it once and for all. They only apply game specific workarounds, which, IMHO, is a terrible approach only causing the same issues over and over again (like you mentioned). I'd take a different stance, but I'm not the one to decide. I'll try to convince them in this issue, but I feel our chances are slim to none.

Anyways, there's nothing Wine can or should do here, I think.

[kohlrak]

I took the issue to mesa at https://gitlab.freedesktop.org/mesa/mesa/-/issues/11625, but since what the program does is technically against spec mesa doesn't want fix it once and for all. They only apply game specific workarounds, which, IMHO, is a terrible approach only causing the same issues over and over again (like you mentioned). I'd take a different stance, but I'm not the one to decide. I'll try to convince them in this issue, but I feel our chances are slim to none.

Anyways, there's nothing Wine can or should do here, I think.

Actually, i think they gave a reasonable answer. Those of us trying to get things working in wine are more or less used to workarounds. The "allow_glsl_120_subset_in_110=true" is reasonable, and universal. Throwing it in .bashrc (with export) should effectively solve the problem. I'm not sure i agree that the shaders are out of spec, but i also don't know the spec. Anyone who finds this post by googling the issue and landing here would reasonably find the solution to this issue. It's certainly not ideal, but this works. Now, as for why that isn't documented among all the other common mesa options is for another discussion, which, to me, says a little about the current problem.

That said, thank you for your hard work on this issue. I don't think there's much more that can be done here unless we can demonstrate that the shaders are in spec (by version assumption in through the other two shaders, or just compilers normally defaulting to the latest version for everything other than mesa including other programming languages).