https://bugs.winehq.org/show_bug.cgi?id=43590
Bug ID: 43590 Summary: Rise of Nations Thrones & Patriots weird graphics Product: WineHQ Apps Database Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: appdb-unknown Assignee: wine-bugs@winehq.org Reporter: brabec.tomislav@gmail.com Distribution: ---
Created attachment 59003 --> https://bugs.winehq.org/attachment.cgi?id=59003 Weird map rendering
I have a problem with Rise of Nations: Thrones & Patriots graphics. While the basic version of game works fine, the expansion has weird rendering while playing (image).
https://bugs.winehq.org/show_bug.cgi?id=43590
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #1 from Fabian Maurer dark.shadow4@web.de --- Please fill in the fields correctly, this is not a "WineHQ Apps Database" issue.
It also would be good to know which version of wine you're running, and maybe a log.
Is this program free, or does it have a trial/demo?
https://bugs.winehq.org/show_bug.cgi?id=43590
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|appdb-unknown |-unknown Product|WineHQ Apps Database |Wine
https://bugs.winehq.org/show_bug.cgi?id=43590
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://www.gamewatcher.com | |/downloads/rise-of-nations- | |thrones-patriots-download/t | |hrones-patriots-demo Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords| |download
--- Comment #2 from Andrey Gusev andrey.goosev@gmail.com --- Confirming. Can reproduce the issue.
wine-2.15
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #3 from brabec.tomislav@gmail.com --- I have tried it on various wine versions like 1.6, 1.72, 2.15
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #4 from brabec.tomislav@gmail.com --- It is the full version of the game
https://bugs.winehq.org/show_bug.cgi?id=43590
brabec.tomislav@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |2.15
https://bugs.winehq.org/show_bug.cgi?id=43590
brabec.tomislav@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu
https://bugs.winehq.org/show_bug.cgi?id=43590
pe.we.psi@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pe.we.psi@gmail.com
--- Comment #5 from pe.we.psi@gmail.com --- I have the same problem with weird rendering in Rise of Nations in all recent wine-devel versions.
The game runs without any problems using the stable versions of wine (2.0, 2.01, 2.02) using the hints from the winehq-appdb.
The problem with the disturbed graphics (weird rendering) first occured with wine-devel 2.1 and persists until the present version (wine-devel 2.15).
https://bugs.winehq.org/show_bug.cgi?id=43590
atrinkerer@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |atrinkerer@gmail.com
--- Comment #6 from atrinkerer@gmail.com --- Not a practical workaround... But minimizing the application, and restoring it will (temporarily) cause a 'clean' re-render. Any view movement or zoom in/out will cause new rendering artifacts in the same style.
Forcing LLVM_PIPE (using LIBGL_ALWAYS_SOFTWARE=1 in environment variables) removes the issue. Framerate in software rendering suffers, though.
When not forcing software rendering, here's an excerpt of `glxinfo -B` for version info:
Extended renderer info (GLX_MESA_query_renderer): Vendor: X.Org (0x1002) Device: AMD CAYMAN (DRM 2.49.0 / 4.9.0-4-amd64, LLVM 3.9.1) (0x6719) Version: 13.0.6
https://bugs.winehq.org/show_bug.cgi?id=43590
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d
--- Comment #7 from Matteo Bruni matteo.mystral@gmail.com --- I spent some time on this and I think I know what's going on. Chatty log of the debugging process follows, feel free to skip to the end.
I'll start by mentioning that I tested the game on Windows and it does work fine there. I couldn't find anything wrong from the logs + OpenGL apitrace so I decided to take a d3d8 apitrace on Windows and figure out which draw breaks on Wine. To my surprise, replaying the d3d8 trace on Windows showed pretty much the same artifacts as Wine. That suggests either there is something drawing "out of channel" or apitrace somehow missed out on something, exactly as Wine.
Back to Linux, I see no evidence of the former. I then go back staring at the draw I found the most suspicious. Essentially the game draws all the tiles of the map normally, then this draw "darkens" some of the tiles by blending in some semitransparent black triangles. In the log that is:
0009:trace:d3d8:d3d8_device_DrawIndexedPrimitive iface 0x130468, primitive_type 0x4, min_vertex_idx 0, vertex_count 2150, start_idx 0, primitive_count 2752.
Hmm, that seems a lot of triangles to draw so few black spots (after you move the camera around a bit, at least). Checking the contents of the index and vertex buffers doesn't show anything clearly wrong. But then I happen to notice how the vertex buffer is updated:
0009:trace:d3d:wined3d_buffer_map buffer 0x57f00b0, offset 0, size 5000, data 0x32dde0, flags 0.
For the records the vertex stride is 20 bytes. That means only 250 vertices are updated. Which would be all fine and good, except that's how the buffer is mapped ALL the times, including the first time.
It turns out that the game updates the buffer outside of the mapped area. That apparently works on Windows (my guess is that the whole buffer is mapped regardless of the size - it's a DYNAMIC, WRITEONLY buffer FWIW) while in current wined3d that works only for the initial buffer upload but obviously fails for subsequent updates. Hacking the buffer map to e.g. replace size == 5000 with 100000 does avoid the bug. I initially tried to hack a DISCARD flag into the map but that didn't quite work right, which I guess means that the game doesn't overwrite the entire (used portion of the) buffer on each update.
It would be interesting to know if there are more applications doing the same. I don't see obvious generic workarounds we can do to fix this. It's worth mentioning that persistent buffer maps from ARB_buffer_storage could potentially avoid this bug.
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #8 from pe.we.psi@gmail.com --- (In reply to Matteo Bruni from comment #7)
I spent some time on this and I think I know what's going on. Chatty log of the debugging process follows, feel free to skip to the end.
I'll start by mentioning that I tested the game on Windows and it does work fine there. I couldn't find anything wrong from the logs + OpenGL apitrace so I decided to take a d3d8 apitrace on Windows and figure out which draw breaks on Wine. To my surprise, replaying the d3d8 trace on Windows showed pretty much the same artifacts as Wine. That suggests either there is something drawing "out of channel" or apitrace somehow missed out on something, exactly as Wine.
Back to Linux, I see no evidence of the former. I then go back staring at the draw I found the most suspicious. Essentially the game draws all the tiles of the map normally, then this draw "darkens" some of the tiles by blending in some semitransparent black triangles. In the log that is:
0009:trace:d3d8:d3d8_device_DrawIndexedPrimitive iface 0x130468, primitive_type 0x4, min_vertex_idx 0, vertex_count 2150, start_idx 0, primitive_count 2752.
Hmm, that seems a lot of triangles to draw so few black spots (after you move the camera around a bit, at least). Checking the contents of the index and vertex buffers doesn't show anything clearly wrong. But then I happen to notice how the vertex buffer is updated:
0009:trace:d3d:wined3d_buffer_map buffer 0x57f00b0, offset 0, size 5000, data 0x32dde0, flags 0.
For the records the vertex stride is 20 bytes. That means only 250 vertices are updated. Which would be all fine and good, except that's how the buffer is mapped ALL the times, including the first time.
It turns out that the game updates the buffer outside of the mapped area. That apparently works on Windows (my guess is that the whole buffer is mapped regardless of the size - it's a DYNAMIC, WRITEONLY buffer FWIW) while in current wined3d that works only for the initial buffer upload but obviously fails for subsequent updates. Hacking the buffer map to e.g. replace size == 5000 with 100000 does avoid the bug. I initially tried to hack a DISCARD flag into the map but that didn't quite work right, which I guess means that the game doesn't overwrite the entire (used portion of the) buffer on each update.
It would be interesting to know if there are more applications doing the same. I don't see obvious generic workarounds we can do to fix this. It's worth mentioning that persistent buffer maps from ARB_buffer_storage could potentially avoid this bug.
Very interesting findings. But it is also true, that RON runs flawlessly in wine with the stable version 2.0 and before (also at least with 2.01). The problem (weird rendering) first ocurred with development version (wine 2.1) and persists until the actual development versions. Also the newer revised stable version 2.03 now seems to be affected).
https://bugs.winehq.org/show_bug.cgi?id=43590
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #9 from mrdeathjr28@yahoo.es --- (In reply to Matteo Bruni from comment #7)
It would be interesting to know if there are more applications doing the same. I don't see obvious generic workarounds we can do to fix this. It's worth mentioning that persistent buffer maps from ARB_buffer_storage could potentially avoid this bug.
Stefan Dosinger talks about this sometime ago, maybe him can help in this case
https://bugs.winehq.org/show_bug.cgi?id=43590
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=43590
Walter Woden wodencafe@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wodencafe@gmail.com
--- Comment #10 from Walter Woden wodencafe@gmail.com --- I have this exact same problem.
Is there anything I can do to help get it figured out?
https://bugs.winehq.org/show_bug.cgi?id=43590
brymaster@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brymaster@gmail.com
--- Comment #11 from brymaster@gmail.com --- (In reply to Walter Woden from comment #10)
I have this exact same problem.
Is there anything I can do to help get it figured out?
Someone will need to run a regression test (https://wiki.winehq.org/Regression_Testing) between Wine versions 2.0 and 2.1 (where the problem first occurs) in order to find the commit responsible for the graphics corruption.
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #12 from Matteo Bruni matteo.mystral@gmail.com --- (In reply to brymaster from comment #11)
(In reply to Walter Woden from comment #10)
I have this exact same problem.
Is there anything I can do to help get it figured out?
Someone will need to run a regression test (https://wiki.winehq.org/Regression_Testing) between Wine versions 2.0 and 2.1 (where the problem first occurs) in order to find the commit responsible for the graphics corruption.
Not really: the issue is clear enough but there is no easy / quick fix. FWIW a regression test is likely to turn up efdb898befe42ebb04d5df0cc5f1b566368e9d7f as the culprit (if you want to doublecheck that, be my guest).
https://bugs.winehq.org/show_bug.cgi?id=43590
Antoine Pernot antoinepernot@mailoo.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |antoinepernot@mailoo.org
--- Comment #13 from Antoine Pernot antoinepernot@mailoo.org --- Same issue with Wine 4.0. How can I set environment variable LIBGL_ALWAYS_SOFTWARE to 1 to solve this problem ?
https://bugs.winehq.org/show_bug.cgi?id=43590
odecif@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |odecif@gmail.com
--- Comment #14 from odecif@gmail.com --- Issue persists in wine-4.5.
https://bugs.winehq.org/show_bug.cgi?id=43590
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #15 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-4.19?
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #16 from Antoine Pernot antoinepernot@mailoo.org --- The bug persists with wine-4.19
https://bugs.winehq.org/show_bug.cgi?id=43590
alberto uff.legale.spada@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |uff.legale.spada@gmail.com
--- Comment #17 from alberto uff.legale.spada@gmail.com --- Many thanks to Matteo Bruni for his detailed and very competent analysis. And even if RoN used to run smoothly in previous versions of Wine, it seems that the bug depends on some bad programming in the extended version, somehow masked by features of Windows. After all, Bruni's d3d8 api trace showed the same artifacts as Wine. Thus, I wouldn't really blame Wine for that, but I'm also afraid that a fix is unlikely. I also set LIBGL_ALWAYS_SOFTWARE to 1 but the weird graphics was still there. On the other hand, the original version runs very well once one applies the workarounds; a pity that we can't transplant the the graphics sections of rise.exe to patriots.exe... ;-)
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #18 from odecif@gmail.com --- Bug still present in wine-7.10.
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #19 from odecif odecif@gmail.com --- Bug still present in wine-8.6.
https://bugs.winehq.org/show_bug.cgi?id=43590
--- Comment #20 from odecif odecif@gmail.com --- Bug still present in wine-9.8
-
wine-bugs＠winehq.org -
WineHQ Bugzilla