HansKristian-Work / vkd3d-proton

Fork of VKD3D. Development branches for Proton's Direct3D 12 implementation.
GNU Lesser General Public License v2.1
1.87k stars 194 forks source link

Age of Empires 4 (1466860) most units fail to render #880

Closed aeikum closed 2 years ago

aeikum commented 2 years ago

Most of the in-game unit graphics fail to render in Age of Empires 4. Screenshot and log attached, notice the floating swords in the bottom-left.

The game is playable currently on the bleeding-edge branch of Proton Experimental. (Just needed 06104aec963 picked from upstream Wine to become playable.)

steam-1466860.log

Screenshot_2021-10-28_11-07-00

tkamat commented 2 years ago

vkd3d.log

I can reproduce the behavior above, I generated logs using the trace debug feature. It's hard to make out what the issue is due to "ignoring optimized clear value" and "Extended dynamic state is supported, but compiling a fallback pipeline late!" being repeated a bunch.

This line is also repeated a lot: "got NULL index buffer view, indexed draw calls will be dropped". Could have something to do with the missing unit models.

sulix commented 2 years ago

FYI: I got a RenderDoc trace (albeit of the resulting Vulkan calls, not of the D3D12 calls) of this issue from the Stress Test:

https://davidgow.net/stuff/aoe4-berrybush-rdoc.rdc.bz2

There's one berry bush selected, which does render (for some reason). All the units seem to be rendered in Colour Pass 2, and one part of the berry bush which does render is event 408.

I'll look into the final version of the game a bit when I've got it, but maybe this will help. Also, from the debugging I did from the stress test, I don't think the got NULL index buffer view, indexed draw calls will be dropped message is actually related to this issue: https://github.com/ValveSoftware/Proton/issues/5048#issuecomment-922093219

techy2493 commented 2 years ago

Trying to generate some logs for this, but haven't had a lot of luck so far getting logging turned on, am going to keep trying though. In the meantime wanted to indicate that the linked thread is now closed and a new one was created which continues to track this error on the Proton side.

https://github.com/ValveSoftware/Proton/issues/5258

I posted this there, but I'll include it here as well for ease of access. Here's an image of rendering,

image

sulix commented 2 years ago

I've re-run a few of my experiments on the final game, version 5.0.5544.0 (appid 1466860, build id 7595436), and my observations are:

There are two "types" of issues here (which are likely at least related, if not the same issue):

Looking at the game under renderdoc, there are two possible codepaths which can occur, both of which have this issue. I think they probably depend on the game settings or something.

  1. A depth pre-pass renders the objects (typically in Depth-only pass 3 or 4, with shader hash a2675ea7efda0520 or 063ac6fa716bddb6). See this renderdoc capture.
  2. The colour and depth are rendered at the same time (typically Color Pass 3, with shader hash 2a62ba8f721daf38 or fbda694dd47ef82e). (I have another renderdoc capture for this, but have removed it to save disk space for now. Let me know if you want it.)

In both of these cases, both the "wiggled" and totally invisible objects appear to be rendered with vkCmdDrawIndexed(), and their meshes can be viewed in renderdoc. Only some of them actually do appear. (And for whatever reason, the mesh viewer isn't showing any VS Output in renderdoc whether they appear or not — though that feels like it's probably just some Vulkan feature that's beyond my OpenGL 2.0-era knowledge.) One other thing I'm not sure of is how the per-instance buffer seems to have a format of R16_UINT, but accesses everything as though they're 32-bit uints (including having 4-byte aligned offsets, etc).

In any case, hopefully the renderdoc captures can be of some use. I wish I could get some D3D12 API traces as well, but it looks like the d3d12 ApiTrace support doesn't handle OpenExternalHeap(), which would be required…

sulix commented 2 years ago

Okay — it looks like it was the alignment mismatch on the per-instance data which was causing this issue. Fixing it (as in PR #884) makes the units appear for me: The battle of hastings with people and trees in it

HansKristian-Work commented 2 years ago

Should be fixed on master now thanks to @sulix.

Blisto91 commented 2 years ago

Can confirm this issue is fixed