Xash3D: An open-source reimplementation of Half-Life | Hacker News Reader

Xash3D: An open-source reimplementation of Half-Life

github.com

176 pointsmepian68 comments

FYI: Half-Life is currently free on Steam: https://store.steampowered.com/app/70/HalfLife/

Your IDOR link made me curious and it appears that /10 is the lowest they serve: https://store.steampowered.com/app/10/CounterStrike/

There are lower, but I think Counter-Strike is lowest commercial product

https://developer.valvesoftware.com/wiki/Steam_Application_I...

That's the point. Now that you can get HL assets for free, open source implementations will be usable by everyone.

I am able to play hl1, blue shift, and opfor as well as CS on the ps vita due to an android wrapper of this engine. It is great except the save/load times are very long (30-60 seconds) and the levels have many load triggers.

https://github.com/FWGS/xash3d-fwgs/blob/master/Documentatio...

I have a port of this running on my 3ds. Terrible load times, amazing performance considering the hardware. Pretty funny.

is it a new 3ds?

Nope, non-xl o3ds

I always enjoy seeing games running on platforms never intended and especially not even invented at the time, but sometimes I think we forget how powerful computers weren't back then.

Didn't Half Life require a Pentium (as in the first one) and something like 32 MB RAM when it came out?

I think the 3DS should be at least that powerful, or is there something I'm missing?

Xash3D isn't the engine of the 90s, despite it allows to run the game from this era.

The fact that it actually works in such constrained environments is impressive.

We ran our FWGS fork with our own software renderer on Chinese MP3 player and Motorola Linux phone from the mid-00s just for fun. But these ports are total hacks. :)

I think you're right. The 3ds is definitely over minimum spec now that I think about it, especially given that it has a dedicated GPU

This is a good point. I had no idea its hardware requirements were that low.

I wish these ports were upstreamed, so they could leverage optimisations that could be found in latest development branch.

At this time, only nswitch and psvita are upstreamed, but both tend to get broken over time, mostly due to breakage in homebrew SDKs.

Hoping this would bear fruit for macOS, but looks like the maintainer instead has written a mini anti-Apple screed and intentionally doesn't support it. https://github.com/FWGS/xash3d-fwgs/issues/61

I mean, yes it's somewhat anti-Apple. But their justifications aren't really wrong.

Reading through the thread, the dev stance honestly seems pretty reasonable.

He initially supported it, but Apple kept making changes that caused trouble. Since the devs don’t have Apple devices and have no personal interest supporting the platform, they cut “support”.

They continually invite anyone that wants to come onboard to support it on Apple if they want to.

Your post (to me) initially reads as seeming like they are actively blocking Apple support out of ideology, but that’s not the case. They even seem to occasionally entertain possible ways to add compatibility without extra effort.

Microsoft is also increasingly causing them problems, with the antivirus and software signing needed to ensure getting past it.

He personally doesn't have time or motivation or desire to buy a Mac just to support it, but he also won't reject pull requests from others to add MacOS support.

Mac Source Ports has a macOS version of this, including Apple Silicon support. Played it recently and it works very well despite a couple of annoyances.

Mac Source Ports is fantastic overall, there’s a ton of other games available too.

http://www.macsourceports.com/game/halflife

Thanks! I had not seen this. Am I missing something, or is his actual build not open source?

edit: Here it is. This looks like a good place to work from: https://github.com/MacSourcePorts/xash3d-fwgs

Looks like the main annoyance is no resolution scaling; the game always renders at the size of the window, which at high pixel densities is a problem for the text rendering (it's tiny). Should be solvable for someone motivated though.

Maintainer here.

We have upstream support for macOS now, since there is at least one person ready to work on it.

Well, thankfully, it doesn't require too much work, except some Apple specifics. If someone could set up a CI build, that would be awesome.

I personally didn't have an overall problem compiling the project on macOS in the past. The only issue I ran into was not being able to get VGUI to work, so there were no HUD in-game. Last I did this was ~6 months ago, though, so it could be things have improved now.

VGUI usually isn't used for HUD drawing.

If you have problems, better report them at our issue tracker on GitHub. Even if it was unsupported configuration, there might be somebody who knows how to fix this exact issue.

I guess it is your time to shine then. Open source is a two-way street.

> mini anti-Apple screed

It's not the developer's fault that Apple forces them to bend over backwards and continuously update and rewrite huge chunks of their software just to make sure it doesn't get broken by every other macOS update changing or removing some essential API or feature that every other OS still supports.

The simple fact that OpenGL and Vulkan are supported on Windows, Linux and Android, but not macOS, which only supports a single proprietary graphics API that everyone is forced to use, should be enough of a reason for game developers to stay far away from it, and indeed, most do. Valve themselves have decided to distance themselves from macOS in recent years due to Apple's behavior despite openly embracing it in the past. If you're going to buy a Mac expecting to game on it, you should take this into consideration.

That doesn't read like a "screed" to me. That's a pretty reasonable justification and it's probably not worth the effort to support a toolchain to target Metal for a platform that isn't often used for gaming in the first place.

It reads like "a screed" due to the way they write with unnecessary vitriol.

Their reasons are definitely understandable though.

> unnecessary vitriol.

The vitriol is very necessary to communicate that such actions are disliked.

No, it's really not. ;P

Their reasons for disliking the Apple ecosystem are fine, it just doesn't need the tone. It's like reading something from /. circa the mid 2000s - most of us have grown up since then.

> it just doesn't need the tone

IMO it does, people aren't machines and they both tend to produce and respond to strongly worded criticism.

> It's like reading something from /. circa the mid 2000s - most of us have grown up since then.

New humans are created all the time, the people who disliked at what big companies were doing back in 2000s - and being vocal about it in the social platforms of the time - growing complacent in 2020s doesn't mean everyone else has to do the same.

I don't think anyone is trying to go to bat for Apple's graphics API policies in this thread or are corporate shills. I originally described it as a screed because of the tone, profanity, several factual inaccuracies, as well as the cutting and derogatory comments by the maintainer further down in the thread that I found unwarranted.

Sorry, it happens. :)

I use an Apple device, but I also agree with this guy. "Fuck Apple". His rant was funny and accurate. But oh no... he hurt Apple's feelings. A fucking three trillion dollar company is going to cry itself to sleep tonight because of his mean hurtful rant on GitHub.

You're welcome to your opinion, but I contend that your opinion is part of the problem in open source. Maturity is necessary - it's not "growing complacent" to realize there are better ways to express yourself in 2020+.

Please show us these better ways, oh master, that we may follow you.

> there are better ways to express yourself in 2020+

Tone policing is still lame in 2020+

https://en.wikipedia.org/wiki/Tone_policing

Tone policing is one of this forum's foundational rules. You're going to have a bad time here if you don't understand the utility of putting in the effort to have more civil discussions.

Tone Policing is a type of ad hominem logical fallacy, as explained in the article.

If committing ad hominem logical fallacies is one of the rules of the forum, then this forum is a waste of time.

This thread has already been a complete waste of time.

> Maturity is necessary [..] better ways to express yourself in 2020+.

Well, part of my opinion is that i disagree that trying to force a specific tone is a sign of maturity and i do not see that as a better way of expression.

It can be easier to stomach, especially to those who do not want to see the opinions discussed, but at last personally i do not consider that as better.

Gotta say, being passive aggressive is a bad look (or should I say bad tone). It's how children and socialy maladjusted people communicate.

Here's my anti Apple Rant.

I got an email the other day, that despite me paying my 100$ a year fee, my hobbyist game would be removed unless I update it.

This is after the pure hell of getting my developer account working and getting the app approved in the first place. The email didn't say it's not running properly on iPhones anymore. Just I need to waste my time updating this app.

I immediately canceled my developer subscription. Google is starting to crack down on hobbyist projects as well.

Whatever, Unity Web builds are fast enough on mobile browsers.

I'll upload the game to itch.io, if anyone wants to play it, they can do it there.

Apple doesn't bother to support standardized tech like Vulkan, and generally makes like difficult.

As far as my hobbyist projects go I'm moving away from proprietary software, and moving towards open source GitHub projects. I code outside of work for fun. Once I need to jump though 800 hoops to get my project to end users I lose motivation.

>I got an email the other day, that despite me paying my 100$ a year fee, my hobbyist game would be removed unless I update it.

Isn't this the same on Google play? I got a similar email around August time saying end of August is the cutoff date for upgrading to Android 13.if I don't upgrade my app they'll take it down. What's the difference?

Why does there have to be a difference?

I don't think they need to pay 100 per year on Google play

Correct.

I paid a 20$ fee once years ago.

You have to rebuild for the latest SDK version; sounds like you have some deprecated code that won't be supported. Stop playing the victim - Apple won't allow apps that won't run to be on the store.

Then it's an issue with Apple's platform.

Old Steam games still run after all.

Apple removed OpenGL support that his project depends on while he was working on it. Developers were unhappy with Apple _explicitly choosing_ not to allocate resources to maintaining a widely used open source graphics backend, because it means a lot of open source code floating around will not work without a lot of extra effort.

I suspect that you fundamentally do not understand the issue since you're characterizing the developer not putting in that extra work as "intentionally not supporting Apple".

Anyone tried the Linux version on Apple hw?

Managed to get this compiled and running on my M1 MBA pretty quickly, although a bit tricky.

For reference to those who might attempt, I had to swap 'python' for 'python3' in the header of the waf binary, patch one file to replace 'malloc.h' with 'stdlib.h" to overcome the one compile error, compile the hlsdk-portable library referenced in the README (again with waf tweaked), and copy both the resulting dlls/hl_arm64.dylib and cl_dll/client_arm64.dylib into the valve folder.

FYI this is the base for running CS 1.6 in browser: https://play-cs.com/en/credits

Xash3D was used by marty to port HL1 to the original Xbox [0].

[0] https://github.com/brentdc-nz/Half-LifeX

Anybody have quick take on why this fork was needed? Since Xash3D was also for Half Life, why did they need to fork to Xash3D-FWGS.

Not complaining, just sometimes I think open source looses ground by having too many forks, which dilutes man-power on these efforts.

."Xash3D FWGS is a heavily modified fork of an original Xash3D Engine by Unkle Mike."

Original Xash3D is only developed for Windows.

Initially fork was done to port all the Windows-specific code to SDL, but since then the goals has changed on improving compatibility and extending it further for modders.

I created Half-Life Engine JS wrapping a Wasm port of Xash3D in a clean JS module: https://hl-engine-js.steren.fr/

I wish Wasm was officially supported by Xash3D.

Weird, I get an error:

> Exception thrown: TypeError: params.args is undefined

Yes, I should put a better error message. You need to load the game files, which aren't serve from my website.

If you want to see an example with my own maps, see https://minfantry.steren.fr/

It happened when I did load the game files, I had to patch out this line to remove the second set of args:

    Module.arguments = [...args, ...params.args];

Then, it did work! :D

There is also this amazing fork [0] that brings xash3D to standalone VR headsets, complete with 6dof controls, etc.

[0] https://www.lambda1vr.com/

It uses the Valve SDK. Why no one tried to extend/fork Quakespasm or Darkplaces?

There is FreeHL, a clean room implementation of HL1 game logic on top of FTEQW. It's pretty impressive project.

Can we do this for Starcraft?

http://www.openbw.com

Thanks, looks like another corpse project though.

~~Wasn't this created from stolen/leaked code?~~

Edit: nvm, I was thinking of the HL2 leak

You’re probably thinking of the HL2 engine, which was leaked in ~2003.

You're right!

No, the leaked code wasn't involved, it's all reverse-engineering and Quake's open source code where applicable afaik.

Unfortunately, it was by original Xash3D author. In FWGS we do not take any leaked code, but we also do not tend to do clean room implementations, since it's easier to work with decompiled code.

And license-wise it would be very hard to get rid of the fact that Uncle Mike used some stolen code.

Reply on news.ycombinator.com