XDM is running on this rare machine you (probably) never seen before (pt.1) news - XDM mod for Half-Life

Hi! It's just me, Xawari. And I'm here to tell you about incredible adventure I had during last week. Personally.

This article will cover something special and out of ordinary. At least for this whole project.

Preamble

As you probably know heard, XDM is written with portability and compatibility in mind. Since most of the time it was played as a Half-Life mod, which is a Win32 x86 platform, it wasn't noticed by most. But now, when Xash3D has matured enough, it pays off! Quite unpredictably.

The unbelievable coincidence

Among people around me I'm a well-known computer enthusiast, passionate collector and hobbyist, so it's somewhat normal for me to get asked for a technical advice from time to time.

During a normal busy day I got a call from a friend saying "Look what I've got!". Intrigued, I opened the photos he sent me, and, boy, those got me excited...

In the next two seconds I already knew what am I going to do. "I need to assemble a team. The Team." And I had to do it fast. Immediately I call my friend from FWGS with only words "You won't believe!..", and "I kind of do" he replies. :) Turns out, he already got a whiff of rumors of this acquisition by my friend, but never knew it made its way to me.

Working out of town, I rushed to my kitchen home the next day, by a train, which took a few hours, but those went rocket-fast. Hours, not func_trains. And the same afternoon I was happily presented with... a computer:

Not a fancy-looking one, but horizontal, and quite light, actually, which is even better. I thanked my friend and took it home. Being who I am, I quickly wired it all up, hooked to my network, monitors, peripherals, and... Got greeted with a BIOS/UEFI logo screen. :D ...and that's it: no OS, no boot drive. But it works! It was not guaranteed at all. Finally, removing the cooler fan and the radiator revealed this beauty:

Skylake? Kaby Lake? Tiger Lake?? No, it's Baikal Lake! The BE-M1000 central processor unit!
For quick reference: Baikal is a low-power 8-core ARM CortexA57 CPU which runs at up to 1.5GHz with 8 Mali-T628 750MHz graphic cores. And it's a somewhat rare (and expensive) Russian processor!

It is intended to run special versions of Linux. But, since it's architecture is ARM-based and we have experience in porting Xash3D and XDM onto mobile platforms, there's a good start!

Already foreseeing the amount of upcoming work, I swiped the dust from my main machine and got to revisiting my code. All of the code. "I'm hoping you're not planning on getting much sleep tonight" - some random phrase slipped through my mind. "I don't" - replied my reflection in the monitor as the black desktop began showing up before me - "I wish I did, but really don't..."

The Cold Boot

The next day it was hot and sunny. But we weren't up for a walk. I met The Team, a1batross and mittorn, all hyped and ready for action. Equipped with a fresh image of the ALT Linux distro, designed specifically for Baikal platform, we returned to the machine. :)

After a short selfie session, we put our flash drive to use. The first boot we did was a live session - it worked fine, but then, my friend got us an internal SSD and we decided to reboot and install the OS properly. And that's where it went bonkers on us.

EFI directory not found? What a pity. Thankfully I've got the exactly right people with me! :) Yes, ALT Linux is not exactly rock-solid, but - heck - you sould've seen me trying to install Ubuntu on MY ordinary AMD64 laptop: It couldn't even see existing partitions on my SSD!

But, yeah - it's a rough start. I even asked a1batross to call the OS maintainer at some point, but we then settled at filing a bug report. And it was kind of late, anyway, past normal working hours. :D

Finally, we got it installed. Booted into Mate (worst thing I've seen, really! I was forced to work on GNOME for some time, I know what I'm talking about!). Our main work has begun.

The Missing Link

One might think that, since we already have ported Xash3D and XDM onto Linux and Android, porting to another ARM processor will be a piece of cake, but in reality It won't. Theoretically, yes, it's an ARM, practically, it's a unique SoC, a platform with its own drivers and compiler. And we now had to make use of that.

Another problem is the absence of two important APIs: VGUI and a music player. The thing about VGUI.dll is: originally, it is linked statically to a client.dll via vgui.lib from HL SDK during linking with MS Visual Studio toolchain. But that's i386 only! Half-Life never supported 64-bitness, let alone different architectures. And there's actually at least two versions of it with one-way forward compatibility (e.g. if you link your mod with newer vgui.lib, you won't get to run on HL1121-). There were several attempts to re-create the VGUI DLL from scratch, but they're very incomplete.

The music player also poses a few problems:

1. it depends on an old closed-source proprietary library called FMOD (because it was all we had at the time, 20 years ago!),
2. it, once again, makes heavy use of VGUI. What's wrong with FMOD? Its closeness! True, they've provided a few libs to be compiled with win32, linux64 and some consoles, but modern ARM64 platforms were unheard of at that time, And, of course, there are no .so/.libs for these.

Not only that, even i386 and amd64 FMOD builds have their own problems with current Linux sound systems. That's the drawbacks of using proprietary software.

So, a1ba, mittorn and me sat at our workstations, banging on keyboards ferociously to address all these (and even more later) problems in the limited time we had. A real code marathon, if you ask me. Oh, and don't forget the heat. Finally rare hot summer day and not only we missing it, we're suffering from it. Sitting in a building under direct sunlight doesn't really help programming, you know.

Miraculously, the unfinished OpenVGUI build succeeded and I managed to write a quick and dirty music API fallback: in case XDM does not detect FMOD DLLs SOs, it falls back to using extended Client Engine functions (engine API) or even console commands in the end. Of course, you can forget about seeking and getting track updates this way, but at least it (somewhat) works for single map soundtracks (which took a lot time to find!) in XDM.

All tools installed, all code compiled (quite fast, actually, when paralleled), it's time for the first run. And here's where it gets crazy...