The Least-Bad Way To Play Baldur’s Gate/Icewind Dale on GNU/Linux

Published: 2022/09/07

Last updated: 2022/09/07

Lately, after idly searching out the differences, if any, between Icewind Dale and its so-called “Enhanced Edition”, I read enough to reignite my desire to give it and Baldur’s Gate a serious, honest try, and quickly realised that the available options on a modern GNU/Linux system were all seemingly flawed in various fashions. As such, I set out to find ways to make it suck less, resigning myself to vanilla Wine in the interim.

Problems With Vanilla Wine and Proton

Wine actually works well enough once you get things set up, though I had to rely on some workaround with the “gdiplus” library, and had to change to OpenGL graphics for Icewind Dale in order to make the cursor usable.

My biggest gripe was how Wine completely lacked any sort of scaling, relying on setting the monitor’s resolution to what the game wanted. This isn’t necessarily a bad thing, but it comes with side-effects:

• Primarily, it’s impossible to multitask. If I got an e-mail or someone trying to otherwise get my attention, I couldn’t respond to it without quitting the game, resetting the resolution. This also makes it very annoying to try and view reference material, such as the manual.
• Secondarily, there’s various bugs somewhere between my display drivers, X11, and maybe even the window manager:
  • After playing, the centre area between the two monitors can get quirky, and I found that I can’t properly drag windows on my secondary monitor without them wanting to “stick” there.
  • Sometimes the above issue could be corrected by playing around with the driver settings, but it was easier to just kill the whole X11 session and start over.

The whole time, I kept finding myself wishing that Wine could just do some sort of software scaling. The obvious option of using the “virtual desktops” didn’t cut it — while it prevented the monitor resolution issues, “fullscreen” doesn’t work like you’d think it would, instead just jamming the still-tiny window in the upper-left corner.

I eventually had the thought that perhaps Steam’s Proton stuff could help me out, but I found that Proton is, while a true miracle of engineering, quite difficult to control at a lower level, especially for titles that are not actually part of my Steam collection. I found that it was unable to run either title, crashing with odd errors upon running the main executable.

Considering my options, I first looked again at the “Enhanced Editions” to decide if the drawbacks were worth the immediate gain in literal playability.

Why Not The Enhanced Editions?

The answer depends somewhat upon the game. In the case of Baldur’s Gate specifically, it is infamous for adding disgusting Mary Sue NPCs and altering the backstories of existing NPCs alike in the name of “social justice”. That is reason enough. Thankfully, Icewind Dale appears to be lacking those dubious “enhancements”. One would think it would be possible to just deal with the issues in the former by ignoring them as best one can, but both games share one other very big flaw: they are forced into the engine of Baldur’s Gate 2, a move which carries many implications about game balance. For example, to borrow a few salient points from Lilura1’s excellent article on the topic:

• None of the encounters are designed around the new potential abilities and attributes. For example, it’s entirely possible to start Icewind Dale: EE with a character who has 19 Strength due to the imported Half-Orc race and then bump that to 23 with the Barbarian kit’s “rage” ability, which confers a massive boost to damage relative to the original game, where getting even 18/00 Strength had a 1% chance of happening per roll while creating a character, and getting to 19 took a lot of setup with magic or strictly-rationed items.
• Weapon proficiencies are altered, as which weapon falls under which category differs between the original games quite drastically at times. For instance, Baldur’s Gate treats morning stars and flails as “spiked weapon” and maces and clubs as “blunt weapons”, while Icewind Dale puts morning stars and maces under “maces”, and clubs and flails under their own categories. One that especially caught me off-guard is that Baldur’s Gate has daggers under “short swords” while Icewind Dale and the EE games have them under “daggers”.
• Two-weapon fighting functions (or doesn’t) in a drastically different way between the three, affecting both how it’s used and how the Ranger stacks up against a Fighter or its dual- or multi-class combinations:
  • In Baldur’s Gate, there is no way to dual-wield at all.
  • In Icewind Dale, a Ranger has a “fake” dual-wielding technique, if a weapon is wielded without a shield, that grants an extra attack each round.
  • In the EE games, anyone can dual-wield, and there’s a special “weapon style” proficiency that reduces penalties and adds bonuses. Rangers at least start with two ranks in it and can get up to three, but any Warrior class can do likewise even without the free ranks.
    • These proficiencies in general can alter the balance a fair bit, both by attracting investments early on that might’ve otherwise been spent elsewhere and by the bonuses. One that got my attention in particular is the fact that by taking “sword and shield”, it’s entirely possible for classes that normally only get bucklers to nullify one of its major downsides of being unable to block missile attacks, and likewise to essentially upgrade small shields to being like cheaper medium shields for the same reason.
• Unique to Icewind Dale, party management is very different between it and its remake. In the original, it is trivial to recreate the party at any point, adding and deleting characters at will, allowing for some degree of experimentation and recovery. In the remake, this is much more convoluted and requires abuse of the multiplayer mode.

Additionally, the various “EE” games come with their own new bugs and quirks, as might be expected. On the whole, I don’t want any of that; I want to play the games more or less as intended by the original development team. I must admit, however, that the new user interface is wonderful, Lilura1’s scaling gripes aside; it’s nice to look at, very detailed, and easy to read. Shame about the rest of the remake.

Why Not GemRB?

The next place I looked was GemRB, a Free Software reimplementation of the Infinity Engines’ various incarnations. Unfortunately, while I very much appreciate the idea, and they’ve doubtless come a very long way, the project, even on games they list as “polished”, still has a lot of rough edges.

The most recent version of GemRB as I write this is 0.9.1. However, I ended up using 0.9.0 instead because 0.9.1 seemed to have broken the fullscreen mode.

While the fullscreen mode used was in some ways a definite improvement upon Wine’s resolution changing, it felt “squished” to me and I was never quite happy with it. In addition, I saw a lot of quirky behaviour in both games, including bouts of very odd pathing issues (e.g. getting stuck on corners) and what I can only call “spastic” enemy behaviour, such as when my Icewind Dale party was beset by skeletons who, going by the status window, were making attack rolls by the dozens each second with no obvious effect. I also recall several instances where I tried to talk to people in Baldur’s Gate and en route to them suddenly found that the chat icon was grey and my clicks weren’t doing much of use without right-clicking to cancel the chat mode first. Looking at their Github issues page shows a lot of other behavioural problems that have yet to be fixed as well.

At this point, I was resigned to dealing with Wine, until I had the idea of searching around one more time for ways to possibly avoid the resolution changes. This time, I stumbled upon the description for the GloriousEggroll build for outside of Proton. Proton, as previously noted, doesn’t seem to be affected by resolution changes, so I decided to see if that just might hold true with this branch too and set out to get it working with Lutris as it described. Truthfully, I’m still not certain what exactly causes this to work, but the fact that it does is good enough for now.

Final Solution: Lutris

I was initially a bit sceptical about Lutris, admittedly. I had looked over it on a few prior occasions, but I couldn’t see what really differentiated it from PlayOnLinux in concept other than being an everything-launcher, which wasn’t something I really wanted. I had also run into issues any time I attempted to install games from GOG using their scripts, while the ones from PlayOnLinux usually worked without a hitch (at least, until the last year or so, as very old versions of Wine seem to no longer run on my system).

I think Lutris could do with a bit more advertising of its most interesting feature: when everything is working correctly, it, just like Steam, has the ability to upscale windows in software, which is precisely what I wanted the entire time. The fact that it bundles DXVK and vgvoodoo2 helps drastically in improving performance, too. And indeed, once I got it working correctly, I had pretty much the perfect experience — the upscaling was better than GemRB and naturally had none of the associated quirks, it didn’t break my multi-monitor setup, and Icewind Dale even started working with EAX, something that my system Wine never handled. This is due to the versions of Wine used (staging and/or GE) as opposed to Lutris itself, of course, but still a welcome bonus.

The Actual Setup

I’d be remiss if I didn’t document how I actually did this, given all the effort I put into it. I’ll break it down per-game after covering the pre-requisites:

1. Install Lutris.
2. Run Lutris in order to generate its local directory structure. Go ahead and set up your sources at this point as well.
3. Install the GloriousEggroll version of Wine by following the instructions, taking care to grab the pre-compiled version. Restart Lutris afterwards.
4. Ensure that you have the installers on hand, for reasons I’ll detail momentarily. I ended up using the Linux installer for Baldur’s Gate as opposed to the vanilla Windows one, which saved me a little work; if you have the Windows installer instead, you’ll have to adjust the instructions a bit by following the relevant procedure in the section on Icewind Dale below.

One thing I should note immediately, for more advanced users: Linux GOG installers all use the /tmp directory and expect to be able to run executables from it, and therefore a standard tmpfs setup, which prevents that, will cause issues. It is possible to temporarily remount it with appropriate options before and afterwards as follows:

Before:

# mount -t tmpfs -o remount,exec /tmp

After:

# mount -t tmpfs -o remount,defaults,noexec,nosuid /tmp

Also, don’t forget to uncheck the options to place shortcuts and such when installing the games.

Baldur’s Gate

Trying to install from inside of Lutris was terrible; it ended up filling my entire drive. I think that this is because the GOG installer for Linux contains a pre-made Wine prefix, which includes symlinks, and that the Lutris scripts resolved those symlinks and attempted to recursively copy everything it could reach.

The best way to do this is to just run the GOG installer manually using your system install of Wine, set up Lutris to use it, and then configure it. To do so:

1. Install the game, then make note of its location.
2. Find the game in the GOG sources and select it, then, in the lower-left corner, click the arrow next to “Install” and select “Locate installed game” to open the game’s properties dialogue.
3. Make note of the default directory, and then move the previously-installed “Baldur’s Gate” directory there, renaming it to match.
4. Proceed along each tab as follows:
   • On the “Game info” tab:
     1. Select “Wine” as the runner.
   • On the “Game options” tab:
     1. Set the executable to “BGMain.exe”; it’s deep under the “prefix” directory.
     2. Set the wine prefix to the “prefix” directory noted earlier.
     3. If only for reference, set the “Prefix architecture” to 32-bit.
   • Under the “Runner options” tab:
     1. Set the Wine version to either the default or the GE version acquired previously. In this case, performance seemed about identical.
     2. Ensure that “Enable vgvoodoo2” is checked, as well as DXVK. VKD3D isn’t applicable here, so you may as well turn it off.
     3. Disable “Esync”, “Fsync”, “SuperFX”, and the anti-cheats for the same resaon.
   • The “system” tab can likely be ignored; mess with it if you need to.
5. Click “Save”, and then click the new “Wine” button next to “Play” and select “Wine configuration”. If you’re prompted about installing Mono, just hit cancel. When winecfg pops up, select the “Graphics” tab and ensure “Allow the window manager to control the windows” is checked, then click “OK”.

If all went well, the game should now be playable.

Icewind Dale

In this case, installing from Lutris appears possible and fairly painless, but it is in fact a subtle trap — it installs it in a 64-bit prefix, which seems to render vgvoodoo2 inoperable, and it also automatically runs a ddraw patch that breaks things horribly. So, similarly to above, it is necessary to install the game normally, create a prefix, and then copy the files in:

1. Install the game, then make note of its location.
2. Find the game in the GOG sources and select it, then, in the lower-left corner, click the arrow next to “Install” and select “Locate installed game” to open the game’s properties dialogue.
3. Although not strictly necessary, let’s mirror the structure we used in Baldur’s Gate:
   1. Make note of the default directory from the properties dialogue, and then create it and enter it in a terminal.
   2. Create and enter a directory called “prefix”.
   3. Run the following command to create the wine prefix:

   $ WINEPREFIX=$PWD WINEARCH=win32 wineboot

   4. Find the previously-installed “Icewind Dale” directory and place it inside the “drive_c” directory the previous command created, inside a directory called “GOG Games”. This is important, unless you want to manually edit “icewind.ini” later.
4. With that done, return to Lutris and proceed along each tab as follows:
   • On the “Game info” tab:
     1. Select “Wine” as the runner.
   • On the “Game options” tab:
     1. Set the executable to “IDMain.exe”; it’s deep under the “prefix” directory.
     2. Set the wine prefix to the “prefix” directory noted earlier.
     3. If only for reference, set the “Prefix architecture” to 32-bit.
   • Under the “Runner options” tab:
     1. Set the Wine version to either the default or the GE version acquired previously. In this case, as previously noted, the GE version seemed to give better performance.
     2. Ensure that “Enable vgvoodoo2” is checked, as well as DXVK. VKD3D isn’t applicable here, so you may as well turn it off.
     3. Disable “Esync”, “Fsync”, “SuperFX”, and the anti-cheats for the same reason.
   • The “system” tab can likely be ignored; mess with it if you need to.
5. Click “Save”, and then click the new “Wine” button next to “Play” and select “Wine configuration”. If you’re prompted about installing Mono, just hit cancel. When winecfg pops up, select the “Graphics” tab and ensure “Allow the window manager to control the windows” is checked, then click “OK”.
6. Click the arrow next to the “Wine” button again and select “Run EXE inside Wine prefix” and select Config.exe. Set it up as you like, but leave the resolution and colour depth alone, and do not enable OpenGL, as that will negate and break what we’re trying to do.

If all went well, the game should now be playable.

Final Thoughts

I haven’t tested this with any window manager aside from awesome-wm, but in my case the game window shows up kind of in the centre of the screen; since awesome-wm is allowed to interact with it normally, I can simply invoke my “fullscreen” command to play the game with proper upscaling. Sometimes, especially with the non-GE versions of Wine, the game might sort of invisibly “hang” after quitting. Clicking the “Stop” button will correct that, much like with PlayOnLinux.

It took a bit of work to get to this point, but that’s just how it is when trying to wrangle old stuff on a platform for which it was never designed. I’m continually amazed at the progress being made in gaming on GNU/Linux, in truth. I hope one day GemRB is able to faithfully reproduce the original engines, but for now, this setup works much better than I ever expected.

Back to main page