[Bug 43590] Rise of Nations Thrones & Patriots weird graphics

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=43590

--- Comment #8 from pe.we.psi at 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.