Commit 3aa80056

   – add the tilemanager (WiP)
   – bring the renderer closer to actually rendering the floor (WiP)
   – experiment with smart pointers a bit (WiP)

Adding the concept of a TileManager (similar to the TextureManager) which in turn manages TileTypes. The floor class is extended to know which logical tile is of which tile type, on top of the raw height map data.
As also mentioned the support on the renderer for the new floor concept is being further fleshed out.
Lastly, some references and raw pointers have been replaced by smart pointers (std::unique_ptr/shared_ptr).

Commit e727731f

WiP: Add the concept of a floor (that includes a heightmap + tile logic)

This adds the “floor”, which is fancy way to say “wrapper around a height map”. Additionally to that, the floor can also, similar to the model manager, return vertex data which then in turn can be used by the renderer.
This commit also included a lot of (boilerplate) code being added to the renderer in order to draw the floor/height map.

Commit 437614c7

add rudimentary change of positions and rotation

Building on the previous work of the object state updates, this properly introduces the concepts of logical tile position (as opposed to geometrical position) and rotation.
Furthermore, objects now also have a current speed can bet set to move to a target tile. At this phase, that means rotating towards it and then moving directly in that direction, no pathfinding is involved.
The result can be seen in the video below.

Commit 52044d41

– add tick methods (that do not do much yet, but are called)
– create objects using logical 2d vectors and convert to 3d internally

This fleshes out the Object and ObjectManager class. Sadly removes the example scene and replaces it by a single object. The main reason for this is the fact that objects can no longer be manually placed in the 3D space, but are actually converted (mapped) from a logical 2D tile position into the 3D space.

Commit 8c063260

– refactor so that the assumptions about the number of descriptor sets is true
– generate correct object ids
– actually check for further usage before discarding textures

Little is to be added to this commit message except that is also (successfully) included an object removal without scrambling up the object-to-Vulkan vertex structure and texture-to-Vulkan image buffer mapping.

Commit 8db623c6

– refactoring: the GameState is now responsible for adding new objects
– refactoring: the renderer no longer directly adds/removes models but instead implicitly uses the current data from the ModelManager

A substantial refactor that can be summed up in some further bullet points:

  • We now use the GameState to load models, as such the addModel()/and removeModel() functions are removed from the renderer
  • They are being replaced by a function called synchroniseModel()
  • The concept of a state hash is added to the ObjectManager which calculates a unique hash for the current object state
  • The renderer also has a copy of the hash value, if they differ it knows it needs to update the Vulkan specific data structures to draw the new object/model state
  • The instantiation of the homely example scene (if you consider a bunch of chairs hovering over a bottomless void homely) moved from the renderer to the object manager

Commit 0c1c2395

– refactor the renderer so that the does not instantiate the model manager on its own so that it can be used across places
– introduce the object manager and game state classes, even if they are not used yet

This was actually a substantial change, as it finally disconnected the renderer from the model manager. As is hinted in the second point, this introduces the yet unused ObjectManager, which stores logical objects that have a concept of position other than the actual geometrical position used when drawing the models.
This is the first step towards building game logic.
What makes this less monumental is that it is missing the actual object manager files, see the next commit for that.

Commit efd2a7eb

add missing files

The second part of the previous commit. This adds the actual files for the ObjectManager. The ObjectManager has its own instance of the ModelManager and automatically loads models as needed (i.e. a new object is added that uses a certain model). At this point it is not much more than a wrapper around the ModelManager, but that is to change.