Big endian support for BSP loader

[Xav101]

This set of patches seems like it's enough to get the game loading BSPs on big endian platforms. Tested on big endian mips-irix using half life 1 maps. This does not have support for extra lumps and doesn't support the QBSP2 files.

I probably missed something in here because there's quite a few fields in a BSP so please let me know if you notice anything.

[a1batross]

Spaces in parentheses. :)
It's fine to not have them in type casts and between consequent parentheses, but they should be everywhere else:
For example:

(T *)(expr + (expression2 * n))

should be formatted as:

(T *)( expr + ( expression2 * n ))

Sorry, don't have clang-format for this yet, but we probably will migrate to something similar later.

[a1batross]

I suggest you to change this:

uint32_t version;

version = LittleLong( *(uint *)buf );

So you don't have to add macro calls to every version check.

[a1batross]

You're potentially writing to const here. While this memory isn't read-only, I'm not sure if it's a good solution here. I think we can remove const modifier from BSP model loader for now.

Also, you can use static inline instead of _inline. Or even just static, since most compilers do ignore inline keyword.

_inline is a legacy macro definition I forgot about, it's almost not used in new code.

[a1batross]

You may completely remove this check. Compiler will optimize out a loop that does nothing on little endian.

Also, if you didn't know, platform macros are defined into positive values in build.h, so they can be checked with just #if and used in complex expressions without defined() usage.

[a1batross]

Same as above. You can just use simple and readable #if XASH_IRIX && __GNUC__.

[a1batross]

Also, your RTC battery seems worn out!

Xav101 added 14 commits 25 years ago

Though I don't care about commit date to be honest. But you still better rewrite the commits because the commit messages must be in a specific format:

tag: subtag: more subtags: short summary

long summary, if needed

You can easily rewrite commits using git rebase -i for example.

[SNMetamorph]

Looks like this guy completely lost somewhere. Maybe we should complete this PR ourselves? It isn't complex nor massive, that shouldn't be a problem.

The only problem is we couldn't test it on Irix. So, maybe he'll come back and do it himself, or somebody else who have Irix hardware will do it for us.

п.с. а может быть спросить у Бачило, может он бы согласился помочь с этим? :)

[Xav101]

Sorry, I just noticed this update in my inbox.

Unfortunately these days I'm fairly busy and have a lot less free time than I used to. I would like to work on the project but it just doesn't fit into my schedule. I still have all of my SGI hardware as well as my development environment, so if there's a specific thing that needs testing I can probably spin it up for a weekend to help out. Unfortunately my main IRIX system has some strange boot issues right now but they should be fairly easy to resolve if need be, or I could pull out a different machine.

[Link4Electronics]

Looks like this guy completely lost somewhere. Maybe we should complete this PR ourselves? It isn't complex nor massive, that shouldn't be a problem.

The only problem is we couldn't test it on Irix. So, maybe he'll come back and do it himself, or somebody else who have Irix hardware will do it for us.

п.с. а может быть спросить у Бачило, может он бы согласился помочь с этим? :)

Hello,

I don't have a mips-irix system, but I do have a PowerMac G5 which is big endian PPC64 and running linux, unfortunately don't know how to program but I can compile and test on it.

Best regards,
Link.

[SNMetamorph]

@Link4Electronics yeah, that will be pretty good if you will test this PR on your machine

[Link4Electronics]

I'm having this issues:

In file included from ../public/crtlib.h:24,
                 from ../public/dllhelpers.c:15:
../common/xash3d_types.h:188:8: error: expected ‘;’ before ‘float’
  188 | _inline float LittleFloat( float f )
      |        ^~~~~~
      |        ;
../common/xash3d_types.h:188:15: warning: no previous prototype for ‘LittleFloat’ [-Wmissing-prototypes]
  188 | _inline float LittleFloat( float f )
      |               ^~~~~~~~~~~

Waf: Leaving directory `/xash3d-fwgs/build'
Build failed
 -> task in 'public' failed with exit status 1 (run with -v to display more information)

I tried to adapt the PR like this be.patch since there were changes to some variables like loadmodel became mod on recent changes

Gonna try to compile Xav101:irix-port-wadfix branch later to see what happens.

Best regards,
Link.

[Xav101]

I started looking back into this and trying to fix some of the commit messages. I will need to try and merge the upstream into my local tree which may take a little while.

[Link4Electronics]

Compiled this fork: https://github.com/IntriguingTiles/xash3d-fwgs/tree/big-endian which is only 100commits behind

It's missing the first guard knocking at door, there's only a fluctuating lantern. The other actors from the other train car are all flying everywhere very fast. When it's about to do the first Loading, crashes.

Best regards,
Link.

[a1batross]

Got myself Mac Mini from 2005 with PowerPC G4 CPU clocked at 1.25 GHz with 512 MB of RAM.

I hope it will help me to test big endian support and finally merge this.

[Link4Electronics]

Congratulations on your aquisition, I have one and I like it. If you don't mind me ask, which OS are you using on it? Reason I ask is because OS X Tiger only has OpenGL 1.x, OS X Leopard exposes OpenGL 2.x. Linux iirc GL 1.3 or 1.4 with Radeon 9200, or 4.5 with llvmpipe but is gonna be extremely slow.

@Doctorj128

Best regards,
Link.

[a1batross]

@Link4Electronics for now it's 10.4.11. Xash should be fine with OpenGL 1.x.

[Cowcat5150]

Guys, the IntriguingTiles changes basically fixes 95% of the big-endian issues. Apply them and tribute him.
The MorphOS platform has its own port since three months ago thanks to those changes.

[SNMetamorph]

@Cowcat5150 thanks for information, I guess you meant this: https://github.com/IntriguingTiles/xash3d-fwgs/commits/big-endian/

[Cowcat5150]

@SNMetamorph Correct.

My port: https://www.youtube.com/watch?v=bN1brvRKiEo&t=103s

[a1batross]

Guys, the IntriguingTiles changes basically fixes 95% of the big-endian issues. Apply them and tribute him. The MorphOS platform has its own port since three months ago thanks to those changes.

why not tag them here then @IntriguingTiles

[IntriguingTiles]

Hi! I've been meaning to work on making my changes upstreamable, but I got distracted by other stuff. My port is fully functional to my knowledge (except for cross-endian multiplayer). I also got it working on Mac OS X 10.4.

[Link4Electronics]

For powerpc 64-bit (power mac g5) it does have small issues, the actors they all fly everywhere like a g-mod game and crashes, and like the screenshot I posted, missing the first guard. Probably a swap or a pointer somewhere.

Regards,

Link,

[Xav101]

Wow, this is great progress!

I think moving forward with the patches from @IntriguingTiles is probably best because at this point despite my best efforts every step of trying to merge the git tree has been a process. I don't have a ton of git experience since I work in a different field and so I haven't been able to make much process. His patchset also seems to be far further along than I had previously managed to get so I would say it's probably best to start from there.

There might be a few tweaks from my initial patchset that need to be merged in eventually because iirc not all of them were strictly big endian related, some of them were to work around a few issues to get the server to compile (like the patch to redefine isnan on IRIX to __builtin_isnan). Generally speaking our GCC port works fairly well but there are a few random issues here or there mostly due to various bugs in IRIX itself and things that weren't fully tested (they had a roadmap planned out for future hardware and future OS versions, but all of that was pretty much cancelled when they went bankrupt in 2006). Additionally I also had some patches at one point for the hlsdk build system that I never got around to PRing, but they were pretty much the same as the patches to properly support compiling Xash on IRIX. So mostly minor.

The good news is that I also just got my main SGI development machine back together, and I've added a 3rd node to it so it now has 12 CPUs, and I've also got an Octane2 set up at my desk now that I have a bit more room.

[Cowcat5150]

@Link4Electronics Models doing weird shit maybe are due to math or/and hlsdk missing big-endian changes.

[mittorn]

Cross-endian multiplayer worked in old engine, first BE port was dedicated server only. Maybe need port some network code changes 9 ноября 2025 г. 2:06:38 GMT+03:00, IntriguingTiles ***@***.***> пишет:

…

IntriguingTiles left a comment (FWGS/xash3d-fwgs#1466) Hi! I've been meaning to work on making my changes upstreamable, but I got distracted by other stuff. My port is fully functional to my knowledge (except for cross-endian multiplayer). I also got it working on Mac OS X 10.4. <img width="1024" height="768" alt="Picture_7" src="https://github.com/user-attachments/assets/e44e547b-25f3-4f5d-94a4-0083c2676fbf" />

[Link4Electronics]

I compiled this fork https://github.com/IntriguingTiles/hlsdk-portable/tree/big-endian and game works flawless on PPC64, the physics issues are no more, wasn't aware about this fork of hlsdk libraries.

Regards,
Link.

[Xav101]

Yeah I managed to get that and the other big endian branch tested on IRIX. However because it has been several months since that branch of the engine was in sync with the upstream master, I put in some work to get them caught up as there were a number of changes in upstream that conflicted with that fork. I have a branch at https://github.com/Xav101/xash3d-fwgs/tree/working-12112025-2 which was working as of 12-11-2025 but I went on vacation and haven't had a chance to merge commits in the last few weeks while I was out of town.

There do appear to still be a few bugs with the port:

• Barney for some reason disappears after he lets you off the tram, meaning that he never unlocks the door to let you enter the facility
• The GMan appears on your tram near the end of Black Mesa Inbound. He just kind of floats there.
• At one point while playing through Unforseen Consequences, the game hit a massive lag spike where some things seemingly stopped working. I don't know what the exact cause of this was and haven't tried to reproduce it yet.

[Cowcat5150]

@Xav101 Deleted my notes.

What I'm not sure is what was done previously on xash3d for the little endian macros that went from signed to unsigned. That is not what works for my ports.

Now I see you already reverted it. Anyways, the issue of floating models is due to endianess in math code/macros and that is what I saw when I was applying Intriguing Tiles changes piece by piece till it worked.

[Xav101]

Yeah I did pretty much the same thing, except with also putting the upstream patches into my branch. I've tested after pretty much every stage and I can say that these edge case issues were present even when I got both the xash3d and hlsdk big-endian patchsets building on IRIX without any additional upstream patches.

Additionally, there's a 3rd bug that I forgot to mention - when you go through a level transition, the game camera seems to snap upwards.

At this point I think there's likely one of two causes:

1. It's a missing byteswap in an uncommonly exercised code path that only gets triggered in those specific instances.

2. It's a bug that somehow I managed to introduce in my unaligned access handlers.

MIPS requires memory alignment but IRIX makes no attempt to trap and emulate unaligned memory accesses in the way other platforms do. MacOS on PowerPC will, which is why this hasn't been an issue yet. So ontop of the big endian patches I also wrote some macros to perform unaligned access handling. These mostly get used in the model code it seems for some of the animation stuff.

@Cowcat5150 would it be possible for you to build my big endian branches to test that they still work normally on PowerPC MacOS? I don't have any Powermac systems so it's kind of hard for me to test. If the build doesn't encounter any of the issues I mentioned, could you try a debug build but manually add MacOS to the macros so that it uses the unaligned access handlers? That would help me narrow down what is causing this.

Current xash development branch: https://github.com/Xav101/xash3d-fwgs/tree/working-12112025-2
Current hlsdk development branch: https://github.com/Xav101/hlsdk-portable/tree/working-11302025

[Cowcat5150]

@Xav101 Maybe later I can test your branch but my ports are for MorphOS and Amiga Warpos (ppc for Classic) not old MacOS.

Off the top of my head in my ports (basically build from June 2025 sources and partially upgraded till december 2025):

• All the endian macros are signed for both xash3d and hlsdk, except for the sprite include (xash3d/engine/sprite.h) where the long/int32 macro seemed to have a conflict at compile time and that is unsigned.

• For the Amiga port, hlsdk needed unaligned treatment in one of the functions at /dlls/utils.cpp "EntvarsKeyvalue" because some maps crashed when loading ( check the Dreamcast port for it ). Still some issues with one of the later levels in some particular places that have random crashes. Eventually you can finish the game.

Note: I found that the bigendian changes done for libmenu dll aren´t needed as all the conversions are already done in xash3d. Both of my ports are built that way.

[Cowcat5150]

@Xav101

Tested your branches:

Xash3d with or without alignment code seems to work good combined with my hlsdk dlls but with "aligned hlsdk" what is saved has the structure wrong ( characters go in dumb mode, map is not what it was before, etc ).
Bear in mind I don't use "dladdr" function for saving/loading those structures because is not available in my systems and I use save_restore_offset code that is still there (only in libxash dll). Don't know if could affect the test.

At least your branches forced me to finally integrate my changes to mostly updated main github so all my comments above are dated now as all happens to be correct. Still testing anyway.