Warp Drive is a Game Engine built on top of C++ and SDL2. It originally started as a school project but I have over the years kept it around and, every once in a while I go back to it.
It’s main use for a while has been as a complex project within which I have a less “hello-worldy” situation to study and implement new features in. One of these features, multi-threading support for OpenGL is still likely my favourite bit of code among everything I’ve made. I’ve actually made a post in this site about my process breaking the problem down and implementing a solution. You can check it out if you’re interest, it’s template hell all the way
As usual, Warp Drive is open source, hosted publicly in Gitlab
Project Status
Warp Drive is “inactive”. Coding a game engine is super fun, excessively so, even. So much so that it’s easy to just keep tinkering with it forever without actually making anything with it. As such, I’ve decided to try my best to, instead, code in different contexts.
Instead of spending my time tweaking Warp Drive eternally, use something like Godot and have some actual output to show for it and a chance I’ll actually make the game projects I want rather than implementing more low level features in this engine.
As a study tool it IS very valuable, though, and I may end up bringing it out again in that capacity.
How it works
Warp Drive uses SDL2 to handle its window/context creation as well as user input. It switches between distinct Game States. Each state has a Draw and an Update loop, to process graphics and logic. By default, these run on separate threads but a flag can be tweaked on build to have them run on the same one. This is useful, for example, when exporting to WebAssembly through emscripten, something that IS supported.
Internally Warp Drive has some basic OpenGL support. It’s very incomplete as it was always “next on the list” for a more robust implementation. Game elements are structured through inheritance. Everything is a Game Object, and there’s an overarching `Game` singleton which manages everything. Individual game states can then control which objects get drawn and/or updated.
Other than all of this state and object management, Warp Drive has a lot of Maths coded by hand and other things which, for more real-world use cases would likely be better served by integrating pre-existing specialised libraries. Part and parcel of its origins as a school project aimed precisely at learning those
Warp Drive requires C++ 14