Closed ghost closed 3 years ago
Happens to me too, video resets for a second. I also mentioned this but don't know if they're working on it.
Thanks for the report! I see the same behavior with dragon age. But I still get it when downgrading to v0.5, so something else is responsible for it I guess. Anyway, I just commited a fix, can you guys compile&test with that patch?
Or maybe you guys ran into a long-standing bug, pushed another fix 058d2f0d
Seems to have fixed it, thank you dhewg.
I tried testing this today, and successfully compiled the code (lastest 058d2f0 from git) based on the instructions in https://github.com/iXit/wine-nine-standalone/wiki/Compiling and https://github.com/iXit/wine-nine-standalone/wiki/Debian-and-Ubuntu. I used a Ubuntu 20.04 LXC container to perform the build, since that has all the build dependencies avaliable via apt.
What's interesting what that the build completed successfully with no errors, and I got a successful "enjoy your release" message. However, when I moved the tar back to my Ubuntu 18.04 machine (the one that I actually use wine-nine on), and tried to install it using the nine-install script, the install failed. I got the following error:
err:d3d9nine:nine_set Couldn't load d3d9-nine.dll: L"Bad EXE format for %1.\r\n"
This error does not occur with the binary 0.6 and 0.5 releases on this site, only with my custom build. I tried building the 0.6 release code on my 20.04 setup as well to see if there would be issues, and I got the above error as well. I have seen people getting this error on the Internet with their gallium nine setups, but that is due to missing 32-bit libgl libraries. I have those libraries installed, and the interesting part is that the binary releases work - so my opengl configuration should be fine.
I also tried the build on a Debian 10 VM I had lying around and got the same error as well.
This has led me to think if I need to build on the distro I'm actually running wine-nine on to get the build to work, or if there's some additional hardcoding taking place that is different between the distros (I have the "-Ddistro-independent=true" var set when compiling).
The releases here on github are compiled with an Ubuntu 16.04 machine on Travis, so I suppose I can setup a 16.04 container and try a build to see if it will work. But for now I'm stuck, and things seem strange.
That's somewhat expected and the reason we use an older distro to compile binaries: The binaries are linked to the library versions installed on the build machine, which are newer than those on your 18.04 box.
Just tested v0.7 and the black screen issue is fixed. Thanks!
Nice, thanks for the confirmation
I am using wine-nine with Wine 5.10 Staging, on Ubuntu 18.04 using Mesa/Radeon drivers (20.0.8) with AMD 6620G graphics (Llano APU). I have been a satisfied user of wine-nine starting on v0.5, and today I updated to v0.6. I didn't see any performance issues, however with v0.6 my computer screen turns black for a second or two after I exit a wine-nine application. The screen does not turn black when I use v0.5.
I tested with two games, Halo CE and Dragon Age Origins, and both had the issue (my computer screen turns black for a second or so when I press "exit" or "quit" in the game GUI). Both games are run on 32-bit wineprefix.
Below is the v0.6 log from starting Dragon Age Origins, then closing it by pressing the "quit" button in the game menu after it loaded. Once the game quit, the screen turned black for a moment.
Below is the v0.5 log, ran in the same manner as the v0.6 one. The system configuration was not changed, I directly installed v0.5 from the release on github and reran the game. The screen did not turn black when the game quit.
Basically the logs pretty much look identical except for the last v0.5 line. I tried looking at the NINE_DEBUG settings to get more information, but there's a lot of data I can potentially capture there and I'm not sure where to start. I can also provide traces if necessary.
Thanks!