Support us on Patreon
PayPalOne of the great game industry battles of the turn of century was the standoff between Quake III Arena and Unreal Tournament. With both multiplayer focused first person shooters released just weeks apart from one another, that the two games would wind up going head to head was inevitable. If pressed I am always going to have to say I favour the former, but the remarkable thing for us Linux users is that, for a time, both games lived harmoniously under the same publisher.
More than any other developer, Loki Software can be credited with founding the Linux games industry, and with them still riding high at the time, they went on to publish both titles on our platform. More than just popular games, Quake III Arena and Unreal Tournament were also flagships for the engine technology within. Unreal Engine 1 and id Tech 3 would go on to be used in dozens of other titles, some of which would also be ported by Loki Software before their closure in 2002.
While Quake III Arena was granted its place in eternity when its source code was released in 2005, community support for Unreal Tournament was able to breathe some new life into the game, even with the limitations of the closed binary. By 2018 however the game was no longer launching for Mesa users. Due to certain core files being statically linked to an archaic libstdc++ library, the game can only be ran outside of Software mode on the free graphics stack with the use of a hacked Mesa patch.
After spinning my own Mesa packages by use of the Arch Build System, I reinstalled Unreal Tournament using the data from GOG.com and the ut-install-436-goty.run Linux installer. I could now start the game without producing a segmentation fault, and other than some sound quality problems everything seemed to be normal. After installing a third party OpenGL renderer, OpenAL audio device, and S3TC textures the game was looking and sounding better than ever before.
With my love of a straight bot DeathMatch, it took me a while to discover that changing to any other kind of game mode from the menu would cause the game to crash with a "Signal: SIGIOT [iot trap]" error. This, along with the need to apply Mesa patches in the first place, severely hampers the game for use at my next LAN party. With the Linux versions of Unreal Gold, such as those provided by icculus.org or Unreal 227, also relying on this game to work, that takes them out of contention as well.
As I mentioned before, Unreal Tournament was not the only Unreal Engine 1 game Loki Software worked on. Rune has to be the most fitting port they ever produced, with the company's namesake Norse trickster god even appearing as the archvillain. It was also one of the last ports that Loki Software released before closing down, and as such is just modern enough to make me wince at the fact I am no longer capable of getting it to work.
With a patched Mesa the game launches and renders fine, but you can no longer load your saved games while using OpenGL, meaning you are once again stuck with Software mode. The crackling stuttering audio I encountered with Unreal Tournament is also present here, but is now unavoidable due the game shipping only with its default OpenAL audio device. I tried using some of the alternatives available for Unreal Tournament, but Rune refused to load them.
I remember playing through the whole game close to ten years back when I was still on Fedora and having a good time with it. Rune has a very solid if lengthy campaign with tight controls that plays more like its first person shooter contemporaries than many other third person games did. The developer Human Head Studios would go on to work on the original Prey, which also supports Linux and I have written about previously.
If there is one silver lining in all of this, it is that all of these games can be made to work reasonably well with WINE or Proton without the need to fiddle around with Mesa to get them to launch. Performance does suffer if you do not supply an OpenGL renderer such as those by Chris Dohnal, but once properly configured the games can be made to run almost as if they were native applications. I even got a higher frame rate in Unreal Tournament.
Launching them still requires some patience, as they all seem prone to false starts, but once you do get to the main menus all seems to be well. This also allows you to reunite the games with their brethren Deus Ex, which if not for the closure of Loki Software would have become a native Linux title. I can confirm that Rune Gold, Unreal Gold, Unreal Tournament GOTY Edition, and Deus Ex GOTY Edition from GOG.com all can be made to WINE well with a few tweaks.
For an engine with such a pedigree on Linux this outcome is still disappointing. It may just be my pride getting in the way, but there is something special about being able to get the old native binaries to work, especially in the case of Rune where I have it on disc with the full retail packaging. It also makes me wonder how well my modern library of native titles is going to run in twenty years time, and if I will be forced to use a compatibility layer to run some of them too.
According to Ryan Gordon's recent Patreon post, the former Loki Software employee once came close to reviving Rune on Linux in some form but it "slipped through [his] fingers". The source code release of Quake III Arena has allowed it to transcend all the boundaries imposed by time, while its erstwhile adversary begins to languish. For those who value games as more than just ephemera, I can only hope such releases start to become the norm.
UPDATE 1: Since publishing this article a new modified build of Unreal Tournament has come to light. This version has been made to work around the symbol collision with recent versions of libstdc++ which in turn produced the segmentation faults with modern versions of Mesa. I have also been made aware of a Lutris script that allows their package of Unreal Gold to run with Mesa.
Also thanks to adamhm for providing a method that allows all of the Unreal Engine 1 games to start reliably with WINE.
UPDATE 2: The OldUnreal project has released an updated build of Unreal Tournament with the blessing of Epic Games that no longer suffers from the issues mentioned here. More information can be found in this article by Liam Dawe.
Article taken from GamingOnLinux.com.
Quoting: Purple Library GuyOK, I don't know anything so this may be bogus, and anyway it's kind of shooting a mouse with an elephant gun, but . . . if worst came to worst, couldn't you run a VM and stick a whole old Linux in it and run the game in that?This is what Valve is trying to do with the containers. With the added benefit of security.
Quoting: lgpmichaelI'm not completely sure that UT was anything to do with Loki. My memory is a bit old and fuzzy from back then, but I do distinctly remember that Tux Games had to sell Windows UT boxes with an installer CD. It was 20 years ago though, so, you'll have to forgive my brain if I'm wrong {;-)There was only one box, that contained the penguin logo, but only the windows version.
You had to download the real engine and installer from the Loki site.
What tuxgames did was a service to it's customers.
The port was indeed done by Loki, but the distribution was different.
I remember trying to get a deal with a local software supplier to send me 1 linux game every month of their choosing. Online purchases were still a big hassle, as there was no easy way to pay (upon delivery or wiring), so having mandated them to take money of my bank account was the easiest way to go.
The linux platform ABI changes a lot, and I consider the windows API is just middle ware.
If we can change that somehow to a platform agnostic middleware, that should be better.
Most old windows games are hard to run on modern windows. You have to know what you are doing (do this, click that, install this, turn off that), while these games are usually running problem free on proton.
So yeah lets keep the API legacy on the windows side for now. There is no proton for windows, so only those that know how to fiddle with windows can run old games.
It does not mean I do not appreciate the work of feral games. They are really dedicated, so I don't expect them to stop supporting old builds.
Quoting: ArdjeAs a side note: personally I promote making bug free windows games, that perform perfectly on proton.It's not a case of Linux APIs changing, it's all about how the games are built. I have plenty of games from 10 years ago on Linux that work without a single issue.
The linux platform ABI changes a lot, and I consider the windows API is just middle ware.
If we can change that somehow to a platform agnostic middleware, that should be better.
Most old windows games are hard to run on modern windows. You have to know what you are doing (do this, click that, install this, turn off that), while these games are usually running problem free on proton.
So yeah lets keep the API legacy on the windows side for now. There is no proton for windows, so only those that know how to fiddle with windows can run old games.
It does not mean I do not appreciate the work of feral games. They are really dedicated, so I don't expect them to stop supporting old builds.
appetrosyan Feb 5, 2020
Quoting: Liam DaweQuoting: ArdjeAs a side note: personally I promote making bug free windows games, that perform perfectly on proton.It's not a case of Linux APIs changing, it's all about how the games are built. I have plenty of games from 10 years ago on Linux that work without a single issue.
The linux platform ABI changes a lot, and I consider the windows API is just middle ware.
If we can change that somehow to a platform agnostic middleware, that should be better.
Most old windows games are hard to run on modern windows. You have to know what you are doing (do this, click that, install this, turn off that), while these games are usually running problem free on proton.
So yeah lets keep the API legacy on the windows side for now. There is no proton for windows, so only those that know how to fiddle with windows can run old games.
It does not mean I do not appreciate the work of feral games. They are really dedicated, so I don't expect them to stop supporting old builds.
Sadly, not many of those games are OpenSource, and it’s only a matter of time when this issue crops up, if the community can’t patch the executable to work with newer libraries. Proton has one big advantage, being a non-ideal solution, it can work with very archaic code and make it work on a modern system.
That said, if possible, let’s have more FOSS games. I really enjoy Quake Darkplaces, and I don’t think that would’ve been possible if I’d tech 1 remained proprietary.
Quoting: appetrosyanSadly, not many of those games are OpenSource, and it’s only a matter of time when this issue crops upWhich is as true on Windows as it is on Linux though remember. All games eventually succumb to time, we're just in an interesting position thanks to Wine/Proton that can at times run games Windows 10 now cannot heh.
QuoteAfter installing a third party OpenGL renderer, OpenAL audio device, and S3TC textures the game was looking and sounding better than ever before.
What you have linked as OpenGL renderer is same OpenAL. That's a mistake I guess. Is the third party OpenGL renderer the same Stéphan's Kochen OpenGLDrv based on Chris Donhal's enhanced OpenGL renderer?
https://www.pcgamingwiki.com/wiki/Unreal_Tournament#The_game_runs_too_fast
In that case both native and WINE version of UT99 is better run with a FPS cap since it is heavyly affected by CPU speed. I suggest limiting it to 120 via .ini setting pointed at the guide.
2) For native Rune on Linux, I suggest using following scripts and libraries for sound and speeding issues.
https://www.icculus.org/lgfaq/#runeutfast
https://icculus.org/~ravage/
3) For sound on Loki games, I usually switch to OSS to translate to PulseAudio via osspd which returns much more stable results than ALSA nowadays.
Quoting: docofkultI have been contemplating doing a retro build for some time specifically for playing the Loki games. However, besides some dabbeling with Red Hat around the turn of the century, most of my Linux knowledge have been gained after Ubuntu came around. My initial idea is to do a close to contempary build with a contemporary OS as to not have to fight issues like described in the article. Hardware will likely be Pentium III and a 3dfx graphics card. Not too sure about which sound cards actually had good support at the time. I would appreciate any suggestions as to which OS to go with and any sound card recommendations.My personal opinion, if you're going to do an old school Linux, go with Mandrake/Mandriva. They were the king of user friendly before Ubuntu came along. They were I believe the first to do for Red Hat's rpms what apt does for debs. And for someone whose early experience was Red Hat, well, Mandrake was based on Red Hat in somewhat the way Ubuntu is based on Debian.
Quoting: docofkultI have been contemplating doing a retro build for some time specifically for playing the Loki games. However, besides some dabbeling with Red Hat around the turn of the century, most of my Linux knowledge have been gained after Ubuntu came around. My initial idea is to do a close to contempary build with a contemporary OS as to not have to fight issues like described in the article. Hardware will likely be Pentium III and a 3dfx graphics card. Not too sure about which sound cards actually had good support at the time. I would appreciate any suggestions as to which OS to go with and any sound card recommendations.SB Live 5.1 with emu10k1 chipset worked miracles back then. So much pain saved thanks to beeing able to open it "exclusively" multiple times. Do not confuse with the emu10k tho. That was garbage :D
Quoting: Purple Library GuyQuoting: docofkultI have been contemplating doing a retro build for some time specifically for playing the Loki games. However, besides some dabbeling with Red Hat around the turn of the century, most of my Linux knowledge have been gained after Ubuntu came around. My initial idea is to do a close to contempary build with a contemporary OS as to not have to fight issues like described in the article. Hardware will likely be Pentium III and a 3dfx graphics card. Not too sure about which sound cards actually had good support at the time. I would appreciate any suggestions as to which OS to go with and any sound card recommendations.My personal opinion, if you're going to do an old school Linux, go with Mandrake/Mandriva. They were the king of user friendly before Ubuntu came along. They were I believe the first to do for Red Hat's rpms what apt does for debs. And for someone whose early experience was Red Hat, well, Mandrake was based on Red Hat in somewhat the way Ubuntu is based on Debian.
It was actually Mandrake, not Red Hat, come to think of it :) So yes, probably what I should look at first.
Quoting: BillFlemingThe author of this article really didn't do their research. The game runs fine without needing a patched mesa.You just need to install some extra audio packages and launch the game using a special command for the audio.Trust me when I say that I have been aware of this issue for years and that I spent a great deal of time researching when crafting this article. I did miss your AUR package, but that is because I deliberately avoid distribution specific methods so as not to exclude people with other setups. All that being said, I am happy to say that your build of the game does work.
Looking into it, the "ut99v451-linux.2019-07-21.tar.gz" package you are using has hacked game binaries that have been made to work around the symbol collision with modern versions of libstdc++ which in turn produced the segmentation fault with Mesa. This is NOT TRUE of the last official release of the game, which is provided by the "ut-install-436-GOTY.run" installer I used.
Again, I will admit to not being aware of this hacked version, but considering that it only shows up on Google from either ./play.it or the gog-unreal-tournament-goty AUR package I can hardly be blamed for that. The vast majority of articles and sources online do not refer to this package, likely because it is not official and did not even exist before last summer.
Quoting: BillFlemingThe game's old renderer is also still usable so you don't even have to mod the game to play, but it won't support super high res. (2560x1080 works, 2560x1440 didn't for me)I never claimed that it did not work. I did need to supply a new audio device in order to get better sound, but the original OpenGL renderer did indeed work fine given its limitations.
Quoting: rea987What you have linked as OpenGL renderer is same OpenAL. That's a mistake I guess. Is the third party OpenGL renderer the same Stéphan's Kochen OpenGLDrv based on Chris Donhal's enhanced OpenGL renderer?Okay, that one is my bad. It was supposed to link to a compiled version of Stéphan Kochen's OpenGLDrv renderer like you said.
Quoting: Perkeleen_VittupääSoo, could all this be possible to package somehow to a state that even a non-tech-savvy random occasional gamer could then enjoy Unreal Tournament on Linux?Well, now that I have a binary that works without issues, I will at least be writing a guide on how to get Unreal Tournament working on modern Linux distributions as a sequel to this article.
Quoting: Liam DaweYeah, there is nothing about Windows that makes it less susceptible to these problems than Linux. This is just one of the benefits of WINE being a compatibility layer. It grants compatibility, even for older titles.Quoting: appetrosyanSadly, not many of those games are OpenSource, and it’s only a matter of time when this issue crops upWhich is as true on Windows as it is on Linux though remember. All games eventually succumb to time, we're just in an interesting position thanks to Wine/Proton that can at times run games Windows 10 now cannot heh.
Last edited by Hamish on 6 February 2020 at 2:44 am UTC
TheRiddick Feb 6, 2020
Quoting: BillFlemingThe author of this article really didn't do their research. The game runs fine without needing a patched mesa.
You just need...
I guess the point was that it's not a out of box experience, like many things under Linux, you need to stand on your head and rub your tummy to get some things going.. lol
Three libs from [UTPGPatch451.tar.bz2] have a [symbol conflict] with modern
libstdc++.so.6. Sadly `objcopy --redefine-sym` can't [redefine dynamic symbols]
and hexediting just delays the crash to loading Pit of Agony. Use [elfhash] to
replace the symbol with one the same length and rehash the elf.
for lib in System/Core.so System/NullDrv.so System/NullRender.so; do
md5sum $lib
../elfhash/elfhash -f __dynamic_cast -t __dynloki_cast $lib > /dev/null
md5sum $lib
done
522154c5c551de4cda673f9b75cae109 System/Core.so
fbbcff9c5e40de08acb7c98f364a9707 System/Core.so
7600d224c7614c7f6a07c5eef8c66015 System/NullDrv.so
3b075a8a3c4773759fe6f7c935cb4ff0 System/NullDrv.so
89f4cc264c97fe5f97d6c63dd6a05e26 System/NullRender.so
c317de7117e78b9e16becc8583c3752a System/NullRender.so
[UTPGPatch451.tar.bz2]: https://web.archive.org/web/20160803031207/http://www.utpg.org/patches/UTPGPatch451.tar.bz2
[symbol conflict]: https://bugs.freedesktop.org/show_bug.cgi?id=108933
[redefine dynamic symbols]: https://sourceware.org/ml/binutils/2006-03/msg00005.html
[elfhash]: https://github.com/cjacker/elfhashIt should also be noted that this build is based on the unofficial UTPG 451 patch.
I can also now confirm that the "Signal: SIGIOT [iot trap]" error when changing game modes is a product of using Stéphan Kochen's OpenGLDrv renderer. When using SDLGLDrv it works fine.
Last edited by Hamish on 24 February 2022 at 12:18 am UTC
Perkeleen_Vittupää Feb 14, 2020
Quoting: TheRiddickQuoting: BillFlemingThe author of this article really didn't do their research. The game runs fine without needing a patched mesa.
You just need...
I guess the point was that it's not a out of box experience, like many things under Linux, you need to stand on your head and rub your tummy to get some things going.. lol
The universal packaging is one thing helping towards our "promised land" :)
Quoting: AnthraXOldUnreal recently took over maintenance of the UT99 source code and we now have a beta patch available for macOS and Linux. We took this opportunity to modernize the codebase. The new Linux binaries were compiled with gcc 4.8 and they link against a somewhat recent version of libstdc++. We also use SDL 2.0.10 now.
Whaaaat?!! That's what I have been asking for years! When will you be able to release it? And by the way; THANK YOU!
Quoting: GuestBy the way, this archive moved to a new domain and can now be found at https://downloads.dotslashplay.it/resources/unreal-tournament/I have fixed the link, thanks.
I kept a redirection in place, but updating the URL in the article might still be a good thing to do.
See more from me