As a company, we choose to do things in a way that cannot be summarised as simply “different”. While we understand that rules are made to be broken, they were written with a purpose, and we look towards understanding the parameters of our work enough to be effectively different. So much of the potential in setting trends and redefining things is lost to realisations of irrelevancy, and we can stand apart by understanding this enough to apply it. With that in mind, I would like to give an explanation of a potentially controversial and confusing choice made in the interest of the ÔÇô Engine. In a word, Vulkan.

In our eyes, developing a game engine to use more than one graphics API is at best avoidably expensive, and at worst a downright squandering of resources. In the past, the obvious answer was OpenGL, but it has truly seen better days. The first incarnation of Khronos’ Vulkan API was released nearly two years ago, and has had ample time to gain widespread adoption on all recent platforms of note. Apple devices have tentative support through an abstraction from the Metal API, and there is solid support for Microsoft Windows, GNU/Linux, and Android with unanimous support across hardware vendors. The only snag to note is Windows’ lack of support for Intel iGPUs older than Skylake, but GNU/Linux has support backported as far as Ivy Bridge. Furthermore, Nintendo has provided official support for Vulkan on the Nintendo Switch.

Nonetheless, it would be silly to say that Vulkan absolves us of discrepancies. Its system for handling shaders is quite alien compared to OpenGL’s, and given Sony’s insistence with their adored GNM(X) graphics APIs and associated shader language on the PlayStation 4, there will be quite some work to do on our part. But what about it, anyway?

As I have written before, ÔÇô has the goal of pragmatically separating “scripting” from “programming” – in this way, it should also provide powerful abstractions for GPU-centric tasks as engines of times past have done for the CPU. Vulkan maximises the potential of such functionality when it comes time to be written. When it comes right down to it, we think and act for the future more easily without dated dependencies getting in our way.

We think Vulkan has enabled everyone to tap into an ocean of power, lying within the graphics cards we have been using for years. If parallelisation is truly the pyramid king of software engineering, well… we are happy to take that as a challenge. The only place to go is up 🙂