Darksiders 2 Deathinitive Edition does not work with Nine #317
Comments
|
Could you describe your configuration ? |
|
Gentoo x86_64 |
|
To exclude a configuration issue, have you checked your other dx9 games to see if they work right ? |
|
I tried with Splinter Cell : Conviction and it works without problem with Nine. |
|
@berillions, After that run the game with You can find more details here . BTW, you don't need to bother with the additional BTW, this reminds me, before you recompile with debug support, you could also try |
|
After to disable Nine in winecfg and I compiled Mesa with debug flag and when i launch the game with Nine enabled and |
|
Somehow NINE_DEBUG=all didn't work. Could you try again (try export it maybe before launch) |
|
Even if i export NINE_DEBUG before to launch the bug, i have the same output console log than in my previous message ... :/ |
|
Then it is possible mesa isn't compiled with --enable-debug afterall.
The game may be 32 bits while you compiled 64 bits mesa ?
|
|
The game is 64-bits : And if i check in Mesa log compilation, debug mode is enabled :/ |
|
The debugging page gives the hint to try If logging still does not produce the desired output, then we'd ask you to disable Nine (aka use wined3d) and use apitrace to record a very short game session. You can upload it on the nine ftp or public sharing site. (We may keep it to use it for regression testing.) My favorite method for making apitrace is to take the Run the game as usual, the trace would be in your game directory. If you get error related to |
|
I have no clue why you don't have debug info. In the case of your bug report, a log would be more valuable since the last buggy call wouldn't be captured by the trace, but it's better than nothing. |
That is why I asked for a fully working trace made with wined3d. |
It shouldn't reproduce the issue. Since D3D_ALWAYS_SOFTWARE works, it means the problem is with the format support the game queries. We likely wrongly advertise support for something as depth buffer, and the game tries to create a depth buffer out of it. Thus it is unlikely a wined3d trace would reproduce the issue. |
|
Yeah i confirm that i can't reproduce the issue with apitrace. I create correctly a .trace file and i can replay it when Nine is enabled. |
|
Since we can't get the log, could you give us a working trace (D3D_ALWAYS_SOFTWARE if possible, or wined3d) and a non working trace (nine, but the trace will be cut just before the buggy call). Then we can compare the previous calls to check format compatibility and figure out which calls return a different value. |
|
How i do a trace with Nine ? |
|
Yes, exactly |
d3d9_get_pipe_depth_format_bindings assumes the input format is a depth stencil format. Previously the user could hit this function with an invalid format. Protect the last non protected call with a depth_stencil_format check. Another solution is to have d3d9_get_pipe_depth_format_bindings support non depth stencil format, but we don't want the user to create depth buffers with d3d formats that can't be one, it's better to check if the format can be depth buffer with d3d. Fixes crash of: #317 Signed-off-by: Axel Davy <davyaxel0@gmail.com>
|
I pushed a patch that should prevent the crash, but I don't think the game will be working. |
|
Hi Axel, I compiled Mesa with your patch and unfortunatly, the game still crashes with the same error. I create a .trace without Nine but impossible to do the same thing with Nine. A .trace is create but there are no frame captured by apitrace when i replay it. |
|
I checked the trace but (as expected), I couldn't deduce what is the issue. It would be useful to find a way to force the debug info to be printed. |
d3d9_get_pipe_depth_format_bindings assumes the input format is a depth stencil format. Previously the user could hit this function with an invalid format. Protect the last non protected call with a depth_stencil_format check. Another solution is to have d3d9_get_pipe_depth_format_bindings support non depth stencil format, but we don't want the user to create depth buffers with d3d formats that can't be one, it's better to check if the format can be depth buffer with d3d. Fixes crash of: #317 Signed-off-by: Axel Davy <davyaxel0@gmail.com>
|
Hello Axel, Can you explain how to replace the calls to debug_printf for printf ? or fprintf(stderr, ) in nine_debug.c ? Thanks |
|
Maybe you should give a try with the new build system (meson) ? The additional flag is -D b_ndebug=false Also remember if the game is 32 bits, that's mesa 32 bits that should be rebuilt. |
|
I will try with debug option enabled. Just to say that i have the same problem with D9VK than Nine ... Maybe it's a problem in Wine directly ? |
|
Most likely the game behaves bad when a specific weird combination of abilities is advertised. It's quite possible both nine and D9VK do wrong there. |
|
An idea to search where come from the issue ? |
|
Yes, comparing trace taken on wine or nine would have helped, but I can compare the wine trace with nine log and see what is different. |
|
It will be a trace with plain Wine (= wined3d) and with Nine disabled right ? |
|
Yes, but you already provided one. If you do the same things (game save, config) when you do the log (with Nine) than what you did for the trace, it'll be fine. |
|
Also since D3D_ALWAYS_SOFTWARE=1 works, I'd like to have a log with it as well. csmt_force=0 will prevent issue in the log due to several threads writing at the same time, and vblank_mode=3 forces vsync, thus fewer frames and shorter log. The log can be quite big, it's easier to work with if you try to play fast to reproduce the issues, in order to have shortest log. |
|
Hello Alex, If i launch the game with
after to rebuild mesa with debug flag enabled, i have this log : I have only this log because the game crash at launch, not in-game. |
|
It seems it didn't print debug
Le dim. 5 mai 2019 à 11:52, Maxime Lombard <notifications@github.com> a
écrit :
… Hello Alex,
If i launch the game with
env csmt_force=0 vblank_mode=3 NINE_DEBUG=all D3D_ALWAYS_SOFTWARE=1 wine
Darksiders2.exe &> Nine_D2.txt
after to rebuild mesa with debug flag enabled, i have this log :
https://pastebin.com/Fv9CsVJc
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#317 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AATNXMPDYHUJYYESSIBECMLPT2U37ANCNFSM4FUBGWFA>
.
|
|
Hum... I don't know how to do a "good" debug log... I correctly built Mesa with "-Db_ndebug=false" |
|
Are you sure you built the correct 32 bits version , or that the new binary
is actually the one loaded
Le dim. 5 mai 2019 à 12:07, Maxime Lombard <notifications@github.com> a
écrit :
… Hum... I don't know how to do a "good" debug log... I correctly built Mesa
with "-Db_ndebug=false"
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#317 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AATNXMIHXXXWK7MJEIKAUKLPT2WV5ANCNFSM4FUBGWFA>
.
|
|
Hum, i rebuilt Mesa git + debug flag enabled and packaged/installed it and now i have a good log with print debug for Nine : |
|
Problem is indeed capabilities advertised. In the log: That is we return D3DERR_NOTAVAILABLE It results in the game passing invalid format later one. |
|
Checking that part of the code and the documentation, it seems we are too strict there. But what we advertise here has to work with other functions, thus it needs a proper fix. Until I write the proper fix, adding D3DFMT_A8R8G8B8 in the list of the function display_format (adapter9.c) should work for your game. |
|
I confirm that with this workaround, the game works with Nine :-) |
|
Hello Axel, Just a question about this screenshot, i have a lot a tearing. What do you think about CPU/GPU-load/FPS graph ? Do you know where come from the issue ? https://reho.st/view/self/a767537405379bb43d8355508b1d6d97aa4db69d.jpg |
|
It looks like the game caps fps to 30, maybe you can set it in the options. For the tearing, I guess the app doesn't ask vsync (maybe you can configure it). You can force it with vblank_mode=3 |
|
Hum ... I disabled VSync in game and added vblank_mode=3 before to launch the game without success. I still have a lot of stuttering. You can see on the graph on the both screenshot that i have drop FPS while i have a CPU increase ... I have an AMD Rx580 8Gb + Mesa Git + LLVM 8.0 ... Screenshot : |
|
The cpu load seems to spike when you have stutter. That could indicate a shader recompilation. maybe's GALLIUM_HUD's num-compilations could confirm that ? Gallium nine isn't supposed to have much of them, taking an apitrace with could help make sense of this. |
|
This the .trace i done with apitrace : And this is a screenshot with num-compilations. |
|
Replaying the trace, I see indeed a few isolated recompilations, but It's hard to tell whether it's your issue or not. Do you use repo llvm or did you compile it yourself ? With the debug flags, llvm can be really slow. radeonsi has a shader cache. If you play a scene, quit, and restart and play the scene again, the stutters should be gone because of the shader cache (the cache is reset whenever mesa or llvm is changed). |
|
I used LLVM and Mesa packaged by Debian (Unstable version). For the radeonsi shader cache, i already played more time a same scene. And each time i played, i had stuttering :-/ |
|
Then it would indicate the issue is not in shader recompilation, and in some other dlls... I would recommand trying out native dlls and integrated dlls, sometimes ones perform better than others. |
|
I reinstall Gentoo and with LLVM 9 + Mesa Git + Nine Standalone Git, stuttering are gone :-) |
|
Ok then |
|
Oups, While the performance issue is fixed, the long term fix for the crash is not yet done, so reopening |
|
Axel, Do you fix the issue in Mesa ? |
|
Thanks for reminding me, I forgot. |
|
It's not exactly the same fix, but hopefully it should work the same. |
Hello,
The game does not work with Gallium Nine but works without problem (except the glitch issue) with Wined3d. When i launch the game with Nine, i have an error message say me that the resolution is not supported for fullscreen display.
Screenshot for the error message :
https://reho.st/thumb/self/85c7d34037ec89e764078870eeaa98fe12cd226b.png
And i have this message in the output console :
Maxime
The text was updated successfully, but these errors were encountered: