[Feature] Allow running games without Wine #4608
Conversation
arielj
requested review from
Etaash-mathamsetty,
a team,
flavioislima,
CommandMC,
biliesilva,
Nocccer and
imLinguin
and removed request for
a team
arielj
removed request for
Etaash-mathamsetty,
flavioislima,
CommandMC,
biliesilva,
Nocccer and
imLinguin
arielj
added
pr:wip
|
@arielj FYI this doesn't seem to work on Linux Latest Commit
After run (I removed the prefix beforehand):
Heroic Launch Logs:Launching "Betrayal at Krondor" (gog) System Info: The current system is not a Steam Deck Software Versions: Game Settings: { Game launched at: Sun Jul 20 2025 00:38:53 GMT-0400 (Eastern Daylight Time) Winetricks packages: Launch Command: HEROIC_APP_NAME=1207660953 HEROIC_APP_RUNNER=gog GAMEID=umu-0 HEROIC_APP_SOURCE=gog STORE=gog STEAM_COMPAT_INSTALL_PATH="/mnt/hdd/Program Files (x86)/GalaxyClient/Games/Betrayal at Krondor" PULSE_LATENCY_MSEC=60 LD_PRELOAD= STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/john/.steam/steam WINEPREFIX="/home/john/Games/Heroic/Prefixes/default/Betrayal at Krondor" STEAM_COMPAT_DATA_PATH="/home/john/Games/Heroic/Prefixes/default/Betrayal at Krondor" PROTONPATH=/home/john/.local/share/Steam/compatibilitytools.d/GE-Proton9-27 WINE_FULLSCREEN_FSR=0 PROTON_ENABLE_NVAPI=1 DXVK_NVAPI_ALLOW_OTHER_DRIVERS=1 PROTON_EAC_RUNTIME=/home/john/.config/heroic/tools/runtimes/eac_runtime PROTON_BATTLEYE_RUNTIME=/home/john/.config/heroic/tools/runtimes/battleye_runtime STEAM_COMPAT_APP_ID=0 SteamAppId=0 SteamGameId="heroic-Betrayal at Krondor" PROTON_LOG_DIR=/home/john WINEDEBUG=+fixme DXVK_LOG_LEVEL=info VKD3D_DEBUG=fixme /tmp/.mount_Heroic4svgNl/resources/app.asar.unpacked/build/bin/x64/linux/gogdl launch "/mnt/hdd/Program Files (x86)/GalaxyClient/Games/Betrayal at Krondor" 1207660953 --no-wine --platform windows --set mididevice=fluidsynth ../KRONDOR.exe Game Log: The 'cycles' setting is deprecated but still accepted; please use the 2025-07-20 00:39:06.163 | CONFIG: Deprecated option 'voodoo_multithreading' Renamed to 'voodoo_threads' 2025-07-20 00:39:06.164 | CONFIG: Loaded primary config file '/home/john/.config/dosbox/dosbox-staging.conf' Moved to [mouse] section and renamed to 'mouse_sensitivity'. 2025-07-20 00:39:06.179 | CONFIG: Invalid 'active' setting: 'higher,normal', using 'auto' Moved to [capture] section and renamed to 'capture_dir'. 2025-07-20 00:39:06.179 | CONFIG: Deprecated option 'frameskip' Consider capping frame rates using the 'host_rate' setting. 2025-07-20 00:39:06.179 | CONFIG: Deprecated option 'scaler' Software scalers are deprecated in favour of hardware-accelerated options:
2025-07-20 00:39:06.179 | CONFIG: Setting 'cputype = 386_slow' is deprecated, falling back to the alternate: 'cputype = 386' The 'cycles' setting is deprecated but still accepted; please use the 2025-07-20 00:39:06.179 | CONFIG: Invalid 'prebuffer' setting: '120'. Value outside of the valid range 0-100, using '100' Only 'nuked' OPL emulation is supported now. 2025-07-20 00:39:06.179 | CONFIG: Deprecated option 'oplrate' The OPL output is now transparently resampled to the mixer's sample rate. 2025-07-20 00:39:06.179 | CONFIG: Invalid option 'gusrate' Use 'lpt_dac = disney' to enable the Disney Sound Source. 2025-07-20 00:39:06.179 | CONFIG: Loaded custom config file '../dosboxBAK.conf' |
|
@Schweppesale is this a game that should already use Dosbox? because I don't see anything in the game settings to tell heroic you want to use dosbox I understand this feature is not what would be used in your case now that I understand what you are trying to do, we use gogdl to run gog games and it already has code to handle dosbox explicitly https://github.com/Heroic-Games-Launcher/heroic-gogdl/blob/f25db86e30e35338b2a9a53d181b00849913dc11/gogdl/launch.py#L106 and heroic should already use native dosbox if available according to this #3797, my understanding is that proton should already be ignored by default when using the system's dosbox I think what you have is maybe a bug in gogdl or heroic, but not related to this feature check https://github.com/Heroic-Games-Launcher/HeroicGamesLauncher/wiki/How-To:-DOSBOX-and-SCUMMVM cc @imLinguin for visibility |
|
@arielj yea it's a really old RPG from back in the 90s.
That's right and Heroic will correctly determine that this game requires dosbox to run prior to calling the native dosbox-staging installation. The problem however is that it will still create a wine prefix despite never having a reason to use it which is something I'd hoped this feature you're working on right now would address. This is also the reason why I had created that feature request the other week: Another problem with the current implementation is that the user may want to swap out the dosbox instance with something like scummvm or a linux build of some game engine source port (gzdoom, openmw, etc) If the user decides to provide the heroic entry with an alternative executable then it will always attempt to run it within the wine prefix. So the behavior here seems somewhat inconsistent. It will create a wine prefix that is never used by default unless you provide it with an alternative executable in which case it will always use the prefix. You can get around this limitation by creating a separate side-loaded app that shares the same game files but since you lose the ability to store saves on the cloud this is not exactly an ideal solution. Another problem with Heroic's dosbox integration is that it doesn't appear to set the correct working directory prior to calling most games and/or configuration files (which often launch the game via autoexec). The workaround is simple enough but it won't be obvious to new users. Basically, you need to append the relative path to executable via build arguments:
I believe it's using the DOSBOX folder as the working directory but obviously that's is a separate issue. Same game - no launch arguments: Note: Most DOS games simply won't launch but the solution is almost always more or less the same. |
|
what you describe seems to be bugs with the dosbox handling, but from the description of the feature request I didn't understand this was the problem I'd suggest creating bug reports for these issues instead, since heroic handling the dosbox integration is unrelated to the feature of this PR, it is already implemented (but with bugs from what I see) EDIT: I was talking with another dev and it seems like wine or proton and a prefix are needed to properly setup the game, even if then it's launched using the native dosbox, so I understand what you explain is not actually a bug but a necessary step of the game setup process |
@arielj I thought the prefix is created when the user presses play for the first time. Is that not actually the case?
Yea, as mentioned earlier I'm going to create a separate bug report for the dosbox/working directory issue.
^ We should disregard this comment I made earlier. Just ran another quick test and it looks like the changes you made do in fact allow us to run native executables that exist outside of the prefix even if it is being unnecessarily recreated. So this is looking good for the most part. |
|
Deleted my last comment since I may have posted the wrong logs and I'm not sure if this is some type of regression: So here we have some logs where I'm including a call to the "does-not-exist" wrapper command. The game in this case still launched despite including a command which doesn't exist:
Note: The additional launch arguments as well. This is probably not a big deal for dosbox (dbox) since it will simply log any missing configuration files and attempt to launch the game without them but I figured it was probably worth pointing out. I'm not sure for example what would happen if we pass these parameters into openmw or gzdoom. |
yes, prefixes are created when launching a game if the prefix does not exist my understanding is that for games that run through dosbox, the prefix is still needed to run setup steps every time the prefix is created, that's why the prefix is created, games may need it again, this PR is not meant to fix anything related to games that run through dosbox, that's out of the scope of what I implemented here |
|
Fair enough. |
There are cases where old games won't run through wine on linux/mac but community patches exist to make them work.
In many cases, the patch not only makes the game work but also provide executables to make the game run the windows version natively (without wine).
Some cases are:
Star Wars Jedi Knight - Jedi Academythat doesn't work with Wine but can be executed when using the OpenJK patches, and it provides patches for windows, mac, and linux, so the game can be executed with a linux binary for example to avoid the need of a prefix (saves are stored in the game's install directory so cloud saves should still work).This PR adds the option to disable wine for these games (with the new
Do not use wineoption in the Wine tab) to be combined with the native executable set as alternative exe in the Advanced tab.How to test this:
Star Wars Jedi Knight - Jedi Academy(I think it was free on GOG at some point?)openjkexecutable that was just copied as alternative exe in the Advanced tabDo not use winein the Wine tabCheck the logs and it should be executed with the
--no-wineflag and you'll see it's not using wine nor umu nor any of those.IMPORTANT FOR MAC: looks like python can't run
.appfiles so it fails to run those files on MacOS. I guess there might be a way to handle that, but I can't find a simple way so I added a warning in the frontend and in the logs to let the user know that they should pick the .app's content's script file instead of the .app, could be improved in the futureThis PR closes #2472
Use the following Checklist if you have changed something on the Backend or Frontend: