Tag: vulkan

change coordinate signedness to make it more obvious what they represent

Does what it says on the label. 🙂

– implement basic setting of movement targets for objects
– impelemet basic tile click handling (sic)
– add stub for wall click handling

This adds handlers for our three types of clicks (object, tile and wall) to the GameState. This furthermore adds the concept of “being selected” to the objects.
Once you click on objects you can now select them (if they are not marked as static) and set a target for them to move towards to.
This finally allows the user to actively alter the state of the world.

encode model IDs and tile coordinates when generating the data structures and decode that information  when clicking on them (WiP, mostly working and walls are missing)

As has been mentioned before, there was no actual distinction between what you were clicking on, but as the commit message states, now there is at least a distinction between models (objects) and tile coordinates.
This is happening in the sparkling new SelectionColourManager which does not represent my best moment when it comes to naming things.

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.