Open SoftwareSchlosser opened 6 years ago
Maybe Proton could include some XNA to FNA magic? https://github.com/FNA-XNA/FNA
This is blocked by C++/CLI incompatibility, so XnaToFna is one possible route, though this game has multiple C++/CLI dependencies aside from XNA, so it would require something like Maik's specialized variant of the tool:
4.2-3 slightly improves the situation, but not by a lot - Maik's tools will still be really important for this game.
4.2-3 actually tremendously improves the situation short-term, for several players, using protontricks
(protontricks 312530 dotnet40
and protontricks 312530 dinput
) is enough to get the game running flawlessly.
For me I had to jump through a few hurdles, specifically I had to purge Proton's .NET framework stub implementations first, as well as manually installing libFAudio for wine 4.2's XAudio implementation. After that, it works as smooth as butter :+1:
And that I am extremely grateful for, for Duck Game I have never before been able to simply click the Play button, and have everything Just Work™ with no glitches or anything.
As of Proton 4.11-2 ~the only hack that is required now is winetricks dinput
~, then the game will launch successfully with the -nothreading
flag enabled.
For some reason the game's managed DirectInput layer fails to load entirely without the DXSDK dinput.dll, which leads me to believe that the builtin DLL isn't exporting something that the game expects.
A really scary line from WINEDEBUG=+all
:
2594502.987:0025:0026:trace:module:load_so_dll loading L"\\??\\Z:\\home\\flibitijibibo\\Games\\SteamLibrary\\steamapps\\common\\Duck Game\\DInput.dll" from so lib "/home/flibitijibibo/.local/share/Steam/SteamApps/common/Proton 4.11/dist/bin/../lib/wine/dinput.dll.so"
So the (very very terribly named) DInput.dll from the game appears to be conflicting with the builtin dinput.dll, causing some really weird load failures to happen, ending with the FileNotFoundException for DInput's assembly.
An even quicker fix than winetricks
is just setting dinput to be native-only in winecfg, which is harmless since the game references dinput8 (as does SDL2, if I remember correctly). I dunno if this is necessarily something that can be fixed easily... we may have to shove in some kind of special rule like we do for large-address-aware games. @madewokherd, @aeikum, any insight here? It doesn't seem like a wine-mono thing since this is "mostly" a native DLL, but I feel like Wine would have run into a bug like this ages ago, native or not...
EDIT: Launch option, for reference:
WINEDLLOVERRIDES="dinput=n" %command% -nothreading
now works without any issue if using protontricks 312530 dotnet40 dinput
I see only that with joypad after a while the window become minimized and trying to understand if it is kde or an hotkey.
The protontricks
method is not working for me on NixOS. Here are my outputs from protontricks 312530 dotnet40
and launching Duck Game from Steam.
My problems might be better discussed with the protontricks
nixpkgs maintainer, but in case I'm missing something obvious I figured I'd comment here.
The
protontricks
method is not working for me on NixOS. Here are my outputs fromprotontricks 312530 dotnet40
and launching Duck Game from Steam.My problems might be better discussed with the
protontricks
nixpkgs maintainer, but in case I'm missing something obvious I figured I'd comment here.
What version of proton were you trying? I noticed it says Wine version 4.0.2 in your log. You should retry with the latest proton version. I had no problems getting into the game with Proton 4.11-8 after running the protontricks line listed above. Granted it should be plug and play, but then we'd have Valve going from game to game.
Honestly Valve should be outsourcing (and open sourcing) the maintenance of games to trusted maintainers and allow the integration of protontricks/winetricks into their tool set.
Imagine if you could create lutris style install scripts and send pull requests to maintainers.
now works without any issue if using
protontricks 312530 dotnet40 dinput
I see only that with joypad after a while the window become minimized and trying to understand if it is kde or an hotkey.
I can confirm that was a KDe settings that was creating issues. Works flawlessy on Linux with 4 controllers :-)
@betam4x I've revisited this with Proton 5.0-4. I launched the game to get the crash and create the prefix, then ran protontricks
. The logs look about the same. Again, it crashed on launch, but then I restarted Steam and tried again. This time, it said "Performing first time setup". After a significant amount of time, the game finally launched, but unfortunately, the duck was stuck moving left on the menu screen. I could only get it to stop by holding down right (d
). Closing and relaunching the game gave me the same issue. But it did launch!
I then restarted Steam again, and now the game window opens briefly to a black screen before instantly crashing. Here are those logs. Maybe someone can diff them with logs when the game is working?
Edit: Also, I tried the above launch options (WINEDLLOVERRIDES="dinput=n" %command% -nothreading
) but they didn't help. I think the crash has to do with the line in the logs mentioning "fork without exec", but I don't know how to fix that.
Update: Something was wrong with my Steam installation. Various other games, both Proton and native, were crashing on launch with errors like the one below and failures to create Direct3D devices. After deleting $XDG_DATA_HOME/Steam
and reinstalling Steam and games, they all work fine. Really wondering what might have caused this, as I have the same issue on another machine and I don't want to reinstall everything there as well.
The game started working for me for a while on the standard build branch with WINEDLLOVERRIDES="dinput=n" %command% -nothreading
, but after the latest big update it no longer works. It crashes immediately with no Proton log from PROTON_LOG=1
, but after protontricks 312530 dotnet40 dinput
, Duck Game crashes and gives this error in a crash dialog:
Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException: Invalid window
at Microsoft.Xna.Framework.SDL2_FNAPlatform.CreateWindow () [0x000a9] in <2a509bd9153f43e2a56073000f1bcdc4>:0
at Microsoft.Xna.Framework.Game..ctor () [0x000cd] in <2a509bd9153f43e2a56073000f1bcdc4>:0
at DuckGame.MonoMain..ctor () [0x0003b] in <6f5c838d2ab84f6bae28e11de2f7f6f3>:0
at DuckGame.Main..ctor () [0x0002c] in <6f5c838d2ab84f6bae28e11de2f7f6f3>:0
at DuckGame.Program.DoMain (System.String[] args) [0x00394] in <6f5c838d2ab84f6bae28e11de2f7f6f3>:0
at DuckGame.Program.Main (System.String[] args) [0x0007d] in <6f5c838d2ab84f6bae28e11de2f7f6f3>:0
Date: 11/13/2020
Version: 1.1.7621.30336
Platform: Windows 10 (Steam Build 5827912)
Online: 0
Mods:
Time Played: 00:00:01 (0)
Special Code:
FIELD FAILED
Level: null
Command Line: -nothreading
The Proton log is huge and I don't know which errors can be ignored but here's some context from that error:
5467.467:0100:0104:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\OPENGL32.DLL" at 0x7a840000: builtin
5467.479:0100:0104:err:wgl:X11DRV_WineGL_InitOpenglInfo couldn't initialize OpenGL, expect problems
5467.480:0100:0104:fixme:win:RegisterTouchWindow (0x10068 00000003): stub
5467.498:0100:0104:trace:mscoree:mono_assembly_preload_hook_fn "System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
5467.500:0100:0104:trace:loaddll:load_native_dll Loaded L"Z:\\home\\lh\\.local\\share\\Steam\\steamapps\\common\\Proton 5.0\\dist\\share\\wine\\mono\\wine-mono-4.9.4\\lib\\mono\\gac\\System.Configuration\\4.0.0.0__b03f5f7f11d50a3a\\System.Configuration.dll" at 0xe070000: native
5467.500:0100:0104:trace:mscoree:_CorDllMain (0E070000, 1, 00000000)
5467.563:0100:0104:trace:loaddll:load_native_dll Loaded L"Z:\\home\\lh\\.local\\share\\Steam\\steamapps\\common\\Proton 5.0\\dist\\share\\wine\\mono\\wine-mono-4.9.4\\lib\\mono\\gac\\System.Drawing\\4.0.0.0__b03f5f7f11d50a3a\\gdiplus.dll" at 0x6f680000: PE builtin
[00000104:] EXCEPTION handling: Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException: Invalid window
couldn't initialize OpenGL, expect problems
seems pretty bad. I'm on NixOS which is a bit quirky but someone on Steam had the same issue on Arch. Others in a Duck Game Discord running Ubuntu seem to be doing fine.
As of Proton 5.13-6, the game works mostly fine with default Proton and commandline
WINEDLLOVERRIDES="dinput=n" %command% -nothreading
The one thing that's still broken is the text in the "Custom Duck" screen in character select is garbled. That's fixed by
protontricks 312530 dotnet461
Maybe some other dotnet works, but I'm not sure. I tried just dotnet40 on a wine that supports it (5.12 through 5.18 say they're broken), but the game just crashes at launch (with proton-tkg 6.0 winetricks), or nothing happens (with proton-5.0-10 winetricks).
Can confirm all of the above. The issues I was having last year were due to some kind of bad state my Steam installation settings intermittently enter that breaks most games games and forces me to reinstall Steam. The latest update for the game has been working consistently on 5.10 with the given launch options, and protontricks 312530 dotnet461
(note: it took 40 minutes on my machine and you need to agree to some EULA's) did fix the garbled text at the character select terminal.
The recent Duck Game update added eight-player local multiplayer which can be accessed by connecting a fifth controller and pressing Start (source).
This does not work for me on Linux. Proton 5.13 got hotplugging working which is a huge improvement for local multiplayer games, but unfortunately more than four player games don't seem to work.
@kisak-valve do you know why this might be? It's an issue across multiple games
@lhindir What specific model(s) of controllers are you trying to use? Do you have any of Steam's various controller configuration support options enabled?
@aeikum Four Steam Controllers via one receiver and an original Xbox One controller, via the newer Microsoft slim receiver and xow. I'm on Gnome Wayland.
I have none of the configuration support options checked.
I was thinking maybe Xinput only got support for more than four controllers recently on Windows and Wine can’t handle that many yet, but I don’t really know.
Oh, I see you work on Wine. I have more Steam Controllers, another Xbox controller, two PS4 controllers, and time to try any configuration! :)
The game uses dinput for controller enumeration and to handle all the extra xinput devices. It was crashing in one of the functions that was doing the xinput/dinput setup which left the dinput side broken.
The crash was caused by Mono's lack of support for Platform Invoke with variable args. Luckily @madewokherd was working on this bug already and the fix is being upstreamed.
I've build wine-mono with the patch and everything seems to be working with 5 xinput controllers :-)
@ivyl That's great to hear. I'll admit I haven't tried since 5.0 but I also had issues with other eight-player games like Brawlhalla and Knight Squad (native, uses dinput I think). Do you know how I might debug these? Brawlhalla is free if you want to try it.
Another >4-player input-related bug: duplicated inputs on Floppy Heroes, ClusterPuck 99, Genital Jousting, and Party Golf. If you have suggestions for troubleshooting this I'd love to try them.
I've checked the thing you've mentioned with Proton Experimental and...
duplicated inputs on Floppy Heroes
Seems like the game behaves as expected. I gave it a shot and it supports only 4 controllers + 2 keyboard inputs. You can map the extra controllers to the keyboard inputs, but not the analogs.
ClusterPuck 99
Works just fine.
Genital Jousting
Seems to be working just fine with many controllers. The only problem was Xbox One / Series controller detection. This should be fixed in the next experimental, so keep an eye on that.
Party Golf
Supports only up to 4 players/controller, unless you enable "wacky shared controller mode". Seems to be working as expected.
If you have any particular problems with those games please describe them (expected behavior, behavior you get insted, Proton version, list of controllers you have used) in the game's dedicated issues and feel free to @ me.
I should've checked; it does look like the duplicated inputs issue on those games is working on 5.13. Sorry for the noise!
I've gone through some of my local multiplayer games and compiled controller issues in #4713.
Has there been any investigation into fixing the corruption on some graphics? The dotnet461
workaround doesn't seem to work on 6.3 and it would be nice to have everything just work without it.
Hangs on boot with too many mods enabled, while on Windows is perfectly fine. steam-312530.log
Hello @CoatlessEskimo, some possibly interesting lines from your log:
[00000118:] EXCEPTION handling: System.IO.FileNotFoundException: Could not find file "Z:\home\ali\.local\share\Steam\steamapps\common\Duck Game\Content\rock.xnb"
[00000118:] EXCEPTION handling: Microsoft.Xna.Framework.Content.ContentLoadException: The content file was not found.
[00000118:] EXCEPTION handling: Microsoft.Xna.Framework.Content.ContentLoadException: Could not load asset rock! Error: The content file was not found.
This could be read as a specific mod being poorly formed instead of generalizing to total number of mods. It might be interesting to identify a mod that wants to use that and see if the mod works in isolation while still giving that error message.
I think it's worth mentioning that the text for these menus is not rendered correctly, however it is still somewhat legible. What's weird is that the game is rendered in OpenGL.
Looks like half-pixel offsets to me. I don't know if/how d9vk accounts for d3d9's nasty pixel centering but for XNA games the "fix" is to try and remove them from the application:
https://github.com/FNA-XNA/FNA/wiki/2:-Building-with-FNA#2a-about-effect-support
Emulating this feature tends to be really volatile, so this is literally the only non-patented feature FNA intentionally avoids because it's extremely easy to fix in native builds and ensures the output doesn't end up like... well, this.
It's not just text that has this issue. Hats have it as well since some hats have parts that don't quite line up correctly on the duck model. (An obvious one is the wizard hat.) You can also see it on the A/B buttons in that screenshot.
It's not just text that has this issue. Hats have it as well since some hats have parts that don't quite line up correctly on the duck model. (An obvious one is the wizard hat.) You can also see it on the A/B buttons in that screenshot.
oh holy crap you're right
If they render all of this with SpriteBatch it (ironically) lines up, the built-in sprite drawing includes half-pixel compensation in the matrix transform. Not to derail the Proton side of things but with the Deck now out it may be worth checking with Landon about this in the context of native graphics backends (though I think they want to move on from DG at this point, sorry Landon if you see this)
Well, I'd much rather have FNA working, but if we can't fix it, maybe XNA would work. That can be enabled with WINE_MONO_OVERRIDES=Microsoft.Xna.Framework.*,Gac=y %command%
launch options.
Well, I'd much rather have FNA working, but if we can't fix it, maybe XNA would work. That can be enabled with
WINE_MONO_OVERRIDES=Microsoft.Xna.Framework.*,Gac=y %command%
launch options.
That worked!
I even double checked the 8-player support and it worked too!
oh wait, doing that causes a crash when entering the Arcade.
Can confirm this crashes the arcade, but fixes the text. steam-312530.log
Appears to be a Mono bug.
* Assertion at /vagrant/mono/mono/metadata/cominterop.c:3387, condition 'ccw->ref_count > 0' not met
As of today, Duck Game has been updated to function and render properly within FNA.
That's not going to break things when the bug is fixed in Proton, is it?
That's not going to break things when the bug is fixed in Proton, is it?
I doubt it, considering @flibitijibibo said that FNA intentionally avoids emulating half-pixel offsets in their OpenGL renderer, due to its volatility.
The plan now is to switch to D3D11 once Wine's d3dcompiler can support it.
All renderers will exhibit the same behavior, so nothing to worry about here - you'd have a better chance of a native version before anyone writes, validates, and ships a D3D9 renderer just for FNA3D.
After a prolonged session (not that long, about 20 minutes), the game starts hitching every ~8 seconds. The more you play, the more noticeable the hitches get. Searched on ProtonDB, I'm not the only one: https://www.protondb.com/app/312530#tIh7Wh-Ca7. EDIT: It seems it has been fixed?
Running the game doesn't do anything.
system information
steam-312530.log