Consider Donating

• a1batross - initial Xash3D SDL2/Linux port author, Xash3D FWGS engine maintainer, creator of non-commercial Flying With Gauss organization
  • Boosty page
• nekonomicon - maintainer of hlsdk-portable, mdldec, opensource-mods.md and Xash3D FWGS contributor (*BSD/clang port, PNG support, etc)
  • Boosty page
• Velaron - maintainer of cs16-client & tf15-client and Xash3D FWGS contributor (Android port, voice chat, etc)
  • Buy Me A Coffee page
• SNMetamorph - maintainer of PrimeXT & GoldSrc Monitor and Xash3D FWGS contributor (Windows port, voice chat, etc)
  • Boosty page
  • Other donation methods
• $_Vladislav - tester of Xash3D FWGS, YaPB Project member, editor of the Official YaPB Documentation (in English and Russian), curator of the YaPB Graph Database and author of YaPB Waypoint/Graph Pack. Also does the Russian localization of text, images (gfx/shell), as well as additional menu buttons in English used in Xash3D FWGS for various mods.
  • Boosty page

Diffusion: the first large-scale standalone game released on Xash3D FWGS​

by Aynekko​

At November 22, Diffusion mod was finally released after almost 10 year of development. This is the most large and detailed mod with unique lore and setting, and the first standalone game released on Xash3D FWGS.

Highly recommend to check at this mod on ModDB page, if you didn't yet. Also, this mod took 2nd place at Mod of the Year 2025 Awards on ModDB!

PS Vita port improvements​

by SNMetamorph​

This year, cs16client was ported to PS Vita, attracting a lot of people attention, especially on Reddit. But just compiling it for PS Vita was not enough, to make it playable a bunch of things were changed: touch settings fine-tuned, voice chat was enabled by default, brand-new touch controls layout for PS Vita & Nintendo Switch was made, documentation for touch controls was written too.

In addition, the acquisition of a unique Console ID (CID) for the PS Vita platform has been implemented to generate a unique XashID to avoid ID collisions between different clients playing on the same platform.

Metamod-FWGS: cross-platform Metamod-R fork​

by SNMetamorph​

Xash3D FWGS and most of mods (thankfully to hlsdk-portable) supports LP64-compatible architectures for years. But other important server-side tools such as Metamod and AMX Mod X does not support anything but x86 architecture.

Also, Metamod-R contains a lot of x86 JIT optimizations, patching hacks, constrained by binary compatibility with ReHLDS and legacy game libraries, and not flexible enough to be compatible with wide variety of compilers/toolchains and architectures. This is why we decided to do our cross-platform Metamod fork which has priority to work with Xash3D-related things in first place.

Nodemod is the first plugin that works with 64-bit Metamod, also it implements all functionality from basic AMX Mod X plugins such as administrative functions, map voting, localization, fun features and so on. It uses JavaScript and TypeScript languages for plugins, instead of Pawn, which makes possible to bring wider audience for making new plugins.

GoldSrc voice chat support​

by pwd491​

Users running Xash3D can now hear and talk to GoldSrc players, as long as those GoldSrc players are running the latest Steam version of the game. The Silk voice codec isn`t supported yet.

GoldSrc spray customization support​

by pwd491​

As for now, GoldSrc users can see sprays of Xash3D users, and this works in opposite way too. Moreover, UX are significantly improved comparing how it was in GoldSrc: you don't need to mess with tempdecal.wad manually anymore, just select desired image in menu and engine will automatically resize, generate transparency mask and properly generate WAD texture for you.

GoldSrc compatibility improvements​

by Flying with Gauss​

• Disabled autogenerating gameinfo.txt (PR #1947)
• Added support for sprites with less than 256 colors in palette
• Fixed TE_BLOODSPRITE tempentity behaviour to match GoldSrc
• Fixed status client-side command behavior to match GoldSrc
• Enabled applying texgamma for sprites/studiomodels textures during loading
• Added support for playing/recording demos in GoldSrc format
• Added support for GoldSrc masterserver protocol

Microsecond sleep support for some platforms​

by a1batross​

Microsecond sleep makes possible to suspend game loop in time period between two game frames, instead of using busy-wait loop like in GoldSrc and vanilla Xash3D. This results in fewer CPU usage, lower temperatures & energy consumption. Instead of wasting CPU cycles inside busy-wait loop, now these cycles could be properly managed by OS scheduler and spend on useful tasks for other processes.

If you want check how this feature works on your setup, you could use host_sleeptime_debug console variable.

Support for VFS mount of compressed ZIP archives​

by a1batross​

Now it's possible to load files from compressed ZIP archives in same way as it was with .pak, .pk3 and .pk3dir formats. Though, this is not preferable option, because compression makes perceivable performance overhead.

New iOS port​

by ksagameng2​

A new iOS port of Xash3D FWGS is now available, featuring updated platform support and improved compatibility with modern iOS devices.

FFmpeg-based video playback​

by a1batross​

Xash3D FWGS now fully supports videos playback using FFmpeg library, replacing the legacy "Video for Windows" backend. This means intro videos are no longer limited to the 32-bit Windows build and Cinepak codec, they can now be played on other platforms too. The update also adds support for the WebM videos introduced in the Half-Life 25th Anniversary Update. Supported video formats is .mp4 with H264 codec, .webm with VP9 codec and .avi with Cinepak codec.

On Android and other non-desktop platforms FFmpeg libraries is not included in the builds by default in order to keep the engine builds lightweight.

Support for loading maps in BSP2 format at runtime​

by a1batross​

BSP2 is the different version of BSP format for maps that have expanded some data types from 16 to 32 bits, consequently expanding some of limits related to maps format.

Back in the days, it was impossible to load BSP2 maps in runtime, because engine should be recompiled to be able to load these maps and also this was breaking compatibility with classic BSP format which was a serious concern. Now engine supports both of formats without special build options.

Mounting HD, Addon, Localization and Low Violence directories​

by a1batross​

Now engine can load content from the folders gamedir_hd, gamedir_language, gamedir_addon, and gamedir_lv, where gamedir means the name of the game directory, such as valve, gearbox, cstrike. For example, this feature makes possible to do proper localization of mods and standalone games, or making HD packs for existing mods. Documentation regarding to localization feature will made later, but as an example you could check how it was done in Diffusion mod.

List of cvars for mounting directories:

• fs_mount_hd – mounts the directory with HD models
• fs_mount_l10n – mounts the directory containing localization files
• fs_mount_addon – mounts the directory with custom content (similar to the custom folder inside the game directory)
• fs_mount_lv – mounts the directory with low-violence content

Drop of legacy Xash3D FWGS protocol​

by Flying with Gauss​

As of December 1, 2025, support for legacy Xash3D protocol 48 from mid-2010s era has been dropped, and players on the new engine will no longer be able to connect to servers running on the old engine. Also, servers running on deprecated protocol won't show up on public servers list anymore.

TUI Main Menu​

by numas13​

A new text-based experimental menu written in Rust arrived this year. Nothing special to say here, it was made just for fun.

Luma texture support in Half-Life​

by a1batross​

Engine now supports fullbright/luma textures, identified by the ~ prefix in the texture name. This feature initially inherited from Quake, but at some point it was broken in GoldSrc and nobody noticed. But finally somebody did. Feature is disabled by default, but can be enabled by setting the r_allow_wad3_luma console variable to 1.

Fullscreen mode fixes​

by a1batross​

In recent engine updates, several issues related to fullscreen mode have been fixed. Previously, when users enabled fullscreen, the game could actually remain in a window or start with an incorrect screen resolution. This issue was fixed in commit 4a16ca8.

Another issue caused the engine to get confused about the window state when exiting fullscreen. After switching to windowed mode, the window could have an incorrect size or behave as if it was still maximized. This was fixed in commit ad01be8.

Other minor changes & bug fixes​

by Flying with Gauss​

• Fixed incorrect XashID generation on Windows due to uninitialized string
• Improved compatibility with GoldSrc-based clients behavior (thanks @Garey27)
• Fixed loading of DDS with volume textures
• Attempt to automatically create .nomedia file in directory where games are located on Android
• Fixed erasing physinfo on client connect, when it was already set by game logic on save restore
• Fixed SQB in event playback function
• Fixed crash if server sends new movevars before entities were created
• Fixed command line window popping on Windows when starting engine
• Fixed mitigations of speedhack and other input commands spoofing hacks
• Fixed some of exploits that were made possible to crash servers
• Fixed bug when engine couldn't start on Windows in case if file path contains non-latin symbols
• Fixed restoring player view entity after save restore (fixes trigger_camera usage)

Consider Donating

• a1batross - initial Xash3D SDL2/Linux port author, Xash3D FWGS engine maintainer, creator of non-commercial Flying With Gauss organization
  • Boosty page
• nekonomicon - maintainer of hlsdk-portable, mdldec, opensource-mods.md and Xash3D FWGS contributor (*BSD/clang port, PNG support, etc)
  • Boosty page
• Velaron - maintainer of cs16-client & tf15-client and Xash3D FWGS contributor (Android port, voice chat, etc)
  • Buy Me A Coffee page
• SNMetamorph - maintainer of PrimeXT & GoldSrc Monitor and Xash3D FWGS contributor (Windows port, voice chat, etc)
  • Boosty page
  • Other donation methods

GoldSrc network protocol support​

by a1batross​

Since this autumn, GoldSrc protocol support is in the mainline engine and available for testing for anybody. This feature is still a work-in-progress, but anyway it is good enough to be called playable. We appreciate any bug reports and contributions according to it.

For connecting to GoldSrc-based servers, you can use the console command: connect <ip> gs. Also, GoldSrc servers can be added to the favorites list - just don't forget to choose the proper protocol when adding it.

There is short footage of playing Counter-Strike 1.6 on some GoldSrc-based server.

But keep in mind, there are requirement for server to be able to accept connections from Xash3D-based clients: it should use Reunion or Dproto. Without this requirement, you will just get "Steam validation rejected" error on connecting. That is because proper authorization with Steam API is not implemented in engine yet. There is a list of things that are still unfinished:

• Authorization using Steam API (first priority)
• Voice chat on GoldSrc-based servers
• Player sprays on GoldSrc-based servers

Also, we encountered that some GoldSrc-based servers are recognizing Xash3D clients as "fake clients" and banning/kicking them. Maybe this problem will be solved along with better compatibility with GoldSrc behavior, but maybe not - we don't know the logic behind this useless "fake client" check.

Voice chat improvements​

by SNMetamorph and a1batross​

Fixed an issue when voice chat sound would become completely distorted when multiple players spoke simultaneously. Also, some settings related to voice chat were added to the multiplayer settings menu. Voice chat button was added to touch configuration for Android port.

There is short video with demonstration of working voice chat in multiplayer.

Server browser improvements​

by Flying With Gauss​

Added tabs with favorites and recent servers, basic server filtering was added (in the bottom).

Also, an entirely new menu for viewing server detailed information was added.

Support for Ogg Vorbis and Ogg Opus audio formats​

by SNMetamorph​

We've needed some kind of MP3 alternative for a long time. Since being invented back in 1993, nowadays MP3 is far inferior to its modern alternatives in both compression efficiency and audio quality. At the same time, also the best lossy audio compression codec Opus is open-source and free, and we're already using it for voice chat - why don't use it for audio files too? Also, some of the mods using really a lot of sounds, and at some point audio compression efficiency can save several gigabytes of disk space.

What about Vorbis codec? It's still better than MP3, but from practical point of view it can be useful in terms of backward compatibility with existing content (because, obviously, if you have lossy-compressed audio - it's better to not recompress it to another format, because this will lead to "generation loss"). Ogg Vorbis is pretty wide-spread audio format, also other idTech-based game engines supports it.

The sound looping feature, which was already supported in MP3, now also supported in both these formats too.

Video playback support​

by a1batross​

This is from that rare kind of feature, that had already been in the engine for a long time, but could not be used for technical reasons. Originally, video playback was dependent on the platform-specific "Video For Windows" framework and the ancient Cinepak codec. For proper working, it should be installed system-wide and also it's available for use only for 32-bit processes and exclusively for Windows. Because of that, users were having a lot of troubles while trying to get things working, and with some circumstances it was not possible at all.

In engine and some of the mods, we support (and use) 64-bit builds for a long time already. Also, we do care about other platforms rather than only Windows. This is why we decided to completely get rid of VFW-related code and instead use ffmpeg for video playback. Also, we decided that video playback support should be an optional feature - ffmpeg libraries are bulky; also, most mods don't use videos anyway. So, anybody who has plans to distribute mods along with the engine, or just want to free up some disk space will be able to just remove those libraries.

Here is a short demonstation of the video playback feature within PrimeXT. The original valve.avi intro video was used for it.

Port for Sega Dreamcast (WIP)​

by maximqaxd and megavolt85​

This is still in progress, but it already works on actual hardware. Port can load content that was originally made for Dreamcast port, because it supports all of that platform-specific content formats such as PVR with VQ compression and ADPCM WAV sounds. Multiplayer works too.

MacOS port rehabilitated​

by sofakng​

Project building issues on MacOS were resolved, and automatic builds for MacOS were added to CI. But this port isn't well-tested anyway, and it is possible to catch some MacOS-specific bugs: in this case, feel free to report it on GitHub. But our capabilities with the MacOS port are limited, since nobody from the developers has any relevant hardware, and because of it we're looking for a proper maintainer.

Compatibility with GoldSrc improved further​

by Flying With Gauss​

There isn't much to describe here, as it involves plenty of minor changes that are hard to track down retrospectively. In some cases, incompatibility was caused by differences in console variables. Sometimes, it was caused by differences in internal logic between GoldSrc and Xash3D.

• Implemented PHS/PAS generating; this helped to fix issue #619
• Added room_off console variable; after this Sven Co-op 4.8 client started working with Xash3D FWGS
• Added gl_overbright from early GoldSrc versions, also some changes with gamma were made for better matching with GoldSrc looking
• Added gl_fog console variable for toggling OpenGL's built-in fog implementation. Some of GoldSrc servers anticheats were checking this value
• Added fps_override console variable for overriding framerate soft limit
• Reverted ancient GoldSrc shadows, this feature was reintroduced to GoldSrc at the HL25 anniversary update - as of today, we support it too. It could be enabled with r_shadows console variable
• Fixed broken physics behavior on high FPS: it was caused by rounding error in a physics code

Complete IPv6 support in multiplayer​

by Flying With Gauss​

As of today, engine and masterserver both support IPv6. And we have some masterservers running on the Internet through IPv6. This means anybody could set up their Xash3D FWGS server on the Internet with IPv6, and it will be presented for other clients who also have IPv6 address. Also, it is well tested, and we didn't discover any issues with it.

If you, for some reason, need to run a dedicated server exclusively on IPv6, you can use the -noip startup parameter, which completely disables IPv4 networking.

Published Docker image of up-to-date XashDS​

by SNMetamorph​

If you have some VDS or PC with an installed Linux distro, now it's possible to set up a Half-Life dedicated server based on the up-to-date Xash3D FWGS engine build in a couple of actions! Also, this Docker image has pre-installed Metamod, AMX Mod X, and bots using jk_botti Metamod plugin.

For now, a pre-built Docker image is only available for Half-Life, but in the future we hope to build images for other mods too (such as Counter-Strike 1.6).

Here is Docker Compose file example. You can read more information at GitHub repository.

services:
  xashds:
    image: snmetamorph/xashds-hldm:latest
    container_name: xashds-hldm
    restart: always
    command: +map crossfire
    ports:
      - '27015:27015/udp'

Hardcoded sounds overriding through sounds.lst​

by a1batross​

This brand new feature can be used to override some of the hardcoded sounds in temp entities and server physics. You can read a more detailed description in the documentation.

Support for external textures​

by a1batross​

This feature allows you to create HD texture packs for classic mods without involving any code changes. Initially, this feature was presented in some of the old vanilla Xash3D versions, but was removed by Uncle Mike at some point, and now it's back here again. You can read a more detailed description in the documentation.

Other minor changes​

by Flying With Gauss​

• Added SIGTERM signal handling for XashDS, it's needed for the graceful shutdown of the dedicated server inside Docker container
• Enabled engine binaries signing for the Windows platform, this helped a lot with false-positive antivirus detections
• Added console variable cl_logomaxdim for setting maximal dimension for player sprays, default is 96 units
• Added more information to logs: engine build number, VCS branch name & commit hash, platform and architecture name, game startup parameters
• FastDL improvements: support for chunked transfer encoding and gzip compression
• Android port improvements: some platform-specific bugs were fixed
• Reduced connection time to the servers: for now, you can connect to the server in less than 5 seconds (except time spent on content downloading, if it was required)
• Entities state interpolation fixes: leaded to much more smooth and better multiplayer experience

Recently I found such an interesting piece of hardware at local store - vacuum-fluorescent display (VFD) with 2x20 characters. So I decided to buy two of them for future investigations since they're relatively cheap.

Originally, display distributed with pole and cable. I got rid of pole since I don't need it, anyway you can find how it looks without any problems. Cable has familiar DB9 male connector on one side, but on other side there is some strange connector that vaguely looks like 8P8C, and I've never seen it before anywhere.

This is how display without pole looks like:

Dismantling the display​

Let's try to detach front panel: that can be done with bare hands, you just need to pull front panel both down and away from the display.

This is how front panel looks like on the back side:

Next, you need to remove three screws on both sides:

First thing we see, is that display based on Futaba M202MD10C board. From this information I found out that display more likely uses UART with 9600-8N1 configuration (but also with inverted logic levels). I will test it in future steps.

Determining pinout​

But let's assume that we're at time point when all of needed information is not available yet. Next step we should do is determine display pinout. Probably, since display has only four pins, it shouldn't be that hard. I easily found GND pin and two VCC pins. Therefore, last remaining pin is used for transfer data from microcontroller to display. As a result, we got such scheme:

We got pinout scheme and obviously next step will be applying voltage to display. But what exact voltage we should use? I guess that 5 Volts will not enough. Then I'll try 9 and 12 Volts. As it turned out later, 9 Volts also not enough. But with 12 Volts it worked - display showed underscore at first row.

Connecting display to MCU​

It is time to bring other hardware to this journey - I will use Arduino Uno and try to send some information to display and check what will happen. For this we need pretty simple code snippet:

#include <Arduino.h>
#include <SoftwareSerial.h>

// display DATA should be connected to pin #3, pin #2 will be unused
// "true" as third argument means that logic levels will be inverted
SoftwareSerial softSerial(2, 3, true);

void setup() {
    // sets proper baudrate according to information obtained earlier
    softSerial.begin(9600);

    // send some ASCII text to check is it even works
    softSerial.print("Wake up, Neo...");
}

void loop() {
}

And it worked without any problems!

Conclusion​

This post in theory can be much longer, I didn't covered determining other functions of display protocol, such as controlling cursor position, dimming, etc. But there is nothing interesting it in, really. It's just sending random bytes to serial stream and see what happened. For narrow down the number of possible bytes combinations I checked datasheets for similar displays from Futaba corporation. Also, some russian guy with nickname abomin helps me with code pages and custom character defining feature a lot. And one by one, I determined all things that this display can do.

And result of all this investigations was library for working with Futaba M202MD10C board on Arduino framework. This library exposes in it's API all possible functionality of displays based on this board. Library is well documented and contains bunch of code examples that covers different library functions. Therefore, this shouldn't be a problem to create your own library that works with this display, in case if you want to use display with something else rather than Arduino or just don't want to depends on any kind of frameworks.

After some time I got an idea to make thing like meteostation based on this display. It shows current air temperature, relative humidity, atmospheric pressure & carbon dioxide concentration on display, and periodically sends all of that information to Home Assistant through MQTT. This device based on ESP8266 microcontroller, sensors BME280 and MH-Z14A used inside it. Energy consumption of this device is around 6 Watts, a most of this bugdet used by VFD. This is how this device looks:

What's we have?​

In stock, I had a GoldMaster I-905 TV set-top box, which is completely unremarkable. It has 16 gigabytes of internal memory, 2 gigabytes of RAM. Based on the Allwinner H313 processor. From interfaces: has two USB 2.0 ports, composite video output, HDMI port. Network access can be provided both via Wi-Fi and via an Ethernet port, but I used a wired connection.

Also, we need map compiler sources. For almost 30 years of the existence of the game, quite a few of their variations have appeared: the original compilers from Valve, ZHLT, VHLT, P2ST, etc. I will use the map compilers from my PrimeXT project: they are the most up-to-date at the moment, they will be the easiest to build and run under some exotic platform, unlike all other variations. The game itself, as well as all related utilities, including map compilers, are written in C/C++. PrimeXT uses the CMake build system.

Preparing​

After a short search for information, I found out that in order to build C++ projects straight on Android, I need Termux. It should be downloaded from the F-Droid repository, as the version published on Google Play has been deprecated and is no longer supported.

After installing Termux, just in case, update the installed packages:

pkg upgrade

Now let's install the packages that we actually need:

pkg install cmake git openssh pkg-config ninja

For more convenient work, I decided to run an SSH server on the TV-box and connect to it from my computer. For this I used a KiTTY and WinSCP. Of course, you can use any other software instead. And you can do without an SSH server at all - just write all the necessary commands into Termux manually on the device. But I will use WinSCP for convenient work with files on a remote device.

Now you need to start the SSH server: the procedure is quite trivial. At first, we need to set a password to connect to the server, and then start the corresponding service.

passwd
sshd

After that, you can try to connect from the computer to the server. Please note that Termux uses port 8022 for the SSH server, not the usual 22. You can enter any username, but you need to enter the password specified earlier. If the connection is successful, a shell will be displayed.

Building map compilers​

After completing all the preparatory procedures, you can go directly to the build procedure. The first step is cloning the sources into your home directory:

cd ~
git clone --recursive https://github.com/SNMetamorph/PrimeXT.git
cd PrimeXT

Next, you need to bootstrap vcpkg package manager. You can be warned about missing packages - in this case you need to install them.

export VCPKG_FORCE_SYSTEM_BINARIES=1
external/vcpkg/bootstrap-vcpkg.sh

Then, you need to create and prepare the directory in which the assembly will take place.

cmake -E make_directory ./build
cd build

And now it's time to generate the CMake cache and run the build. Since I'm only interested in map compilers, I disabled building game libraries, launcher, and other unrelated utilities. Also, to make the compilation of the project faster, I will set the build to 4 threads.

cmake .. --preset utils-termux-debug
cmake --build . --parallel 4

After executing the two commands described above, the build process will start.

If the build succeeds, it will look like this. If any errors occur, it is better to restart the build process in one thread, so it will be easier to find out where exactly the compilation error occurred. By the way, on this TV-box, project building with 4 threads tooks about four minutes, taking into account the fact that an IPTV player was running in the background and occupying some of CPU resources.

Compiling map​

For the final step, you need to prepare a working directory that will contain WAD files with textures, a .rad file, and a map source. In my case, this directory will be called gameres.

mkdir ~/gameres
cd ~/gameres

Then, inside this directory, you need to create a gameinfo.txt file with the following content:

basedir ""
gamedir "gameres"

Important tip: in this file, the value of the gamedir parameter must match the name of the working directory. Next, you need to put the used WAD files in the working directory, create a subdirectory called maps inside it, and put the .rad file and the map source in the form of a .map file into this subdirectory.

All the necessary files that I used are available at this link.

Now you can try to compile the map, and all that remains is just wait.

cd ~/PrimeXT/build/Release/primext/devkit
./pxcsg ~/gameres/maps/crossfire_double1_v2.map
./pxbsp ~/gameres/maps/crossfire_double1_v2.bsp
./pxvis ~/gameres/maps/crossfire_double1_v2.bsp
./pxrad ~/gameres/maps/crossfire_double1_v2.bsp

The map compilation process consists of four steps. At the end of each stage, the time spent on it will be displayed. If there are any problems during the compilation of the map, you can look at the log file in the maps subdirectory. Also, you can add the -dev 5 startup option to compilers to display the process in more details.

Checking the results​

After the map successfully compiled on the TV-box, I decided to rebuild the same map on my computer and then compare these two maps. Ideally, there shouldn't be any visible differences. I will test this whole thing in the PrimeXT mod, which is based on the Xash3D FWGS engine.

The engine has a mapstats console command that allows you to display various internal information about the map. For our situation, this is exactly what we need.

Stats of map compiled on TV-box​

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
entities         [variable]       64780/1048576   ( 6.2%) 
planes           2179/65536       43580/1310720   ( 3.3%) 
textures         [variable]        4976/33554432  ( 0.0%) 
vertexes        11219/65535      134628/786420    (17.1%) 
visibility       [variable]      199238/16777216  ( 1.2%) 
nodes            5031/32767      120744/786408    (15.4%) 
texinfo          1383/65535       55320/2621400   ( 2.1%) 
faces            8467/65535      169340/1310700   (12.9%) 
lightmaps        [variable]     1745778/33554432  ( 5.2%) 
clipnodes       12686/32767      101488/262136    (38.7%) 
leafs            3260/32767       91280/917476    ( 9.9%) 
markfaces       11552/65535       23104/131070    (17.6%) 
edges           20150/1048576     80600/4194304   ( 1.9%) 
surfedges       40037/2097152    160148/8388608   ( 1.9%) 
models            142/1024         9088/65536     (13.9%) 
deluxmaps        [variable]     1745778/33554432  ( 5.2%) 
=== Total BSP file data space used: 4.53 Mb ===
World size ( 5120 5824 3920 ) units
Supports transparency world water: No
Lighting: colored
World total leafs: 2318
original name: maps/crossfire_double1_v2_arm.bsp
internal name: desert
map compiler: PrimeXT Tools v.0.90 (Dec 15 2022 / 1397a04 / armv7l / android)
map editor: J.A.C.K. 1.1.2800 (vpHalfLife)

Stats of map compiled on my PC​

Object names  Objects/Maxobjs  Memory / Maxmem  Fullness
------------  ---------------  ---------------  --------
entities         [variable]       64777/1048576   ( 6.2%) 
planes           2179/65536       43580/1310720   ( 3.3%) 
textures         [variable]        4976/33554432  ( 0.0%) 
vertexes        11210/65535      134520/786420    (17.1%) 
visibility       [variable]      198643/16777216  ( 1.2%) 
nodes            5031/32767      120744/786408    (15.4%) 
texinfo          1383/65535       55320/2621400   ( 2.1%) 
faces            8465/65535      169300/1310700   (12.9%) 
lightmaps        [variable]     1744599/33554432  ( 5.2%) 
clipnodes       12747/32767      101976/262136    (38.9%) 
leafs            3258/32767       91224/917476    ( 9.9%) 
markfaces       11512/65535       23024/131070    (17.6%) 
edges           20138/1048576     80552/4194304   ( 1.9%) 
surfedges       40013/2097152    160052/8388608   ( 1.9%) 
models            142/1024         9088/65536     (13.9%) 
deluxmaps        [variable]     1744599/33554432  ( 5.2%) 
=== Total BSP file data space used: 4.53 Mb ===
World size ( 5120 5824 3920 ) units
Supports transparency world water: No
Lighting: colored
World total leafs: 2316
original name: maps/crossfire_double1_v2.bsp
internal name: desert
map compiler: PrimeXT Tools v.0.90 (Dec 16 2022 / 1397a04 / amd64 / win32)
map editor: J.A.C.K. 1.1.2800 (vpHalfLife)

As you can see, there are still minimal differences in stats. It is difficult to say what exactly is the reason for these differences, but most likely they are completely uncritical. Next, it makes sense to compare if there are any visual differences on the map itself.

Screenshots of map compiled on my PC​

Screenshots of map compiled on TV-box​

Personally, I didn’t notice any visual differences in lighting or geometry at all, which of course is good. The experiment can be considered successful.

Resume​

Using the procedures described above, it is quite possible to compile maps for Half-Life 1 on almost any device that is based on the Android or Linux OS. Unless, on too large and detailed maps, the device may not have enough RAM for compiling.

Despite the fact that all this was not initially intended as something useful, it is possible to find some use cases: for example, if for some reason you don’t want to load the PC, or there are no devices other than a smartphone at all (unfortunately it's pretty common nowadays, PCs stand back in favour of smartphones), but you need to compile the map somehow.