refactor the colour fetching code
This moves the code that does the fetching to the Vulkan utility class.
Right now you can at least distinguish the type of entity you are clicking on.
Ramblings about hobbyist game development
refactor the colour fetching code
This moves the code that does the fetching to the Vulkan utility class.
Right now you can at least distinguish the type of entity you are clicking on.
add fundamentals for the selection logic (WiP)
This adds a second draw pass that draws a second image resource on the renderer that is not visible to the user. It will but will only be used to identify objects, walls and tiles on the screen by drawing each individual entity with a unique, single colour.
Once a mouse click is registered, a copy of that image is made to CPU readable memory in order to check the unique (RGB) colour at the given pixel coordinates. However, so far nothing is actually done with this information.
further split up the (vulkan)renderer into separate files (2)
This makes actual use of all these new classes, or let me try to give you an idea with the following picture:
further split up the (vulkan)renderer into separate files
I just can’t leave that poor renderer alone. This further splits up the pipelines into separate classes that are based on an AbstractPipeline class.
refactor the renderer (done, probably)
Among other things, this adds a utility class that contains many commonly used functions like copyBuffer().
fix and/or silence warnings in the renderer
Casting things, adding #pragmas to stop some overly zealous diagnostics.
refactor the renderer (breaking it up, WiP)
This moves around a lot of code. One of the biggeste changes to mention here is to move the render pipelines (models, tiles, walls) into separate classes.
capture mouse clicks
Sets up basic support for capturing mouse clicks and passing on the coordinates of the click to an as of yet empty handler on the GameState class.
minor refacotring: silence some warnings
(sic)
Does what it says.
wait for the path to clear for 200 ticks before giving up navigation
Since we are only looking for static objects when plotting a path, dynamic objects may end up blocking the way. Those dynamic (as in “moving”) objects might also move away again, to account for this, wait 200 ticks and try again before giving up.
In the above video you can see how the first chair first blocks the way, so the second one waits before it tries again after 200 ticks.