It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
Beamdog initially released only 32-bit native GNU/Linux versions of their EE games, which meant one would need to install multilib in 64-bit systems just to play a game. However they later fixed this by releasing 64-bit versions of the games. On Window$ this "problem" never existed because Window$ installs 32-bit libraries in a 64-bt installation without even asking you - and that's nothing compared to other things they do, actually.

Concerning WINE, you can certainly use it to play the EE games, but I would never do that. First of all the native GNU/Linux versions of the games work flawlessly, so I see no reason to use a simulation while I can play the games natively. In addition, WINE is 32-bit (the 64-bit version of WINE is only experimental), so going the WINE way also means you have to install (otherwise useless) 32-bit libraries in a 64-bit system.

Also, openssl 1.0 was not old when the EE games were released. It was certainly a thing back then. The fact newer version of openssl existed doesn't mean GNU/Linux distributions adopted it immediately. Add to this openssl is a security library, and you have a perfect reason to avoid switching to a new version right away. This is only done in bleeding-edge distributions, eager to adopt anything new, assuming "new" automatically means "better" - which is far from being true. Such distributions are prone to instabilities by definition, and if you use them you accept the fact problems can and will occur. sooner or later. So Beamdog did well to use openssl 1.0 back when the games were released. They did not, however, did well to keep doing that 10 years later, when even the most conservative distributions use openssl 1.1. Their 2.6.6.0 version of the games is simply unplayable as it is, except for very old systems which never upgraded their GNU/Linux.

At any rate, solving the incompatibility issue is easy. Just do as I said in my previous post and the games will run without any issue. If you have all their EE games, it's probably better to just store the old_libraries_needed in one folder, accessed by all the EE games. This only means in each game the line you have to add in start.sh script should be slightly modified to:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:<add full path of old_libraries_needed here>
Post edited September 08, 2022 by Archimidis
avatar
ssling: Wine may introduce bugs but updating OS not?
Dependency hell is always a problem on Linux, but actual bugs during an OS's lifecycle are quire rare IMHO.

avatar
ssling: For performance you would need actual data from tests. There are cases where Windows game game in Wine/Proton performs better than native port, usually there is no difference especially with not demanding games like Baldur or Torment.
Fair enough, but a native game is always going to be faster (albeit maybe not noticeably faster) than one that has to go through syscall and graphics API translation. We're talking about well done ports here, not shoddy ones.

avatar
Archimidis: In addition, WINE is 32-bit (the 64-bit version of WINE is only experimental)
32-bit thunking in Wine is actively being worked on. The days when 64-bit support was experimental are long gone.
Post edited September 08, 2022 by WinterSnowfall
avatar
WinterSnowfall: Dependency hell is always a problem on Linux
Depends on your point of view. Shared libraries are the norm in GNU/Linux for a reason - although some distributions do deliver statically linked stuff by default. On the other hand, static linkage has the portability benefit. There is no "win-win" solution. As far EE games are concerned, the best solution would be to have the libraries needed in a separate package, installed once and used by all EE games. However I doubt this will ever happen because it comes with its own maintenance problems.

avatar
WinterSnowfall: We're talking about well done ports here, not shoddy ones.
Very true. I have yet to encounter issues. No matter how some people hate Beamdog (I don't), it is undeniable they did a great job porting Infinity games on GNU/Linux, and their enhanced editions are better than any heavily modded original one.

avatar
WinterSnowfall: 32-bit thunking in Wine is actively being worked on. The days when 64-bit support was experimental are long gone.
That's not what I have seen when I tried WINE 64-bit, and that was like a year ago. Maybe things are better now. I certainly hope so.
Post edited September 08, 2022 by Archimidis
avatar
WinterSnowfall: Dependency hell is always a problem on Linux, but actual bugs during an OS's lifecycle are quire rare IMHO.
Unless you use rolling release then there is no such thing as OS lifecycle. I assume that in case of BG:EE that old libssl was still included in Ubuntu LTS on release because it was "the default" most devs were aiming for? Now it doesn't matter anyway as they didn't bother to update builds and no one uses 10 years old Ubuntu nowadays.

avatar
WinterSnowfall: Fair enough, but a native game is always going to be faster (albeit maybe not noticeably faster) than one that has to go through syscall and graphics API translation. We're talking about well done ports here, not shoddy ones.
Yes at least it should be in theory. Making well done port is apparently not always easy. Games after Feral Interactive treatment are quite known to perform worse as native and that's company dedicated to porting.
Post edited September 08, 2022 by ssling
avatar
ssling: Loop Hero on GOG is another (or at least was few months ago when I played it).
I did not experience this one, but it might be because I do not use their shipped libraries in the first place.

avatar
ssling: We can't realistically expect lifetime support from devs and update everytime something becomes deprecated.
I think we all know the real solution for this kind of issue: keep proprietary assets, but release the engine under an open source licence ;)

On the other hand, I do expect support as long as the game/software is sold. Why am I giving them money if their product is no longer maintained?

---

avatar
Archimidis: Also, openssl 1.0 was not old when the EE games were released.
The issue here is not that they used OpenSSL 1.0, but explicitly OpenSSL 1.0.0. That one was deprecated months before the release of their first Enhanced Edition game.
avatar
vv221: ...
What do you think about shipping games in something like Appimage? Does it have any serious downsides? Because theoretically it should be both super easy to use for users (you don't need any technical knowledge at all) and solve all dependency problems.
Packaging for developers shouldn't be much more complex than preparing installers, maybe even easier because no need to test in different environments.
Post edited September 08, 2022 by ssling
If GOG starts selling AppImage (or Flatpak, or Snap) instead of their regular installers, I would no longer buy games from them. I don’t really care about the installer format as long as I can extract its content like any regular archive, and turn that into native packages. But these new so-called "portable" systems would make that much harder.

I trust the maintainers of my distribution to provide regular updates to the libraries used by my games. I would not trust neither GOG nor game developers to provide such support for the libraries they ship.
avatar
ssling: Unless you use rolling release then there is no such thing as OS lifecycle. I assume that in case of BG:EE that old libssl was still included in Ubuntu LTS on release because it was "the default" most devs were aiming for? Now it doesn't matter anyway as they didn't bother to update builds and no one uses 10 years old Ubuntu nowadays.
GOG or Beamdog could simply include the needed versions and softlink them, as they do for other games, but I guess nobody considered it at the time. And won't bother with it now, sadly.

avatar
Archimidis: That's not what I have seen when I tried WINE 64-bit, and that was like a year ago. Maybe things are better now. I certainly hope so.
They are indeed better. And the end goal is to deprecate any 32-bit components and use 64-bit libraries to run everything, including 32-bit games, but there's still a lot of groundwork to be done before that becomes possible.
avatar
WinterSnowfall: Better performance and increased stability. While new versions of Wine may introduce bugs, a Linux native version of a game only depends on the underlying OS.
Funny, A lot of games have shown more stable and better performance through WINE than when run natively on Linux. It's not so cut and dry as "native = better" for this.
avatar
paladin181: Funny, A lot of games have shown more stable and better performance through WINE than when run natively on Linux. It's not so cut and dry as "native = better" for this.
... as I said above, shoddy ports aside, this should not be the case.
avatar
paladin181: Funny, A lot of games have shown more stable and better performance through WINE than when run natively on Linux.
In my experience native ones are often much better supported than WINE emulation (over hundreds of games but mostly a single Linux distribution, so this is of course biased). I especially love games like Warhammer 40k: Gladius - Relics of War where native Linux performances and stability are much better than the native Windows ones.

Out of curiosity, what are some games you are thinking about when writing about a better experience through WINE than the native Linux one?
avatar
Archimidis: The solution is simple, provided your distribution keeps older libs in their repositories.
(1) Find a file named openssl-1.0.x. in your distribution repositories. It is a compressed library, and the compression method depends on the distribution. Extract the files libssl.so.1.0.0 and libcrypto.so.1.0.0 to a new folder, say "old_libs_needed". Alternatively, if you have access to a computer running an older version of your distribution, locate those two files in /usr/lib64 (or usr/lib, depends on the distribution), and just copy them to your new folder.
(2) Move the folder "old_libs_needed" in your main BG:EE directory, where "start.sh" exists. This is a simple shell script that launches the game, and you have to modify it a little. Edit start.sh and add one line, so that it looks like that:

...
# Initialization
CURRENT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CURRENT_DIR/old_libs_needed
cd "${CURRENT_DIR}"
....

(bold line is what you add in start.sh). Save and exit. The game should now run as usual.
Thanks for this! I couldn't get the ./play.it solution to work for me. Your solution was simple and effective.
...
Post edited November 16, 2022 by penguin-mancer
avatar
shanefeuz: I couldn't get the ./play.it solution to work for me.
Do you remember what did not work as expected?
If it was due to some bug, or unclear instructions, maybe we can fix this.