[Bug 43590] New: Rise of Nations Thrones & Patriots weird graphics
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(a)winehq.org Reporter: brabec.tomislav(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4(a)web.de --- Comment #1 from Fabian Maurer <dark.shadow4(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|appdb-unknown |-unknown Product|WineHQ Apps Database |Wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Andrey Gusev <andrey.goosev(a)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(a)gmail.com> --- Confirming. Can reproduce the issue. wine-2.15 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #3 from brabec.tomislav(a)gmail.com --- I have tried it on various wine versions like 1.6, 1.72, 2.15 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #4 from brabec.tomislav(a)gmail.com --- It is the full version of the game -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 brabec.tomislav(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |2.15 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 brabec.tomislav(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Ubuntu -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 pe.we.psi(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pe.we.psi(a)gmail.com --- Comment #5 from pe.we.psi(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 atrinkerer(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |atrinkerer(a)gmail.com --- Comment #6 from atrinkerer(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |directx-d3d --- Comment #7 from Matteo Bruni <matteo.mystral(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #8 from pe.we.psi(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28(a)yahoo.es -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #9 from mrdeathjr28(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 mrdeathjr28(a)yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger(a)gmx.at -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Walter Woden <wodencafe(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wodencafe(a)gmail.com --- Comment #10 from Walter Woden <wodencafe(a)gmail.com> --- I have this exact same problem. Is there anything I can do to help get it figured out? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 brymaster(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |brymaster(a)gmail.com --- Comment #11 from brymaster(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #12 from Matteo Bruni <matteo.mystral(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 Antoine Pernot <antoinepernot(a)mailoo.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antoinepernot(a)mailoo.org --- Comment #13 from Antoine Pernot <antoinepernot(a)mailoo.org> --- Same issue with Wine 4.0. How can I set environment variable LIBGL_ALWAYS_SOFTWARE to 1 to solve this problem ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 odecif(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |odecif(a)gmail.com --- Comment #14 from odecif(a)gmail.com --- Issue persists in wine-4.5. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #15 from joaopa <jeremielapuree(a)yahoo.fr> --- Does the bug still occur with wine-4.19? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #16 from Antoine Pernot <antoinepernot(a)mailoo.org> --- The bug persists with wine-4.19 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 alberto <uff.legale.spada(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |uff.legale.spada(a)gmail.com --- Comment #17 from alberto <uff.legale.spada(a)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... ;-) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #18 from odecif(a)gmail.com --- Bug still present in wine-7.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #19 from odecif <odecif(a)gmail.com> --- Bug still present in wine-8.6. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #20 from odecif <odecif(a)gmail.com> --- Bug still present in wine-9.8 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla