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.

I've got this

It is a worthy topic.

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.

1-D dri-drivers=i915,i965,r100,r200,nouveau \
2-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.

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.

Per game pack is probably better.

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.

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.

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.

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...

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.

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.

Awesome. Great job.

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

Done.
https://gitlab.freedesktop.org/mesa/mesa/issues/1924

kjliew wrote:

Done.
https://gitlab.freedesktop.org/mesa/mesa/issues/1924

Waking up an old thread, but I just got Heavy Gear II and after installing all the necessary 32-bit libraries on my Xubuntu 20.10 install, I can start the game and poke around the menus, but then when the 3D initializes I get the segmentation fault.

Looking at the linked gitlab, I'm guessing my only option would be to build my own Mesa from source, and patch that file?

I'm using a Lenovo laptop with an AMD A8 APU, using the radeon drivers for R5 graphics.

Run synaptic and search for "games". It may well have been recompiled to a later architecture. There should be at least 15gigs of fiies found. I did the on my AMDK6-2 400 build with 32-bit Devun Jessie and still haven't gone through all the software it has in than 15gigs.

Yes, MESA devs don't play games. 😉

Is it gonna be a 64bit vs 32bit problem now though, as far as I know any *buntu after 19 is 64bit only.