OpenTTD, the open-source game of business transport simulation based on Transport Tycoon Deluxe, is now available for free on Steam for Windows, macOS, and Linux. The developers recommend that new players check out OpenTTD’s manual, a 26-part tutorial series on YouTube, and a short 14 minute video on signaling. This seems like it’s in the Dwarf Fortress realm of difficulty but those guides should help.
Valve’s Pierre-Loup A. Griffais announced that they’re including their brand new fork of the WINE Windows pretendulator in a new beta product for Steam. They call it Proton. WINE is an open-source Windows API emulation layer that lets Linux users play Windows games without rebooting into Windows. I call this process “pretendulation” because it isn’t emulating the entire operating system, but it is still far from native.
That sounds good, more games for Linux, right?
Well, when I started writing about Linux gaming 18 years ago there was a commercial, closed-source, fork of WINE called WineX. WineX had a lot of fans, it was developed by people who had been working on Wine, which was a more generalized product for Windows software, to target game software. These developers of WineX (later called Cedega) did a good job at writing the software, but it had a number of issues.
One of those WineX issues was that Windows compatibility is a moving target. Any progress the WineX developers made to support new versions of Microsoft’s DirectX game software programming interface were usually still years behind where modern games were. If the latest Battlefield game came out and it only worked with DirectX 8 and WineX was still on 6 or 7, it was going to be a while until they could support that new game.
Even though new DirectX versions are less of a headlining feature in Windows these days, compatibility with a wide range of games is going to be a problem for Valve’s Proton as well.
Any emulation, or translation, layer, is also going to introduce some amount of performance overhead. You can’t emulate a PlayStation 3 or Dreamcast at full speed on a lot of expensive computers today, but you can buy the original console for $50 that plays those games perfectly. The same issue happens with emulating Windows APIs under Linux. Some games will only have a very small hit to performance, but others might be more of a problem and you won’t get the same framerate that you do under Windows.
So there are compatibility and performance issues, that’s it, right? Nope, there’s one more technical hurdle. When something breaks, you’re not going to know if it’s the game or the emulation layer. I imagine this will infuriate some developers.
Valve claims that games they’ve tested and whitelisted in this beta have an almost identical gameplay experience to Windows, and they acknowledge the performance overhead. Valve doesn’t acknowledge the negative effect this will have on real native ports of games. Back in those WineX days there were some developers and publishers who cancelled their plans for native Linux ports because Windows pretendulation was “good enough” for them, even when Wine or WineX didn’t provide a great experience for players.
“Good enough” Windows API emulation eventually turned into developers porting their games with Wine wrapped up into a library, giving Linux players some of the half-assed ports they have today.
One additional issue that wasn’t a problem with WineX, these improvements to Wine are only designed to work with games on Steam. You won’t be playing Battlefield 5 with Proton. Although Valve’s fork of Wine is open-source, unlike the old WineX fork which had its source closed behind an agreement that the executives at Transgaming later deleted and refused to acknowledge.
Proton is an interesting technology, but a bad thing for anyone who loves Linux gaming and wants native ports of games brought to Linux.
This wasn’t in the keynote, but Apple had some bad news buried in the “What’s New in macOS” section of their developer site for anyone who makes games or other software with the OpenGL graphics API :
Deprecations and Removed APIs
Periodically, Apple adds deprecation macros to APIs to indicate that those APIs should no longer be used in active development. When a deprecation occurs, it’s not an immediate end of life for the specified API. Instead, it is the beginning of a grace period for transitioning from that API and to newer and more modern replacements. Deprecated APIs typically remain present and usable in the system for a reasonable time past the release in which they were deprecated. However, active development on them ceases, and the APIs receive only minor changes to accommodate security patches or to fix other critical bugs. Deprecated APIs may be removed entirely from a future version of the operating system.
As a developer, avoid using deprecated APIs in your code as soon as possible. At a minimum, new code you write should never use deprecated APIs. And if your existing code uses deprecated APIs, update that code as soon as possible.
Deprecation of OpenGL and OpenCL
Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14. Games and graphics-intensive apps that use OpenGL should now adopt Metal. Similarly, apps that use OpenCL for computational tasks should now adopt Metal and Metal Performance Shaders.
Metal is designed from the ground up to provide the best access to the modern GPUs on iOS, macOS, and tvOS devices. Metal avoids the overhead inherent in legacy technologies and exposes the latest graphics processing functionality. Unified support for graphics and compute in Metal lets your apps efficiently utilize the latest rendering techniques. For information about developing apps and games using Metal, see the developer documentation for Metal, Metal Performance Shaders, and MetalKit. For information about migrating OpenGL code to Metal, see Mixing Metal and OpenGL Rendering in a View.
Apple is already requiring that apps get updated to be 64-bit, or they’ll stop working in a future update.
As much as I loathe John Carmack today, and it certainly didn’t help that he decided to write this on Facebook, he recently wrote about how he persuaded Steve Jobs to support OpenGL on the Mac:
I was brought in to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.
Part of his method, at least with me, was to deride contemporary options and dare me to tell him differently. They might be pragmatic, but couldn’t actually be good. “I have Pixar. We will make something [an API] that is actually good.”
It was often frustrating, because he could talk, with complete confidence, about things he was just plain wrong about, like the price of memory for video cards and the amount of system bandwidth exploitable by the AltiVec extensions.
But when I knew what I was talking about, I would stand my ground against anyone.
When Steve did make up his mind, he was decisive about it. Dictates were made, companies were acquired, keynotes were scheduled, and the reality distortion field kicked in, making everything else that was previously considered into obviously terrible ideas.
I consider this one of the biggest indirect impacts on the industry that I have had. OpenGL never seriously threatened D3D on PC, but it was critical at Apple, and that meant that it remained enough of a going concern to be the clear choice when mobile devices started getting GPUs. While long in the tooth now, it was so much better than what we would have gotten if half a dozen SoC vendors rolled their own API back at the dawn of the mobile age.
While OpenGL isn’t going away immediately in macOS Mojave, when it is finally gone there will be many fewer games on macOS, it has been the only portable graphics API available for developers to bring their games to Linux and macOS, as well as other platforms, for decades.
Without OpenGL on macOS the Mac and Linux will both suffer, as will new platforms. They’ll have a harder time getting games and other software when bigger platforms are locked to vendor-specific APIs like Metal instead of cross-platform ones like Vulkan and OpenGL.
If I had to guess, I would hope that Valve will ship an intermediary layer to translate OpenGL calls for games on Steam, and hopefully they will make this software available for everyone else. There are already some other projects to translate OpenGL to platform-specific calls but it’s not going to be easy for games to support them. It’d be better if these projects had something to handle the translation on-the-fly. It’s also entirely possible that Valve will just give up on older games supporting modern versions of macOS after Apple fully deprecates OpenGL.
I don’t envy anyone trying to support old software and write good OpenGL drivers like Apple has (even when they don’t update their OpenGL support for years), but the deprecation of OpenGL is a real “Fuck You” to game developers and players unlike any other. Games getting updated from 32-bit to 64-bit, as well as going through the process of having any kind of graphics portability layer added on top, seems unlikely. Thousands of games are going to be lost to time when OpenGL dies off. Competition with popular hardware and software platforms will be even more difficult. I understand the desire to get rid of technical debt, but this is bad.
It can be pretty frustrating to find out that something you want to fix is difficult or impossible to repair. Glued-on screens cover batteries that are all custom fit inside small cases that prevent curious people from learning how things work and fixing problems with their devices. Iconoclasts from Joakim Sandberg takes that a step further, it’s a world where a mechanic, Robin, finds that her profession is outlawed. Your mission is to get Robin and her friends together to fix things in what looks like a bit of a metroidvania side-scrolling action-adventure with a Metal Slug-y vibe to the art.
Iconoclasts is a fine game, offering both satisfyingly sharp platforming and shooting, and some really smart puzzles. It’s enormous too, packed with secret areas and other stuff to discover. And although I found the humour a little glib and childish at times, it tells its heartfelt story well. A lot of Metroidvania games go for a bleak, downbeat atmosphere, but Iconoclasts is infectiously vibrant and sunny, even if the story does occasionally venture into dark territory.
There are two big computer vulnerabilities that were announced recently, Spectre and Meltdown attacks. These are significant because they affect almost every desktop, laptop, smartphone, tablet, and game console. Almost anything with a processor can be exploited to give attackers passwords and whatever other private information is on a device.
The attacks work because of the way that computer processors attempt to speculatively work ahead of their current point in executing a computer program. My understanding is that even code executed in your web browser could execute these attacks.
The workarounds that operating systems are implementing may slow these devices down because the attacks utilize performance features of the processors, but the performance effects of the mitigation might not be noticeable outside of specific workloads.
These aren’t normal software vulnerabilities, where a patch fixes the problem and everyone can move on. These vulnerabilities are in the fundamentals of how the microprocessor operates.
It shouldn’t be surprising that microprocessor designers have been building insecure hardware for 20 years. What’s surprising is that it took 20 years to discover it. In their rush to make computers faster, they weren’t thinking about security. They didn’t have the expertise to find these vulnerabilities. And those who did were too busy finding normal software vulnerabilities to examine microprocessors. Security researchers are starting to look more closely at these systems, so expect to hear about more vulnerabilities along these lines.