Comment by ryandrake
8 years ago
> Three weeks after I sent him development hardware (an iMac) he informed me that the PC and Mac versions of Quake III Arena were in “feature parity.” I still recall my shock upon reading that email from him.
Weird how “writing portable software” was (and in many places still is) considered deep wizardry. I remember the timeframe described here and indeed “porting our software to a non-Windows platform” was on every company’s list of things they’ll never have time to do, because everyone’s code base was so thoroughly (often unnecessarily) tied to Win32. The bad ol days...
It's a bit easier in a game that renders its whole UI custom, though. A standard desktop app would be heavily tied to Win32 simply because of UI controls. Similarly, a server app, if designed for performance, would likely be using overlapped I/O.
Yea I should have qualified that I was mostly talking about games companies. Games should be among the easiest software to release on multiple platforms for to not needing platform specific UI controls. Actually I struggle to think of a single major component to a game that must be platform-specific. Yet, of all the software I use, games tend to be the ones stubbornly stuck on Windows.
If this story inspires you at all to troll old John Carmack .plan files and interviews, I believe you'll discover that id software stopped doing Linux versions of their games for reasons that had little to do with the technical difficulty of porting.
> Actually I struggle to think of a single major component to a game that must be platform-specific.
Different platforms often have totally different graphics APIs. Even when platforms share APIs, driver quality, compliance, and fast paths vary greatly. The Mac still used a completely different processor architecture from the PC at the time of this story, requiring platform-specific optimizations and approaches.
Games, particularly cutting edge ones that demand performance, and especially from that era, are much more likely to need to be tailored to their platforms.
1 reply →
To be fair if you’re doing all your own UI it’s a bit easier. Porting a bunch of Win32 GUI to Carbon/Cocoa would be a big deal.
But I agree. I remember being impressed at seeing boxed Linux copies day one.
Yet today we can still wait YEARS for Mac ports of games, if we get them at all, even though they’re using a cross platform engine.
The Linux edition of Q3A also — remarkably — came in a collector's tin, which I severely regret not buying at the time.
That was the box that lasted the longest at my local computer store, long after almost all other boxed Linux software disappeared.
By committing to making the software portable to, and available on, other platforms, you are also committing your company to incur the testing and support costs for each platform. Many of these costs are fixed, so the more obscure the platform, the bigger proportion of your revenues on that platform will be eaten up in costs.
For this reason, from a business perspective, it makes sense to write games only for Windows. Anything else is bad business.
This is a great argument against releasing (or more specifically, offering support) for multiple platforms, but not an argument for writing your software non-portable in the first place. I’ve worked on projects that technically could have easily been recompiled and released on multiple platforms but were not, for valid business reason.
> Weird how “writing portable software” was (and in many places still is) considered deep wizardry
Well, at this time most code had OS-specific hacks for performance reasons…