Tag: c++

  get elevation by tile WiP

This commit adds some functions to safely get the elevation of the height map at a given tile (coordinate).

  expose the whole tile manager through the floor class

Well.. yes. As it says on the label.

   – 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).

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.

– implement rotation towards current movement target
– implement zooming in and out within a certain range

This commit is more or less self-explanatory. Things rotate. You can zoom. Works as advertised.

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.

– 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.

– 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.

– 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