http://bugs.winehq.org/show_bug.cgi?id=10387
Summary: Civilization 4 world overview sphere rendered/lit incorrectly Product: Wine Version: 0.9.49. Platform: Other OS/Version: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: hein@kde.org CC: stefandoesinger@gmx.at
Created an attachment (id=9066) --> (http://bugs.winehq.org/attachment.cgi?id=9066) Wine v0.9.49 rendering Civ4: Beyond the Sword v3.13's world overview incorrectly
Firaxis' turn-based strategy game Civilization 4 is played on a 3D game board modelling the surface of a planetoid. When the camera is close to the ground, the curvature of the planetoid is not discernable. When zooming out, i.e. moving the camera away from the ground, the landscape gradually morphs into a sphere.
While Wine 0.9.49 renders the landscape correctly in all areas of the game board when the camera is close to the ground, at some point when moving the camera further out parts of the surface stop being rendered or lit correctly. Areas of the map that should be brightly rendered are dark, with a hard transition between the correctly and the incorrectly rendered areas of the sphere. There does not appear to be a relationship between the demarcation line and the game logic, as it doesn't follow the game's fog-of-war or border simulation systems.
Tested releases include 0.9.38, 0.9.44, 0.9.48 and 0.9.49. The problem exists in all of them. I have reason to believe, based on experiences while bisecting for an unrelated bug (#9736), that there exists a git revision between 0.9.44 and 0.9.49 where the problem is not apparent, but have so far been unable to reproduce and track down that revision again.
The Wine configuration is fairly untouched. The Windows version is set to Windows 2000. Pixel and vertex shader support is enabled. Microsoft's MSXML 3 was installed and related DLL overrides added, which is necessary to run the game.
The tested version of the game is the very latest, namely "Civilization 4: Beyond the Sword" at patch level 3.13. "Beyond the Sword" is the second commercial expansion/upgrade pack to the original title, and the preferred version to play the game.
Testing was undertaken using nVidia's proprietary graphics driver in version 100.14.19 on a GeForce 8800 GTX, with X.org v7.3 (xorg-server v1.4) and Linux v2.6.23.1. The distribution is Gentoo Linux.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #1 from Eike Hein hein@kde.org 2007-11-10 10:52:19 --- I set out to provide more data on this problem, and once again employed the sub-frame dumping patch sent to be Stefan as well as Wine's debug logging faclities. The operation ended up dumping 4203 sub-frame and texture files each, and 600 MB uncompressed log, for a whopping 14.6 GB of data in total (my poor little disk!). The problem is first apparent in subframe #12, with a very interesting progression.
In the following posts I'm going to attach relevant subframes converted to JPEG, as well as the log file, chopped into several segments and compressed using lrzip.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #2 from Eike Hein hein@kde.org 2007-11-10 10:54:25 --- Created an attachment (id=9071) --> (http://bugs.winehq.org/attachment.cgi?id=9071) Subframe just prior to the first appearance of the problem.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #3 from Eike Hein hein@kde.org 2007-11-10 10:55:03 --- Created an attachment (id=9072) --> (http://bugs.winehq.org/attachment.cgi?id=9072) First appearance of the problem in subframe #12.
Notice the star field being hidden by the parts that are black but shouldn't be.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #4 from Eike Hein hein@kde.org 2007-11-10 10:55:39 --- Created an attachment (id=9073) --> (http://bugs.winehq.org/attachment.cgi?id=9073) Cloud layer being added in subframe #20.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #5 from Eike Hein hein@kde.org 2007-11-10 10:56:01 --- Created an attachment (id=9074) --> (http://bugs.winehq.org/attachment.cgi?id=9074) Finished frame at subframe #4203.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #6 from Eike Hein hein@kde.org 2007-11-10 11:19:51 --- Created an attachment (id=9076) --> (http://bugs.winehq.org/attachment.cgi?id=9076) Log file part 1/3
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #7 from Eike Hein hein@kde.org 2007-11-10 11:33:19 --- Created an attachment (id=9077) --> (http://bugs.winehq.org/attachment.cgi?id=9077) Log file part 2/4
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #8 from Eike Hein hein@kde.org 2007-11-10 11:33:49 --- Created an attachment (id=9078) --> (http://bugs.winehq.org/attachment.cgi?id=9078) Log file part 3/4
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #9 from Eike Hein hein@kde.org 2007-11-10 11:34:11 --- Created an attachment (id=9079) --> (http://bugs.winehq.org/attachment.cgi?id=9079) Log file part 4/4
http://bugs.winehq.org/show_bug.cgi?id=10387
Eike Hein hein@kde.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #9076|Log file part 1/3 |Log file part 1/4 description| |
http://bugs.winehq.org/show_bug.cgi?id=10387
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |trivial
--- Comment #10 from Vitaliy Margolen vitaliy@kievinfo.com 2007-11-10 14:24:33 --- DID ANYONE ASKED YOU TO ATTACH THAT MUCH CRAP?
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #11 from Stefan Dösinger stefandoesinger@gmx.at 2007-11-10 15:03:55 --- Vitaliy: I did, sort of(on irc).
The subframe dumping output is the only really useful info, unfortunately it comes with at least two(ideally 3) screenshots, and a logfile. It's just that the logfile becomes rather big.
In most cases the log of the last frame is enough for a start, which means the call between the two last IWineD3DSwapChainImpl_Present calls.
So it was my fault of not beeing clear on what parts of the logs are needed.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #12 from Eike Hein hein@kde.org 2007-11-10 15:45:26 ---
DID ANYONE ASKED YOU TO ATTACH THAT MUCH CRAP?
First of, yes. Second, as a developer myself, I tend to value comprehensive bug reports over a dearth of data, and like that data to be preserved for posterity in the bug tracker. Other developers apparently tend to agree (such as Stefan, who was unhappy when I hosted the log externally the last time around to avoid having to post segments to the tracker).
Third, did anyone ask you to be a dick and scream around in all caps? :-)
http://bugs.winehq.org/show_bug.cgi?id=10387
olivier gizmm0@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gizmm0@hotmail.com
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #13 from Stefan Dösinger stefandoesinger@gmx.at 2007-11-30 10:12:28 --- A problem is that we don't know if frame 12 is supposed to draw all of the map already, or if the next draw calls are supposed to add the rest of the parts that were left black in 12. I.E., is the issue in draw 12 itself, or in 13, 14, 15, ...
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #14 from Eike Hein hein@kde.org 2007-11-30 10:16:13 --- Is there some way I could produce data for you to answer that question?
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #15 from Stefan Dösinger stefandoesinger@gmx.at 2007-11-30 10:20:05 --- That's tricky :-(
One way is the tool PixWin.exe in the dx9 sdk. It can generate logs and frame captures similarly to the subframe dumper. Then we can see how it is supposed to be drawn. The problem is that games can refuse to run in PixWin.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #16 from Eike Hein hein@kde.org 2007-11-30 10:22:35 --- Presuming that I can track down PixWin.exe somewhere (or, say, you hand it to me via mail or IRC), would I run that in Wine or on WinXP?
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #17 from Eike Hein hein@kde.org 2007-11-30 11:25:59 --- Status update: While I managed to get ahold of the DX9 November SDK and set up PixWin and the game on Windows (only to be thwarted by the fact that PixWin's F12 dumping trigger is also a game-relevant shortcut that takes me away from the screen I actually want to log), Stefan has done some debugging and analysis on his end. Now we know that the world sphere works fine if OffscreenRenderingMode is set to use Frame Buffer Objects (FBO), but fails with the preferred default methods for offscreen rendering that are friendlier to drivers other than nVidia.
http://bugs.winehq.org/show_bug.cgi?id=10387
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #18 from Stefan Dösinger stefandoesinger@gmx.at 2007-12-18 07:36:48 --- fixed in 0.9.51. It needs fbos or pbuffers to work properly.
http://bugs.winehq.org/show_bug.cgi?id=10387
--- Comment #19 from Stefan Dösinger stefandoesinger@gmx.at 2007-12-18 07:43:15 --- The problem with pbuffer and aux buffer orm was that the scissor test was set up incorrectly when clearing, and it remained set up when blitting the offscreen texture to the pbuffer / aux buffer. aux buffer orm additionally has the problem that the offscreen texture is bigger than the screen(2048x2048), so the offscreen texture gets cut off, which causes the problems observed in this screenshot.
http://bugs.winehq.org/show_bug.cgi?id=10387
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Dan Kegel dank@kegel.com 2008-01-28 05:44:47 --- Closing all RESOLVED FIXED bugs older than four weeks.
-
wine-bugs＠winehq.org