Thoughts on the deprecation of OpenGL on macOS – ShiVa Engine

Thoughts on the deprecation of OpenGL on macOS

Last Monday, Apple kicked off their annual WWDC event with the usual keynote talk, where they previewed the updates to their 4 operating systems macOS, iOS, watchOS and tvOS. Apart from the Apple Watch, ShiVa runs on all these platforms, so we have to keep a close eye on all changes. Naturally, Apple showcased only the visually impressive new features, like updates to AR, dark mode, and Animoji to the crowd, but left the more technical, boring and unfortunate news for after the keynote. One of these unfortunate news is the deprecation of OpenGL. What does this mean for ShiVa?

ShiVa's rendering pipeline

Since ShiVa 2.0 beta 3, our engine's primary pipeline is based on OpenGLES. This change was necessary to support long-awaited features like custom shaders and PBR. ShiVa 2.0 beta3 and all subsequent releases use GLSL ES as their primary shading language, which is probably one of the most complete and universally supported shading languages currently in the world. Translators are in place to cover all our export targets, so the code gets converted automatically into Desktop GLSL, DX11/XB360/XB1 HLSL, PS4 PSSL, PS3 PSGL, and so forth, without you having to write a single line of platform-dependent code. For us at ShiVaTech, this change also makes it easier to maintain the engine on all targets, allowing us to push changes and improvements as well as new shaders more quickly to all available platforms. However we still ship the the "legacy" pipeline as a fallback for very old hardware, just in case you are experiencing difficulties with the new pipeline.

Changing the pipeline also had a very positive effect on all Linux users: For the first time, you were able to develop and play your ShiVa games with the open-source drivers instead of the proprietary binary blobs. The performance gap between open- and closed-source drivers is continuously narrowing, and you not having to worry about the graphics driver on remote Linux system is certainly a great plus.

The deprecation of OpenGL and GL ES

With the deprecation of OpenGL(ES) on Apple platforms, are you in danger of losing all three Apple platforms as an export target? Several game developers have voiced concerns about Apple's move to deprecate these widely used cross-platform APIs, ranging from conflicted feelings to outright refusal for future mac game support. The good news first: Your games will not suddenly stop working overnight. Apple describes the process as follows:

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.

Furthermore, Apple insists on developers making the shift as soon as possible:

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.

Most general news outlets don't report on how widespread this change actually is. Not only is OpenGL deprecated in macOS 10.14, but OpenGL ES is also about to be dropped in the coming versions of iOS and tvOS, meaning the whole range of Apple operating systems that heavily rely on graphics suddenly finds itself without a cross-platform graphics interface. As a replacement, Apple is pushing developers towards their own, proprietary API called Metal.

Apps built using OpenGL ES will continue to run in iOS 12, but Open GL ES is deprecated in iOS 12. Games and graphics-intensive apps that previously used OpenGL ES should now adopt Metal. 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. [...]

This puts cross-platform developers in an awkward position. On virtually any other platform, be it Windows, Linux, Android etc., OpenGL is slowly replaced by Vulkan, a new open cross-platform standard. Metal is unique to Apple systems. While dropping macOS as a gaming platform might be an option to some developers, given how little traction Apple's desktop OS has in the gaming world, but losing iOS on the other hand with its huge market share is unacceptable.

We are working on a solution

We are not going to abandon our customers. ShiVa will continue to be available on Apple platforms, since iOS is the system most of our indie developers rely on for a substantial portion of their income. Your games will not stop working overnight and OpenGL(ES) is still available in the next version of iOS, tvOS and macOS, however we have to work hard behind the scenes to make ShiVa 2.0 fit for the new API requirements.

We are currently looking at a number of options to accomplish our goal. Locking ourselves in to the Metal API seems like a bad idea for a cross-platform engine, especially since Apple has a history of repeatedly dropping their own APIs, connectors and standards on a regular basis. The future of cross-platform development is most likely Vulkan, so this is where we will start. Translation layers for Vulkan to Metal already exist, which do perform very well and give even native OpenGL a run for its money. QT, which is used for the ShiVa Editor UI, will also eventually support Metal through the same mechanism, so it's a good end-to-end solution. In the end, we aim to provide an external drop-in replacement library for the GL/ES subsystem, specifically for our engine, in the same near-seamless fashion you have come to expect from our DirectX/UWP port.