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.
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.
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.
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+.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
