http://bugs.winehq.org/show_bug.cgi?id=17423
Summary: Prince of Persia SoT: Graphic Bug Product: Wine Version: 1.1.15 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: mcflow-forum@gmx.net CC: stefan@codeweavers.com
With wine-1.1.15 a graphic bug was introduced to Prince of Persia - The Sand of Time. Graphics are not displayed properly. See the attachment for how it looks. Because it worked with wine-1.1.14 I did a regression test. This is what it returned:
693d9ded47d56846c3dafe7d04115a4f3a01750a is first bad commit commit 693d9ded47d56846c3dafe7d04115a4f3a01750a Author: Stefan Dösinger stefan@codeweavers.com Date: Sat Jan 10 02:29:39 2009 +0100
wined3d: Properly set the fog frag coord according to the FOGTABLEMODE.
This also fixes the test that an earlier patch broke, so the todo_wine can be removed again.
:040000 040000 d6c96e24ebde7212191b4113d6d55a1bdcd073f1 745e7693925a3ab9384ff77141aad74d082bc23e M dlls
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #1 from Florian mcflow-forum@gmx.net 2009-02-16 10:32:25 --- Created an attachment (id=19492) --> (http://bugs.winehq.org/attachment.cgi?id=19492) Graphic bug with 1.1.15
http://bugs.winehq.org/show_bug.cgi?id=17423
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=17423
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
--- Comment #2 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-16 12:57:18 --- Hi, Can you attach a +d3d,+d3d_shader log? Maybe I missed some details in the fog setup.
I think Vitaliy once fixed a bug in this game that looked exactly the same way. It is likely that my patch reintroduced the old problem accidentally.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #3 from Florian mcflow-forum@gmx.net 2009-02-16 15:32:19 --- Here is the attached log. The game ran just quite short and the unpacked size is like 300 mb. I did not find a section where to cut the log so I put the complete log here: http://uploaded.to/?id=skwkoq The compressed size is 12,5 Mb.
http://bugs.winehq.org/show_bug.cgi?id=17423
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #4 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-16 16:18:30 --- Confirming. Didn't you just fixed it few weeks ago?
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #5 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-20 06:33:49 --- I can reproduce this bug with the demo
What confuses me though is that the fog behavior this game expects is different from what my test shows. The game uses vertex shaders that write fog coords, and sets D3DRS_FOGTABLEMODE to linear fog. FOGVERTEXMODE is zero. My test says that in this case the vertex shader fog coord is ignored and d3d always uses the Z coordinate, because per-vertex fog coordinates only work with per-vertex fog(FOGTABLEMODE = NONE). The game however expects the vertex shader fog coordinates to be used.
I can think of 3 possibilities:
1) I missed something and my test is wrong 2) There is some capability flag that changes the behavior, and POPSOT might behave differently on Windows than on Wine due to caps differences 3) There's some game specific quirk in the Windows driver.
http://bugs.winehq.org/show_bug.cgi?id=17423
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |a.vankaam@chello.nl
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #6 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-21 08:53:40 --- I tested this on an ATI card(my old radeon 9000 mobility). This driver behaves differently - as the game seems to expect it. I'll see what the reference rasterizer does...
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #7 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-21 12:03:48 --- The refrast sides with the Nvidia driver.
My imagination is that something like this happened:
1) ATI and Nvidia program their drivers to honor the fog coord with table fog 2) Ubisoft writes POPSOT with this in mind 3) Nvidia figures out that its driver behaves differently than the refrast and adjusts the driver 4) Nvidia figures out that they just broke POPSOT and make a game-specific hack(The nvidia devs tell me that there are lots of them in their win drv) 5) We're left in the cold wondering what is wrong.
The ATI behavior(the one the game expects) is more intuitive(I originally expected it when writing the test), and its more flexible. The refrast/nvidia behavior is the more consistent one - it matches the fixed function pipeline's fog behavior.
I don't know what to do with this now. We could just change Wine to use the vertex shader fog coord instead of the depth if a fog coord is written and table fog used. That would fix the game, but then another game may come around that requires the opposite behavior.
Another potential clue is this website: http://news.softpedia.com/news/Prince-of-Persia-The-Sands-of-Time-Fixes-and-... It talks in a sentence about fog problems on some ATI drivers(later ones than the one for my laptop). Probably ATI changed their driver to behave like the refrast too, missed the issue with this game and fixed it in an update. I don't have an up to date ATI card+driver to check that.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #8 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-21 14:30:38 --- riclas on #winehackers ran a test app for me on the newest ATI driver. This driver behaves like my NV driver and the refrast(ie, it ignores the vertex shader fog coord too)
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #9 from Vitaliy Margolen vitaliy@kievinfo.com 2009-02-21 14:39:32 --- Let me ask this question - why did it work before? Was the fix that broke PoP SoT required by any other application?
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #10 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-21 15:04:25 --- Created an attachment (id=19596) --> (http://bugs.winehq.org/attachment.cgi?id=19596) Hack for GLSL
It wasn't required by any application I know of. I just ran into this behavior when I extended the fog test to figure out how the vertex shader fog coord is handled in native d3d, and I implemented it.
Originally WineD3D didn't touch the GL fog coordinate if the shader wrote its own. My test revealed that D3D fog coordinate isn't used with table fog, so I changed it. The attached hack reverts this behavior for GLSL shaders. In ARB this can be done in a similar way.
I could of course send this in as a fix for a regression, but since it breaks(*) an existing test on ATI, NV and the refrast we'll have a hard time arguing that it is correct.
Besides, since at least ATI changed the behavior somewhen in the past, it is pretty likely that there's some other application out in the wild that depends on the behavior my test demonstrates.
The correct fix for this is to demonstrate that the NV and ATI drivers have a game specific hack for this, find out how the hack is triggered, and implement the same hack in Wine. If possible we'd also want a test app that triggers the game specific hack in the Windows drivers.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #11 from Stefan Dösinger stefandoesinger@gmx.at 2009-02-21 15:07:02 --- (*) What I wanted to say here: Its quite possible to sneak this hack past the test because there's only a small difference in the test's setup, and a pretty high tolerance for different colors. I think(haven't tested) that the test accepts the results produced by my patch.
If you modify the vertex shader 2 in the test to produce values that are vastly different from the z values the difference becomes obvious.
http://bugs.winehq.org/show_bug.cgi?id=17423
Caladan a.vankaam@chello.nl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|a.vankaam@chello.nl |
http://bugs.winehq.org/show_bug.cgi?id=17423
Ivanov d137@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |d137@abv.bg
--- Comment #12 from Ivanov d137@abv.bg 2009-08-09 00:41:51 --- (In reply to comment #11)
(*) What I wanted to say here: Its quite possible to sneak this hack past the test because there's only a small difference in the test's setup, and a pretty high tolerance for different colors. I think(haven't tested) that the test accepts the results produced by my patch.
If you modify the vertex shader 2 in the test to produce values that are vastly different from the z values the difference becomes obvious.
Any progress with this bug yet ? Still not working wine 1.1.27 NVidia 180.44
Would be happy to see it fixed some day - it also affexts the game "Crashday"
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #13 from Ivanov d137@abv.bg 2009-08-09 00:42:22 --- (In reply to comment #11)
(*) What I wanted to say here: Its quite possible to sneak this hack past the test because there's only a small difference in the test's setup, and a pretty high tolerance for different colors. I think(haven't tested) that the test accepts the results produced by my patch.
If you modify the vertex shader 2 in the test to produce values that are vastly different from the z values the difference becomes obvious.
Any progress with this bug yet ? Still not working wine 1.1.27 NVidia 180.44
Would be happy to see it fixed some day - it also affects the game "Crashday"
http://bugs.winehq.org/show_bug.cgi?id=17423
Vincent Povirk madewokherd@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
http://bugs.winehq.org/show_bug.cgi?id=17423
GyB gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #14 from GyB gyebro69@gmail.com 2010-05-11 11:08:28 --- Is turning off "fog effects" in the game corrects the issue?
If so, then you can find reference to the issue across the web. This is a known incompatibility with some newer Nvidia drivers, using Windows, too. There are traces of the issue on several forums, e.g. Steam, Nvidia and on my favourite digital distribution site: http://www.gog.com/en/forum/prince_of_persia_the_sands_of_time/fog_has_to_be...
http://bugs.winehq.org/show_bug.cgi?id=17423
Xavier Vachon xvachon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xvachon@gmail.com
--- Comment #15 from Xavier Vachon xvachon@gmail.com 2010-07-10 11:27:16 --- (In reply to comment #14)
Is turning off "fog effects" in the game corrects the issue?
If so, then you can find reference to the issue across the web. This is a known incompatibility with some newer Nvidia drivers, using Windows, too. There are traces of the issue on several forums, e.g. Steam, Nvidia and on my favourite digital distribution site: http://www.gog.com/en/forum/prince_of_persia_the_sands_of_time/fog_has_to_be...
In current git (1.2-rc7), turning off fog effects worksaround this bug.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #16 from Ivanov d137@abv.bg 2011-07-03 08:55:55 CDT --- (In reply to comment #15)
(In reply to comment #14)
Is turning off "fog effects" in the game corrects the issue?
If so, then you can find reference to the issue across the web. This is a known incompatibility with some newer Nvidia drivers, using Windows, too. There are traces of the issue on several forums, e.g. Steam, Nvidia and on my favourite digital distribution site: http://www.gog.com/en/forum/prince_of_persia_the_sands_of_time/fog_has_to_be...
In current git (1.2-rc7), turning off fog effects worksaround this bug.
Bug still exists in 1.3.23. Bug also exists with nouveau driver. Bug affects also other games. Patch does not apply to 1.3.23. I try to apply the patch manually now.
Cheers, Damian
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #17 from Ivanov d137@abv.bg 2011-07-03 09:07:40 CDT ---
In current git (1.2-rc7), turning off fog effects worksaround this bug.
Bug still exists in 1.3.23. Bug also exists with nouveau driver. Bug affects also other games. Patch does not apply to 1.3.23. I try to apply the patch manually now.
Cheers, Damian
Patch does NO loger fix this issue. Could You help in doing a *new* hack, please?
Cheers, Damian
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #18 from Ivanov d137@abv.bg 2011-07-03 10:53:47 CDT --- Created an attachment (id=35415) --> (http://bugs.winehq.org/attachment.cgi?id=35415) for 1.3.23
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #19 from Ivanov d137@abv.bg 2011-07-03 10:54:28 CDT --- Ok actually the patch still fixes this with nVidia binary driver. With nouveau they look weird in different ways. Attached the .patch working for 1.3.23.
Cheers, Damian
http://bugs.winehq.org/show_bug.cgi?id=17423
Henri Verbeet hverbeet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |693d9ded47d56846c3dafe7d041 | |15a4f3a01750a
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #20 from Stefan Dösinger stefandoesinger@gmx.at 2011-08-28 13:11:41 CDT --- (In reply to comment #16)
Bug affects also other games.
Damian, can you specify which games are affected? Popsot and Crashday have been mentioned, are there any others?
I think I have Crashday around somewhere, I'll give it a try.
http://bugs.winehq.org/show_bug.cgi?id=17423
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #21 from joaopa jeremielapuree@yahoo.fr 2011-08-28 13:17:21 CDT --- Does the bug occur in the demo http://www.gamershell.com/download_4925.shtml ?
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #22 from Stefan Dösinger stefandoesinger@gmx.at 2011-08-28 15:32:57 CDT --- In Crashday I can see some odd bug covering the HUD, but not the in-game graphics. The fog gets better with the hack, but isn't gone entirely. I have serious doubts that the fog is supposed to be there at all, but I'll give the game a try on Windows to see what is supposed to look like
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #23 from Stefan Dösinger stefandoesinger@gmx.at 2011-08-28 16:52:07 CDT --- on Windows there's no fog covering the crashday HUD and loading screen - neither the thick fog with vanilla wine, nor the thin fog with the hack. I think that the Crashday issue is somewhere else - It isn't the type of fog that's broken, the fog shouldn't be there in the first place.
popsot is broken on Windows in the same way it is on Wine, at least on my Geforce 9600 GPU on Windows 7. A Google search for "prince of persia sands of time fog" brings up a lot of discussions about this issue on Windows with some game settings that work around the issue without disabling fog, for example:
http://forums.ubi.com/eve/forums/a/tpc/f/561108232/m/9731069478 http://forums.steampowered.com/forums/showthread.php?t=1090051 http://forums.nvidia.com/index.php?showtopic=151881
I suggest to close this bug as wontfix and deal with the Crashday issue in a separate bug. Before I do that I'd like to hear from Damian Ivanov which "other games" he meant that are affected by the bug as well.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #24 from Stefan Dösinger stefandoesinger@gmx.at 2011-08-29 15:57:59 CDT --- Ok, the crashday issue is the same as bug 27733(Fog coordinate vs projection matrix). Matteo has done some debugging on 27733 and will post an explanation there.
A short summary: the broken draws don't use vertex shaders, they're done with the fixed function pipeline. The last row of the projection matrix is 0, 0, 0, 1, which is a special case in d3d where the depth after the projection transformation is used for fogging rather than the pre-projection depth. Unfortunately opengl doesn't support anything similar, so we need a fixed function pipeline replacement shader to actually fix this.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #25 from Stefan Dösinger stefandoesinger@gmx.at 2011-08-29 17:40:37 CDT --- Actually the crashday issue is not related to bug 27733 because the game uses pretransformed vertices. It looks like the range fog causes issues with pretransformed vertices and should be disabled in this case. I'll write a test and fix. It's still time to move the Crashday issue into its own bug report.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #26 from Damian Ivanov damianatorrpm@gmail.com 2011-09-17 22:15:28 CDT --- Yeah, I found after your posts that the Crashday issue is http://bugs.winehq.org/show_bug.cgi?id=18505 and again a poster says it's all nVidia's fault :( The other games would be the other early Prince of Persia games.
PS: Is it possible for me (or how could I do it :) ) to make some hackish style patch for my *personal* wine, like
if(WINE_EXE_NAME == PoP.exe) { if(args->fog_src == VS_FOG_Z) { - shader_addline(buffer, "gl_FogFragCoord = gl_Position.z;\n"); + if(!reg_maps->fog) { + shader_addline(buffer, "gl_FogFragCoord = gl_Position.z;\n"); + } else { + FIXME("Shader writes fog coord and table fog is used\n"); + } } else if (!reg_maps->fog) { shader_addline(buffer, "gl_FogFragCoord = 0.0;\n"); } else { whatever }
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #27 from Damian Ivanov damianatorrpm@gmail.com 2011-09-17 22:17:53 CDT --- Of course I don't mean with the diff "+", "-" etc., but the logic behind it, like another registry file or switch application based, so it is working out of the box :)
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #28 from Stefan Dösinger stefandoesinger@gmx.at 2011-09-18 17:10:27 CDT --- Look at dlls/wined3d/wined3d_main.c, there are a few settings that can be changed by registry keys. However, the chances that such a hack gets committed to Wine are probably nil because we don't do per-app hacks. That the app is broken on Windows shows that the bug is clearly in the app, and not Wine. Furthermore the value of such a hack would be fairly small because the user has to enable it manually and the bug can also be worked around by editing the game's config files.
If you have a Windows machine where the game is broken in the same way you could try to run it in compatibility mode(Win98, WinME, Win2k) and see if any of those modes changes the behavior. I can imagine that Windows falls back to the behavior that cards showed in the times of Win98 if you enable Win98 compatibility. If not we should close this bug as WONTFIX.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #29 from Damian Ivanov damianatorrpm@gmail.com 2011-09-18 23:45:34 CDT --- I fully agree with you that this bug is wontfix and wine will not accept per-app hacks in main :) I'd be happy if you explain me how I can implement for my personal wine a per-app hack, maybe not in bugzilla but @mail
http://bugs.winehq.org/show_bug.cgi?id=17423
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |stefan@codeweavers.com Resolution| |WONTFIX
--- Comment #30 from Stefan Dösinger stefan@codeweavers.com 2011-10-15 12:16:31 CDT --- Closing this as WONTFIX. The game has the same bug in Windows. Workarounds for Windows in the game config files fix the bug on Wine as well.
http://bugs.winehq.org/show_bug.cgi?id=17423
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |INVALID
--- Comment #31 from Dmitry Timoshkov dmitry@baikal.ru 2011-10-16 03:12:46 CDT --- It's rather invalid.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #32 from Damian Ivanov damianatorrpm@gmail.com 2011-10-16 03:39:31 CDT --- I just came across this bug again. When it's in winecfg set to WinXP shouldn't it behave correctly then... AFAIK the version in winecfg should emulate the corresponding behaviour.
http://bugs.winehq.org/show_bug.cgi?id=17423
--- Comment #33 from Stefan Dösinger stefan@codeweavers.com 2011-10-16 04:32:35 CDT --- The Windows version doesn't matter, it's the GPU driver that triggers this bug on Windows. I haven't tested this, but I think with a new enough GPU(dx10 class probably) and driver you'll get this issue on WinXP too, and probably even on Win2k.
Windows 98 may be a different matter because new drivers for this system might not be available. But we don't emulate behavior differences in older Windows versions, with very few exceptions(like the reported Windows version and different treatment for some exceptions like invalid instructions)
http://bugs.winehq.org/show_bug.cgi?id=17423
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #34 from Austin English austinenglish@gmail.com 2011-10-17 16:06:30 CDT --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=17423
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andrey.goosev@gmail.com
--- Comment #35 from Andrey Gusev andrey.goosev@gmail.com --- *** Bug 43397 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org