do not make unselected objects darker, make selectd ones brighter (sic)
Three for three, things that make things are on a roll now.
Ramblings about hobbyist game development
do not make unselected objects darker, make selectd ones brighter (sic)
Three for three, things that make things are on a roll now.
do not destroy the selection image view twice
That too sounds like a pretty good idea.
mark debugging output as such
That sounds like a good idea.
visually distinguish selected objects
This draws the selected objects slightly brighter than non-selected ones, and brings the last few commits to a conclusion, as we are now able to distinguish between clicks on objects, walls and tiles as well as being able to tell which entity has been clicked on specifically.
In the case of objects this is wired up to the existing “move object towards a given position” code in order to give the user the possibility to actually alter the game world, check out the video to see this what it actually looks like at this point.
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.
also encode and decode wall coordinates and thus make them identifiable when clicking on them
Add the missing support for identifying wall pieces and which side of the wall the user clicked on.
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.