expose the whole tile manager through the floor class
Well.. yes. As it says on the label.
Ramblings about hobbyist game development
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:
– 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.
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.