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

[wine-bugs at winehq.org]

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

Matteo Bruni <matteo.mystral at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|-unknown                    |directx-d3d

--- Comment #7 from Matteo Bruni <matteo.mystral at 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.