Trying to play GWLE6L on 4.0-2289 fails with several messages similar to:
Debug info (X.Org, Gallium 0.4 on AMD CAYMAN, 3.0 Mesa 10.1.5):
0:110(33): error: `uv0' undeclared
0:110(37): error: type mismatch
0:110(52): error: operands to arithmetic operators must be numeric
0:110(59): error: operands to arithmetic operators must be numeric
0:110(59): error: no matching function for call to `iround(error)'; candidates are:
0:110(59): error: int iround(float)
0:110(59): error: ivec2 iround(vec2)
0:110(59): error: ivec3 iround(vec3)
0:110(59): error: ivec4 iround(vec4)
0:111(33): error: `uv1' undeclared
0:111(37): error: type mismatch
0:111(52): error: operands to arithmetic operators must be numeric
0:111(59): error: operands to arithmetic operators must be numeric
0:111(59): error: no matching function for call to `iround(error)'; candidates are:
0:111(59): error: int iround(float)
0:111(59): error: ivec2 iround(vec2)
0:111(59): error: ivec3 iround(vec3)
0:111(59): error: ivec4 iround(vec4)
Is this a Mesa limitation, or did someone just forget to declare uv0, etc?
Dumps attached.
Try with fglrx and see if it works there.
Sounds like the game is doing something weird, because uv0 and uv1 really aren't being defined in the shader.
(07-28-2014, 07:55 AM)Anti-Ultimate Wrote: [ -> ]Try with fglrx and see if it works there.
Honestly I'd rather not. (I dislike proprietary software and especially really don't want to muck about with my video driver. I've never used fglrx on this machine and would as soon keep it that way.) Sorry; I know it would be a data point...
Is there any reason to think this error couldn't be reproduced by a simple program that just tries to compile the shader(s) from the dump(s)? If no, anyone else with fglrx could try it, and if it works there, it would be useful as a test case for filing a Mesa bug. (I'd be willing to write such a SSCCE.)
(07-28-2014, 08:04 AM)Sonicadvance1 Wrote: [ -> ]Sounds like the game is doing something weird, because uv0 and uv1 really aren't being defined in the shader.
Yes. I'm admittedly not really familiar with "uv0", etc. (I looked them up briefly), but the impression I got was that they aren't in the set of implicitly available variables and must be declared, which I didn't see happening anywhere.
Are these dolphin shaders, or dolphin doing something to create GLSL shaders from information provided by the game, or does the game provide GLSL directly and dolphin just passes it along. (I'd be willing to look into fiddling with the code if someone can suggest where to start poking.)
It's an issue with the game only setting one half of the settings it should be setting. This causes the shaders to break in the GLSL path.
For minor details, a game is supposed to set the number of "texGens" in both XF Memory and BP Memory, but it decided to only do it in BP and not XF. These two values are supposed to be in sync, but of course there are these games that take a half assed approach I guess.
In any case, I know what the issue is. I've fixed it on my end and I haven't sent a PR yet, I will be in a bit.
Bit of a let down though, for me once it gets in game it crashes immediately.
(07-28-2014, 10:25 AM)Sonicadvance1 Wrote: [ -> ]It's an issue with the game only setting one half of the settings it should be setting. This causes the shaders to break in the GLSL path.
For minor details, a game is supposed to set the number of "texGens" in both XF Memory and BP Memory, but it decided to only do it in BP and not XF. These two values are supposed to be in sync, but of course there are these games that take a half assed approach I guess.
In any case, I know what the issue is. I've fixed it on my end and I haven't sent a PR yet, I will be in a bit.
Awesome; thanks. If you'd like some additional poking of it before it's merged, I'd be happy to have a look.
(07-28-2014, 10:25 AM)Sonicadvance1 Wrote: [ -> ]Bit of a let down though, for me once it gets in game it crashes immediately.
I suspect I'm seeing that too... it did crash on me also, but of course I can't be sure if it's due to the above issue or something else.
Looks like the real reason behind the issue is that it somehow crashes and causes a GPU reset which makes it unstable.
There is a patch in the game properties to work around the issue.
(07-28-2014, 11:38 PM)Sonicadvance1 Wrote: [ -> ]Looks like the real reason behind the issue is that it somehow crashes and causes a GPU reset which makes it unstable.
There is a patch in the game properties to work around the issue.
Thanks; with that, and current master (as of writing), it doesn't crash. (Can that be turned on by default? I can imagine it being overlooked quite easily, otherwise.)
Unfortunately it's not "exactly" playable due to a horrible graphics glitch (see attached). I get loosely similar behavior in other games as well - certain textures with similar effects, or similar effect from bloom shaders washing out large portions of the frame - but this is unusually bad. (Note that the cinematics and menu screen don't show this problem.)
Fancy, I didn't go that far in to the game. I went ingame and shot a few bananas with a banana gun, Looked alright for me at that point.
Could potentially be an issue in mesa with the radeon driver if you're getting issues in other games as well.
(07-30-2014, 01:51 AM)Sonicadvance1 Wrote: [ -> ]Fancy, I didn't go that far in to the game.
It's not far in at all; it's literally at the start of the game (pause screen). The first level looks like that (tons of blown-out green and cyan) also. GM8E01 has similar issues. In RO7E7D, the textures themselves look okay (though some seem to be just plain missing), but I get similar blown-out cyan from I think bloom effects.
(07-30-2014, 01:51 AM)Sonicadvance1 Wrote: [ -> ]Could potentially be an issue in mesa with the radeon driver if you're getting issues in other games as well.
Assuming it is, how would one go about reporting such?