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.
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. :)
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
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.
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.
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.
>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?
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".
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.
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.
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.
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.
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.
Readit News
https://developer.valvesoftware.com/wiki/Steam_Application_I...
https://github.com/FWGS/xash3d-fwgs/blob/master/Documentatio...
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?
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. :)
At this time, only nswitch and psvita are upstreamed, but both tend to get broken over time, mostly due to breakage in homebrew SDKs.
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.
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.
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?
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".
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.
Their reasons are definitely understandable though.
Mac Source Ports is fantastic overall, there’s a ton of other games available too.
http://www.macsourceports.com/game/halflife
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.
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.
[0] https://github.com/brentdc-nz/Half-LifeX
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."
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 wish Wasm was officially supported by Xash3D.
> Exception thrown: TypeError: params.args is undefined
If you want to see an example with my own maps, see https://minfantry.steren.fr/