VOGONS

Common searches


First post, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

I recently acquired 2 *ancient* Linux native games. The initial games were released back in 1999 and the native Linux port were released in 2001. They were targets for 32-bit x86 Linux, kernel 2.1 and built with ancient glibc, gtk, glib, early SDL and OpenAL. I am trying to get them to run on modern Linux such as ArchLinux x86_64 using the lib32 multilib support. They don't have source ports, otherwise getting them to run on Linux will be easy. They are:

Both games comes with software and OpenGL renders. The goal is to get OpenGL renderer to work since software renderer just work. They have similar system requirements, asking for Pentium 200 MMX with 3D hardware or Pentium 2 233 for software-only. In fact, with such system requirements, playing on VM is also quite possible.

The main issue is that none of the modern Linux distros still provide glib-1.2 and gtk-1.2 anymore, so they have to be built separately. Amazingly, those games still works 😀 , but with a few caveats:
- i915, i965 OpenGL driver OK
- nvidia-390xx OpenGL driver OK
- MESA Gallium3D-based OpenGL SIGSEGV (r600, nouveau, radeonsi, virgl, swrst)

Unfortunately, the failure of MESA Gallium3D-based OpenGL drivers is disappointing, it kills modern AMD hardware for Linux retro-gaming (anyone care 😵 ?) It is 100% reproducible with exactly the same core dump and stack trace. It also disallows Linux retro-gaming on Linux VM since the VirGL driver is also Gallium3D-based.

Last edited by kjliew on 2019-10-08, 00:59. Edited 1 time in total.

Reply 1 of 15, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie

I don't suppose they'd listen to bug reports about those segfaults would they?

If Intel GPU's work just fine (as far as I'm aware those things are open source drivers only to begin with) I see no reason why the open source ATI/AMD shouldn't work, unless the contributors to the project aren't willing to fix bugs.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 2 of 15, by Caluser2000

User metadata
Rank Oldbie
Rank
Oldbie

I've got this

20190904_081625.jpg
Filename
20190904_081625.jpg
File size
1.33 MiB
Views
630 views
File license
Fair use/fair dealing exception
20190904_081602.jpg
Filename
20190904_081602.jpg
File size
1.35 MiB
Views
630 views
File license
Fair use/fair dealing exception

It is a worthy topic.

There's a glitch in the matrix.

Reply 3 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
DracoNihil wrote:

If Intel GPU's work just fine (as far as I'm aware those things are open source drivers only to begin with) I see no reason why the open source ATI/AMD shouldn't work, unless the contributors to the project aren't willing to fix bugs.

There is 2 types of OpenGL drivers in MESA, Gallium3D and DRI.

-D dri-drivers=i915,i965,r100,r200,nouveau \
-D gallium-drivers=r300,r600,radeonsi,nouveau,virgl,svga,swrast,iris \

As you can see, the Intel's ones that work are the DRI-based. They do have the new iris Gallium3D-based OpenGL driver for Broadwell+ graphics but I don't have the hardware at my disposal to test and I think it will fail the same way. I don't have older ATI/AMD or NVIDIA hardware to test for the DRI-based drivers, which I strongly believe they will work, too. ATI/AMD has another option of using the abandoned Catalyst driver which isn't quite playing nice with modern Linux with recent kernel and Xorg. That means one has to downgrade the kernel and Xorg and keep them forever... 😵

DracoNihil wrote:

I don't suppose they'd listen to bug reports about those segfaults would they?

Do you mean filing bug report to MESA? Well, this is a tough one because the SIGSEGV point to the C++ init code for static initialization and constructors. I need to see if I can make a simple reproducible test case without requiring the whole game. And well, it is just games anyway and pretty old stuffs, so I am not sure if they would care.

Reply 4 of 15, by xjas

User metadata
Rank l33t
Rank
l33t

No idea how feasible this is, but it'd be nice if these legacy-compatible libs could be bundled up into a Wine-like flatpack that you could install on any modern distro. Either a "per game" pack or one big one that tries to be as general as possible (maybe covering all the 32b versions of typically needed libs from 1998~2006.)

In some ways, it seems like running old Windows games on Linux is better supported than running old Linux games on Linux. It's nuts.

twitch.tv/oldskooljay - playing the obscure, forgotten & weird - most Tuesdays & Thursdays @ 6:30 PM PDT. Bonus streams elsewhen!

Reply 6 of 15, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie
kjliew wrote:

Do you mean filing bug report to MESA? Well, this is a tough one because the SIGSEGV point to the C++ init code for static initialization and constructors. I need to see if I can make a simple reproducible test case without requiring the whole game. And well, it is just games anyway and pretty old stuffs, so I am not sure if they would care.

Have you tried running the games with MESA_EXTENSION_MAX_YEAR=2001?

Refer to: https://www.mesa3d.org/envvars.html for more information.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 7 of 15, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Also, do any of the drivers expose the S3TC extension? Ryan Gordon or someone of similar caliber might also have insight into what the games require to initialize.

Probably make it clear if you do contact Icculus that any advice is appreciated, none expected, and you're willing to do the heavy work. He's extremely generous with his time and knowledge, but he's also a busy professional, and neither of these titles are in any way his responsibility to support.

All hail the Great Capacitor Brand Finder

Reply 8 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
xjas wrote:

In some ways, it seems like running old Windows games on Linux is better supported than running old Linux games on Linux. It's nuts.

That is quite true indeed. Linux software philosophy of disrespecting ABI stability and source-based distribution are both a blessing and a curse. On one hand, they promote architecture agnostic portability and job security for software developers and on the other require that someone to maintain the software for life to keep up with the latest kernels, compilers, C/C++ standards and libraries. The moment a piece of software was left out of favor (become an underdog) it will take considerable effort to restore its usability on modern Linux systems, even if source is available.

Reply 9 of 15, by root42

User metadata
Rank Oldbie
Rank
Oldbie

Early Linux was terrible in backwards compatibility. It has gotten much much better, but it’s still an issue. However try to run DirectX 3 games on modern Windows. I still have a bunch of Loki games big boxes. I don’t think I will ever be able to run them again...

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 10 of 15, by DracoNihil

User metadata
Rank Oldbie
Rank
Oldbie
root42 wrote:

However try to run DirectX 3 games on modern Windows.

That's still a crapshoot even on Wine. Especially on modern GPU's, especially when the open source driver devs are more focused on modern feature sets rather than trying to coax backwards compatibility out of the GPU's of today.

I still can't get Hellbender's Direct3D to work correctly on anything, Wine or Windows.

Steam Profile
YouTube Channel
Seal of Nehahra

Reply 11 of 15, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Yeah 😀 I nailed it! 😀

It's a MESA Gallium3D one-liner bug at least for builds without enabling NDEBUG. The C++ iostream inclusion for debug logging is the culprit of SIGSEGV. Now, both games runs perfectly with Gallium3D OpenGL drivers. The systems today are more than capable of running the games in full glory. I can even run them on AMD C-60 laptops at the highest resolution. Oh, both games run quite OK on ASUS EeePC at 640x480 with the Celeron M at 900MHz, well beyond the game requirements. They can also run on QEMU-KVM using the VirGL renderer for accelerated OpenGL and completely playable on beefier CPU such as FX8300/Nouveau and Ryzen APU.

Before getting to the fix, I managed to bring up Glide2x pass-through from Linux VM and with the 3Dfx MesaGL shipped in Heavy Gear II. The game also plays very well at the max 1024x768x16bpp supported resolution, but with the caveats that it needs root access for /dev/mem and a single-CPU Linux VM. Anyway, VirGL acceleration works and makes all this redundant, but it will still remain useful for Linux VM from Windows since VirGL does not work for QEMU Windows. For now, Glide pass-through remains the only viable 3D acceleration for QEMU Windows.

Reply 12 of 15, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Awesome. Great job.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 13 of 15, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
kjliew wrote:

Yeah 😀 I nailed it! 😀

It's a MESA Gallium3D one-liner bug at least for builds without enabling NDEBUG. The C++ iostream inclusion for debug logging is the culprit of SIGSEGV. Now, both games runs perfectly with Gallium3D OpenGL drivers. The systems today are more than capable of running the games in full glory. I can even run them on AMD C-60 laptops at the highest resolution. Oh, both games run quite OK on ASUS EeePC at 640x480 with the Celeron M at 900MHz, well beyond the game requirements. They can also run on QEMU-KVM using the VirGL renderer for accelerated OpenGL and completely playable on beefier CPU such as FX8300/Nouveau and Ryzen APU.

Before getting to the fix, I managed to bring up Glide2x pass-through from Linux VM and with the 3Dfx MesaGL shipped in Heavy Gear II. The game also plays very well at the max 1024x768x16bpp supported resolution, but with the caveats that it needs root access for /dev/mem and a single-CPU Linux VM. Anyway, VirGL acceleration works and makes all this redundant, but it will still remain useful for Linux VM from Windows since VirGL does not work for QEMU Windows. For now, Glide pass-through remains the only viable 3D acceleration for QEMU Windows.

Could you please send in a report to Mesa?
https://gitlab.freedesktop.org/mesa/mesa/issues

All hail the Great Capacitor Brand Finder