[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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #21 from Raditz12 <a25422@ua.pt> --- Is this bug still present in latest Wine version? If yes, I'm guessing from the comments here it's an impossible one to solve? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 Stefan Dösinger <stefan@codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com --- Comment #22 from Stefan Dösinger <stefan@codeweavers.com> --- I don't have the game to test myself, but my expectation is that this should work on modern d3d10+ hardware. With coherent and persistent maps we can let the game write directly into the GPU's memory (or the driver decides to keep everything in system memory and transfer on demand on draws). The map range is ignored in this case, so it doesn't matter that the game passes bad data there. d3d10/11 removed the map start + length from buffers entirely, so in practise a card+driver that supports d3d10 should also allow these badly behaved d3d9 and earlier games to work. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #23 from odecif <odecif@gmail.com> --- Raditz12 Yes, this bug is still present in wine11.0. Stefan I just tested this on my desktop with a Ryzen 9 9950X and an RTX 3070 in a clean prefix on wine11.0 and I still see the bug. Should I verify with different Directx-versions from winetricks as well or are there any other overrides I may need to apply? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #24 from Stefan Dösinger <stefan@codeweavers.com> --- This card should be new enough to have coherent buffers. I guess we have to go back to the drawing board... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #25 from Raditz12 <a25422@ua.pt> --- It's a pity :(. odecif, did you end up trying those different overrides/possibilities? Not sure it's worth a try? In my case (running on a compiled Wine 9.0, with an old onboard Intel HD 3000 graphics), the capabilities of the GPU are a lot less, but tomorrow I might try some winetricks magic and my luck with this too. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #26 from Stefan Dösinger <stefan@codeweavers.com> --- I had a look at this. The reason why coherent maps aren't used is here:
0158:trace:d3d8:d3d8_vertexbuffer_Lock iface 089D06F0, offset 0, size 5000, data 020D1394, flags 0.
This triggers the first like of this check in wined3d/buffer.c:
if (((flags & WINED3D_MAP_WRITE) && !(flags & (WINED3D_MAP_NOOVERWRITE | WINED3D_MAP_DISCARD))) || (!(flags & WINED3D_MAP_WRITE) && (buffer->locations & WINED3D_LOCATION_SYSMEM)) || buffer->resource.pin_sysmem || !(buffer->flags & WINED3D_BUFFER_USE_BO))
And we fall back to returning a heap memory allocation to the game and then uploading it with glBufferSubData. This of course means we rely on the game's lie. This check which triggers the fallback to sysmem+upload was introduced in afb2aa2512d4c5ffa7256ce5137bc2c142a5d065 as a performance improvement. Removing it, stalling the pipeline but then letting the game write directly into the GL buffer object fixes drawing in this game but will likely cause performance issues in other games. Maybe a compromise solution would be to ignore the map range when we see that the game is doing a synchronized map of a dynamic buffer. If we stall the render pipeline doing a full upload probably won't make much of a difference - depending on the buffer size of course. Another potential issue, but it doesn't apply to this game, is that there are a few other conditions that cause us to fall back to sysmem+upload mode. One annoying one is if the game uses the buffer with a stride of 0, which means a static attribute. OpenGL has no way to load static attributes from VBOs. They have to be specified with old immediate mode vertex attribute calls, and the VBO spec explicitly states that a pointer into a VBO map must not be passed to them. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #27 from Raditz12 <a25422@ua.pt> --- Wow, thx so much for your time and for looking into it! Altough I don't understand all this d3d stuff, I can see the general idea and source of the bug. I trust the expert to take the best solution/compromise possible :). And if there's none, I guess one can always build a separate Wine installation (just for RoN) with the solution you mentioned, altough would be cool to get a global fix for everyone. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #28 from Raditz12 <a25422@ua.pt> ---
This check which triggers the fallback to sysmem+upload was introduced in afb2aa2512d4c5ffa7256ce5137bc2c142a5d065 as a performance improvement. Removing it, stalling the pipeline but then letting the game write directly into the GL buffer object fixes drawing in this game but will likely cause performance issues in other games.
Could you provide a patch that does the above? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #29 from Raditz12 <a25422@ua.pt> --- Tried to test multiple DX dll native overrides (and other graphic settings) from winetricks but no luck. Really hope there's a way at the end, even if only the above one I asked. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 eric5 <star989z989@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |star989z989@gmail.com --- Comment #30 from eric5 <star989z989@gmail.com> --- Just ran into this, good to know it's not just me. Interesting technical problem. However as a workaround that doesn't require patching wine, I found that dgVoodoo (v2.79.3) fixes the problem completely. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 cvt67mustang@hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cvt67mustang@hotmail.com --- Comment #31 from cvt67mustang@hotmail.com --- (In reply to eric5 from comment #30)
Just ran into this, good to know it's not just me. Interesting technical problem. However as a workaround that doesn't require patching wine, I found that dgVoodoo (v2.79.3) fixes the problem completely.
That's great to hear. Can you provide any details on the install and settings? I was not able to replicate with dgVoodoo 2.79.3. Thanks. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #32 from Brian <cvt67mustang@hotmail.com> --- (In reply to Brian from comment #31)
(In reply to eric5 from comment #30)
Just ran into this, good to know it's not just me. Interesting technical problem. However as a workaround that doesn't require patching wine, I found that dgVoodoo (v2.79.3) fixes the problem completely.
That's great to hear. Can you provide any details on the install and settings? I was not able to replicate with dgVoodoo 2.79.3. Thanks.
Update: I am able to confirm using dgVoodoo 2.79.3 and setting an override for d3d8.dll resolves the graphics issue completely. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #33 from Raditz12 <q41000@yahoo.com.br> --- Just checked this and super happy to see a potential solution, thanks so much :). However, when I tried to test dgVoodoo and launch the game, I got a black screen, with the game sound (and the game itself) playing in the background, the game mouse pointer icon visible and movable, and the dgVoodoo logo on the bottom-right corner. Do you have any idea what might be causing this? Tested several suggestions but with no luck :(. The steps I did:
Got dgVoodoo 2.79.3 Copied 'dgVoodooCpl.exe', 'dgVoodoo.conf' and 'D3D8.dll' into my game folder Set an override for d3d8 (native) in winecfg
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #34 from odecif <odecif@gmail.com> --- A new comment was posted by "Andreas Gehring" on the RoN Gold Edition-page with a fix on how to fix the graphical issues. Quote: ``` The terrain draw path is basically identical between broken Patriots and working Nations. Same FVF 0x244, same stride 36, same render states, same texture-stage states, same indexed terrain draw shape. So the bug was not bad terrain generation or a missing draw state. The difference was where the terrain vertex buffers live: PATRIOTS: CreateVertexBuffer(... usage 0x208, fvf 0, pool 0 ...) NATIONS: CreateVertexBuffer(... usage 0x208, fvf 0, pool 2 ...) pool 0 = D3DPOOL_DEFAULT is default/device memory behavior. pool 2 = D3DPOOL_SYSTEMMEM is system-memory style behavior. Patriots was using the default-pool dynamic vertex-buffer path, and WineD3D/dxwrapper apparently mishandled that reuse/update pattern after scrolling. The patch forces that one Patriots d3dgl.dll vertex-buffer creation path to use the Nations-style pool: ; original and ebx, 0x2 push ebp push ebx ; patched push ebp push 0x2 nop nop Exact patch: Thrones and Patriots/d3dgl.dll 0xb510 / VA 0x40a3b510 83 e3 02 55 53 -> 55 6a 02 90 90 ``` In my case the hex was located at 0x8dd7 instead of 0xb510 but the patch did indeed work! -- 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.
http://bugs.winehq.org/show_bug.cgi?id=43590 --- Comment #35 from Raditz12 <q41000@yahoo.com.br> --- This does work, incredible :D. For me, was also on 0x8DD7. Cannot thank Andreas Gehring enough. Thanks odecif too for posting it here! -- 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 (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla
-
WineHQ Bugzilla