search

iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
277 stars 23 forks source link

Dragon #159

Open dungeon007 opened 1 year ago

dungeon007 commented 1 year ago

d3d8 wrapper involved, The I of the Dragon game (GoG version actually ships with both their own d3d8/ddraw D3D9 wrappers) Issue and trace is about missrender of flying rug.

NINE and DXVK looks like this: nine

WIND3D is trying to do something about, but result isnt quite correct:: wined3d

DGV2 (which maps such things to DX11/12) works correctly, same as Windows D3D9 driver which emit this correctly too (and that is what makes me think this should work here too) dgv2

Trace here: https://drive.google.com/file/d/15XC5HU4j78RI0A2FNAZ7v4F2oeFMrJLH/view?usp=sharing

axeldavy commented 1 year ago

Thanks for the report.

I assume a trace recorded with windows or DGV2 will play right on the others.

I see a call to ProcessVertices with a ff shader. This is not supported by nine currently. I know wined3d has some limited support to cover needed use-cases, I guess they need some more support. DGV2 must be more advanced there.

The feature consists in running a vertex shader in software mode and retrieve the output. I implemented the feature for vs 3, as it was needed for the Sims2.

It's nice to have a real use case with a trace for other needs than vs 3, but it's low priority. Will take a look one day, but not soon.

dungeon007 commented 1 year ago

"DGV2 must be more advanced there..." I doubt ,it is anything advanced about it... as a wrapper you just map one to another there and that is it. And that worked even since second release of his d3d8 back in 2016 i think... so near immediately worked. Probably he just mapped d3d8 level process vertices to d3d11 variant of that and that just worked as is, for free correct cos dx11 api/drivers are probably more correct there and easier to map. Meanwhile mapping to d3d9 level, likely something more is needed there or missing on a driver level. Thus everybody is buggy on that, more or less on linux. NVIDIA blobs included. Even WINED3D takes it wrong... Look what d3d8to9 is doing there, nothing special, and Windows d3d9 driver just replay it correct. "Will take a look one day, but not soon." No worries nor hurries, i already saw TODOs there, so just to be documented... and guessed maybe somebody actually want to try TO DO something about that, so tried to be useful with some material on the road for that. And since i heard of lack of tests for this... so at least here an app is a test.