Frequently asked questions

Please visit and join our Discord server.

What is Inexor?


Inexor is a MIT-licensed open-source project which develops a new 3D octree game engine by combining modern C++ with Vulkan Vulkan API.

We have the following goals for the Inexor engine:

We are using good software engineering practices:

You can find Vulkan example code online which follows the mantra “don’t use this in production - it’s tutorial code”. Inexor disagrees with this as we believe that defeats its own purpose. If example code is not meant to be used in some other projects then there’s something wrong with that example code. Many projects don’t use a proper memory management library like VMA or they do not abstract their code using RAII, but use a lot of code duplication instead. Inexor is designed to be used in production. Bear in mind however that Inexor is also still far away from being a finished game engine.

Which platforms are supported?

  • We support x64 Microsoft Windows 8, 8.1, and 10.

  • We support every x64 Linux distribution for which Vulkan drivers exist.

  • We have specific build instructions for Gentoo and Ubuntu. If you have found a way to set it up for other Linux distributions, please open a pull request and let us know!

  • We do not support macOS or iOS because it would require us to use MoltenVK to get Vulkan running on Mac OS. Additionally, this would require some changes in the engines as not all of Inexor’s dependencies are available on macOS or iOS.

  • We also do not support Android because this would require some changes in the engines as not all of Inexor’s dependencies are available on Android.

What is the current state of the project?

We are still in very early development, but this project can already offer:

How is Inexor organized?

  • Inexor has no central authority.

  • It’s a headless collective which makes decisions through creative discussions.

  • We are welcoming new contributors to our team.

How to contact us?

Please visit and join our Discord server.

How to build?

If you have any trouble building please open a ticket or join our Discord.

How to build vulkan-renderer?

Where to find Inexor’s documentation?

  • Read our docs here.

What is Vulkan API?


Inexor uses Vulkan API as rendering backend. Vulkan is a new, multi platform low level API (application programming interface) for high-performance graphics programming and computing. It is the successor to OpenGL, and it is important to state that is is very different from it. Vulkan is not just a new version of OpenGL or an extension of it. Instead, Vulkan is a very low level API which allows for much deeper control over the graphics card and the driver, like DirectX 12 or Apple’s Metal. Unlike OpenGL, Vulkan API is build in a way it fits the architecture of modern graphics cards. This offers better performance due to reduction of overhead and driver guesswork during runtime. This results in higher frame rate, more predictable CPU workload and a lower memory usage. The most important benefit of Vulkan is the fact that it allows for multithreaded rendering, which is not possible in OpenGL at all. In general, Vulkan does a lot of work during the initialization of the application but therefore reduces work during rendering. Since Vulkan is much more explicit in terms of code, it foces you to think about the structure and architecture of your code. Both Vulkan and OpenGL are being developed by the Khronos Group. Vulkan is being developed through an unprecedented collaboration of major industry-leading companies (Google, Intel, AMD, NVidia, Sony, Samsung, Huawei, Qualcomm, Valve Software and many more). Vulkan is the only multi platform low level graphics API.

Why is Vulkan API the future?


  • Lower and more predictable CPU load which results in better performance and a reduction of driver guesswork.

  • Vulkan API is asynchronous and encourages multithreaded rendering. This is not possible with OpenGL!

  • The low level API design of Vulkan allows for advanced optimizations such as rendergraphs for generic rendering architectures.

  • It also wants you to use the GPU asynchronously, sometimes referred to as GPU multithreading.

  • Vulkan allows the use of multiple GPUs, even if they are not physically linked via crossfire bridge.

  • The reduction of CPU workload and it’s improved predictability can enforce the GPU to be the limiting factor of performance, as it should be.

Memory efficiency

  • Vulkan gives much deeper control and better interfaces over graphics and system memory.

  • Vulkan API enforces memory management to be done by the application rather than the driver.

  • Since the application knows best about the importance of every resource it uses, Vulkan API allows for a better memory usage.


  • Unlike OpenGL, Vulkan fits the design of modern GPUs as it is not just one single state machine. This means Vulkan API was designed from the beginning to match the architecture of modern graphics cards. OpenGL however still matches the design of graphics cards from the time it was invented in the 1990s.

  • Vulkan is a fresh start, whereas OpenGL contains a myriad of hacks to support very rare use cases.

  • Vulkan has layers and extensions as part of its design. You can check for supported GPU plugins on the target machine and enable them as needed.

  • Vulkan API itself is completely platform agnostic.

  • Available on a variety of platforms: Windows, Linux, mobile devices and much more!

  • The ending of the OpenGL era has begun.

  • Vulkan is being developed through an unprecedented collaboration of major industry-leading companies. It is not being developed by one company only (like Microsoft’s DirectX for example).

  • As Vulkan’s motto states, it really is industry-forged.

Consistency and standardization

  • Vulkan precompiles shaders to a standardized bytecode format called SPIR-V. This also reduces driver guesswork during runtime.

  • The explicit design of Vulkan gives much deeper control and avoids driver guesswork and undefined behavior of graphics drivers.

Debugging tools

  • Validation layers and diagnostics can be independently activated during development, allowing better error handling and debugging compared with OpenGL or DirectX.

  • Upon release builds, the validation layers can be turned off easily.

  • Vulkan API applications can be debugged with RenderDoc.

  • The Vulkan specification is very easy to read and it is the central guideline for how to use the API.

Open Source

  • Vulkan API and some Vulkan graphics card drivers are open source.

Can you explain Vulkan API in simple terms?

  • Vulkan API gives programmers much deeper control over the gamer’s hardware.

  • If applied correctly, Vulkan can result in a significant performance boost.

  • The API encourages the programmers to think in detail about graphics cards and their game engine.

  • It offers advanced optimization techniques which can result in a lower RAM and video memory usage.

  • Using Vulkan can yield in lower and more predictable CPU usage.

  • Vulkan allows programmers to make more effective use of multiple CPU cores.

How difficult is development with Vulkan API?

  • This API does a lot of initialization during the loading phase of the application.

  • The key to success is a good abstraction of Vulkan API based on the needs of the application/game.

  • Vulkan is a C-style API. In simplified terms you fill out structures which start with Vk.. and submit them together with other parameters to vk... functions. That’s it. No complex interfaces.

  • Vulkan API has a very good documentation.

  • The challenges of Vulkan game/engine development boil down to basic programming challenges: abstraction, resource management and parallelization.

  • You may want to read Vulkan in 30 minutes by Baldur Karlsson.

Does my graphics card support Vulkan API?

Will you support other rendering APIs?

  • No, because testing for Vulkan already takes a lot of time and there is no sense in supporting deprecated technology.

  • Some studios like id-software also dropped OpenGL entirely.

  • Vulkan API is the only low level multi platform graphics and compute API.

Which topics are currently not in focus of development?

  • We are currently focusing on the renderer and Vulkan API. When the time has come, we will take parallelization into account.

  • A game engine needs other components besides rendering of course. However, we are currently not focusing on the following topics: networking, sound, physics, packaging of game engine resources and everything else which is not related to rendering.

  • We will not begin to support additional platforms besides Linux and Windows in the near future.