Add user triggered rotation
This actually implements the rotation hinted at in the previous commit. This also has a simple acceleration/deceleration function, so the rotation feels relatively smooth.
Ramblings about hobbyist game development
Add user triggered rotation
This actually implements the rotation hinted at in the previous commit. This also has a simple acceleration/deceleration function, so the rotation feels relatively smooth.
refactor and flesh out key input handling
The input handling is improved by adding the ability to support ongoing key presses as opposed to the simply registering simple one-off key strokes.
This also adds support for rotation, something that does not actually do anything yet, this yet and is just meant as a proof-of-concept.
Catch our first keyboard input event
Nothing much to add to this commit message. A bare-bones input handler was created that simply ignored all input except for the user to press Q to quit OLives.
Catch our first keyboard input event (add missing changes)
No functional changes to the previous commit, simply some missing files added to the commit.
Refactoring
As this prosaic masterpiece suggests, in this commit things were moved around a bit. What it does not say is that the concept MainApp class was introduced here and the function of a classic C style main.cpp was reduced to instantiating the MainApp, which took over the main tasks, such as running the main loop in a run() function.
Initial commit
This is the first commit. The basis for this was work on a Vulkan tutorial that slowly turned into some sort of idea. A bit of code already existed at this point and the main reason to switch to git now was mostly that I grew tired of mainly copying files between my computers.
At this point some basic building blocks already existed, namely the separation into a render and main thread. The renderer made up most of the code and was mostly still in the tutorial-like state.
– add a mutex so that we do not render while re-creating the swapchain
– add a small config and some logic to throttle the rendering speed (no more 100% cpu usage)
– use a more reasonable example model (still not commited, licence unclear)
As suggested by the commit message in this commit the first mutex was introduced so OLives would not crash when resizing the window.
Furthermore the concept of frame drawing (FPS) and tick (per second) target was added, together with the concept of a configuration, which at this point was nothing but a POD struct. But why don’t we let the code highly complex code speak for itself:
// flesh this out into something to be
// loaded from a file
using Config = struct {
uint32_t tickTarget;
uint32_t fpsTarget;
uint32_t windowWidth;
uint32_t windowHeight;
};
Little did I know at this point that it would take another 1.5 years for this to be loaded from a file.
While no screenshot of any of this state exists, the tutorial model (a fairly complex chalet style house) was replaced by a different (low poly) model of three barrels.