I've seen some people manage to get it working on Mac by following this Steam guide from one of the devs:
But it seems pretty finicky about which models it decides to work with and which it does not.
Last active
May 14, 2020 04:38
-
-
Save amcgregor/f3600927879d78196f60920afa7934af to your computer and use it in GitHub Desktop.
A reply to a thread asking for macOS platform support, where the game developer has used the ever classic "it's a custom engine" excuse. https://steamcommunity.com/app/410900/discussions/5/2270319981527105014/#c2271447149952963988
Forts uses a custom game engine. It's not a simple task for a small team to port, test and maintain it for a different platform that it was not designed for from the start.
"Custom game engine" is hand-wavy BS to get people to stop asking. Every time I get notified this game is on sale I check for Mac compatibility. It's become a ritual of mine. Every time anything goes on sale and still isn't, after years, but is offering all kinds of cosmetic or flu-flu extras (trading cards, was it, in this latest one?) … my level of unimpressed grows.
There are a handful of languages. C# or any other .NET-backed system is portable to anywhere, like Microsoft promised when inventing .NET, because it's a portable bytecode based runtime. (There's a reason Unity ran with it.) You can use Microsoft's, or Mono for an open-source alternative. Almost everything else boils down to C or the C-ABI, which requires an architecture flag change and a recompile, especially if you're using anything like SDL at the lowest layer.
There are essentially three graphics driver APIs. Direct3D, Vulkan (OpenGL), and Metal. Direct3D has compatibility via Wine's efforts (which can translate Direct3D into OpenGL calls), OpenGL is universal. ❤️ Id games' support for standards—and multiple platforms—since the beginning. See also: UT2K4, for another example of a grossly multi-platform OpenGL success case. ❤️ any games company using standards. EVE Online almost gets a pass, as they do try very, very hard to make their Wine setup stable, which surprises me, given EVE is written in Python, another bytecode based runtime. It's only so effective, but they try so very hard!
I no longer buy games hoping to support the developer while I wait for them to support my platform. Years ago I realized how stupid that was. Now they get my coin only when they provide the support. I don't entirely blame the developers for this; Mac slighting is systematic. Half the games I have installed and play, Steam swears up and down aren't supported by my platform. Despite being able to double click and launch them, they still have that little slashed O next to their names. Steam/Valve don't have a clue, I've ceased expecting anyone else to.
Edited to add: https://github.com/LukasBanana/LLGL#platform-support is an example where everything is supported simultaneously; may be possible to derive some inspiration from this, hopefully. (Fun anecdotal fact: Halo was originally written for Macintosh. I still have that version. Blood Gulch that chunky brings back such memories, but that's a hilarious example where multi-platform support was removed as a political measure, to spite Apple directly and for literally no other reason.)
It's not "hand-wavy". Forts was written in C/C++, Lua and OpenGL from scratch only for Windows. We don't use SDL. There's lots of Windows specific code. There's no simple flag change.
I'm not saying it's impossible. I'm saying for a team of four, with only one full time programmer (me) and the other part time, that it's currently not worth all the work, headaches and ongoing support of targeting two platforms, when Mac only has a few percent* of the desktop games market.
An additional problem is that the difference of compiler would likely render the game's multiplayer incompatible between Windows and Mac. This has obvious disadvantages for Mac players and would require a separate or (due to low player numbers) disabled ranked competition. As it stands, when Forts is run through Wine or Proton, players on Mac and Linux can battle with those on Windows.
Continue to have excuses as most developers do. (If "endianness" is the compiler difference mentioned making network play incompatible… SMH.) Catch-22, chicken/egg, it never will except to those willing to go to the effort of hacking compatibility systems into shape such as Wine; put thousands of hours into Skyrim using it, and everything Valve before they brought native support. Does anyone even remember these ancient UI designs? Also: at hundreds of FPS on a white MacBook.
Regardless, you're fully entitled to do what you will with what you perceive as current market forces impacting your business. On the other hand, and I mean nothing malicious by this—it's capitalism; removed from wishlist, hope eliminated, I'll spend my money on games (and developers) who do care to spend the effort. Which is honestly most, at this point, especially of indy developers.
RimWorld, Crying Suns, … most of the recent games, and even not-so-recent, GSB ("hard-ish" simulation), Chicken Horse + Stick Fight (multiplayer), Space Base DF-9, ShellShock (multiplayer + "custom engine"), Jupiter Hell (very "custom engine"), Endless Sky (…), &c., &c., I've desired to play all work great. I'd say "at least I have options", but since the introduction of the original Macintosh, I always have had: Armor Alley (now that is a multi-platform success story! Back before the concept of graphics API standardization, or even discrete GPUs…), Glypha, Spin Doctor, Tempest… Ambrosia SW's entire catalog… ABUSE, Marathon, and more cross-platform multiplayer: UT as mentioned, StarCraft/WC3, Halo as also pointed out… Edited to add, how could I forget the multiplayer FPS anime-inspired joy that was Shogo: Mobile Armor Division? Sid Meyer's Alpha Centauri? American McGee's Alice? … Always seemed weird to me that people can somehow end up thinking Macs "don't game".
If it were only an endian issue then it could possibly be solved. The issue is that different compilers generally produce different results from floating point arithmetic.
We do care. We've been providing free updates for 3 years now, and I answer support queries at all hours. There are limits, however. We also care about our families and quality of life. I'm sorry we can't help you right now.
The issue is that different compilers generally produce different results from floating point arithmetic.
"man gcc" says it all: -ffloat-store to avoid issues of excess precision (beyond IEEE 754 64-bit double-precision, i.e. the 80-bit precision on x86/x87) due to use of registers for value storage and other optimizations. Note also that VS's /fp:fast violates the specification as well. (Related, but disabled by default: GCC's -ffast-math which may similarly result in "incorrect output".) Best practice, though, utilize SSE(2) which avoids extra-precision temporaries. (XMM registers are actually 32- or 64-bit IEEE, unlike x87, which are 80, but rounds on transfers to memory, GPU computations being immune to this
particular issue.) -mfpmath=sse -msse2 -ffp-contract=off
We do care. We've been providing free updates for 3 years now, and I answer support queries at all hours.
Kudos for that, for sure.
There are limits, however. We also care about our families and quality of life. I'm sorry we can't help you right now.
I'm somewhat sorry, too. May have come over overly hostile, however, as you say, there are limits.
One does tire of seeing excellent work one can never enjoy. And having that fact lorded over consumers using the platform as a deficit of the platform, and not the developers unwilling to support it.
Root cause analysis and whatnot.
Edited to correct formatting and add a missing link; apologies about that. Silly lack of inline code snippets.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment