5 ms·
Not to be a jerk but... why? At a certain point none of your customers are running 32 bit hardware, so which parts of your toolchain/dependency tree are so anci
by unlinked_dll 7y ago
Not to be a jerk but... why? At a certain point none of your customers are running 32 bit hardware, so which parts of your toolchain/dependency tree are so ancient or difficult to alter that you remain compiling to 32 bit?
And while you're right it was deprecated immediately, I do recall universal binaries were soft and then hard deprecated some years ago but I could tell you the exact date. I know there's a lot of vintage software that would never be updated, but like, a good chunk of stuff seems to have been new development or continued support.
- Jasper_ 7y agoBecause no serious game developer expects a platform vendor to pull the rug out from under them. What benefit is there to an up-to-date port, especially when very few people already buy games on Mac? Most of these port projects were done 10 years ago, when Steam on Mac first released.
- pjmlp 7y agoExcept that has happened multiple times across the industry's history, specially on the consoles, it is a know business factor to take into account.
- Wowfunhappy 7y agoConsole generations are a known quantity for both developers and consumers. A lot of people keep their old consoles around when they buy a new one. You will never see Sony release a PS4 update that drops support for 2013-era PS4 games, at least not purposefully. If they did, people would be very mad.
- pjmlp 7y agoGame consoles come and go, e.g. Saturn, Jaguar. I did saw Sony drop the almost unused GL ES support on the PS 2.
- Jasper_ 7y agoSure, but you're missing that it's worth the effort to maintain. Console platform sales are extremely healthy. Mac sales have never really been enough to support initial porting work, let alone continued investment.
- Wowfunhappy 7y agoI'm not a game developer, so I can't really answer your question. But it's worth noting that most of these games are 32 bit on Windows too. I don't know if that's because of middleware or an actual desire to support 32 bit hardware, but regardless, it probably doesn't make sense to use 32 bit on Windows and 64 bit on macOS. For non-games, a lot of the Mac software that was still 32 bit was using Carbon, which doesn't have a 64 bit variant. Carbon is old as heck, but if you're using it, there's no upgrade path other than a complete rewrite. That may or may not be worthwhile versus EOL'ing the software. (As a complete tangent, I recently learned that Apple did once promise a 64 bit version of Carbon. The library was present in the developer preview of Leopard, and many devs began building with it. But then it was gone in Leopard's final release, and Apple never mentioned it again.)
- makecheck 7y agoI can only speculate as to each company’s intentions but I will say that it is not just a matter of “recompiling” to support 64-bit. For example, one thing I noticed on the iOS side (when it went from 32-bit to 64-bit) is that pixel position rounding changed so you would see things like random one-pixel gaps where textures were previously adjacent, etc. These things add up, and a company might decide an older title is not worth fixing. On the Mac side, the entire damned UI library was thrown out (Carbon), and it wouldn’t surprise me at all if games had been relying on it. That is a huge thing to just redo, and again I would not blame any game company for not bothering to spend the resources.