Inexor is a MIT-licensed open-source project which develops a new 3D octree game engine by combining modern C++ with Vulkan API.
- Source Code
- How to contribute
- Frequently asked questions
- What is Inexor?
- Which platforms are supported?
- What is the current state of the project?
- How is Inexor organized?
- How to contact us?
- How to build?
- Where to find Inexor’s documentation?
- What is Vulkan API?
- Why is Vulkan API the future?
- Can you explain Vulkan API in simple terms?
- How difficult is development with Vulkan API?
- Does my graphics card support Vulkan API?
- Will you support other rendering APIs?
- Which topics are currently not in focus of development?
- Helpful Links
- Source Code License
- Contact us
Frequently asked questions¶
What is Inexor?¶
We have the following goals for the Inexor engine:
Create a Vulkan API codebase which can be used in production.
We are using good software engineering practices:
Use of the new C++ standard library (C++11, C++14, and C++17).
Code documentation using doxygen.
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 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:
A modern C++17 codebase with a setup for CMake and conan package manager.
Stable builds for Windows and Linux using Continuous Integration (CI).
A rendergraph in early development.
ImGui integration using separate renderpasses.
RAII wrappers for various Vulkan resources.
Extensive logging with spdlog.
Vulkan Memory Allocator for graphics memory management.
VMA memory replays for debugging are already working.
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?¶
How to build?¶
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.
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 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
The explicit design of Vulkan gives much deeper control and avoids driver guesswork and undefined behavior of graphics drivers.
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.
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.
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.