Tag: vulkan

Get the first UI data on the screen, WiP all over

Finalising the UI integration on the renderer. 🙂

While not very impressive to look at, it means that the underlying concepts finally work!

fix model rendering. add texture id to the widget parameters

While adding an optional texture id to the widgets it does not do anything in terms of actually rendering it yet. It is also bringing up more of the rendering side of things, starting to account for the differences to the model manager, where we do not have concepts such as “models in models”, while “widgets in widgets” exist.

add a lot of boilerplate code to bring up widget drawing in the renderer. non-functional WiP.

Adds more code to connect the renderer with the more high level UI logic code.

– further flesh out the widget interface (and implementation)
– add a new (yet unused) UiPipeline to the renderer
– add an automated id assignment to the widgets

This adds the render pipeline for the UI, it is mostly copied over from the model pipeline, since there is the biggest logical overlap.
Also, the interface manager automatically counts up the number of instanciated widgets in order to assign them a unique id, similar to the models.

Refactor: Add new renderer and base namespaces and move classes appropriatly (sic)

While it moves around a fair bit of code there is no functional change.

Refactor: Move utilty classes to a utility namepsace

As it says in the message!

add visual feedback when hovering over build markers

Now as soon as the user hovers over build markers they become taller to indicate which one is currently active. This required changes from the shaders to the hash calculation functions, but was definitely well worth it:

– move some static value to proper class members as opposed to defines
– move the render pass creation to the util class
– do not use depth testing when drawing the build markers (they’re always on top as they need to be seen)
– more tests about where to put valid build markers (do not build over existing walls or objects)

Another step to making the renderer less horrible.
Also, we now get more sensible potential positions for the build markers (2nd step), before that we would just place them everywhere.
This video demonstrates the new logic as well as the A* path finding .

add more mutex locks to fix a race condition

It seems to be the solution to many problems.

initial wall building support

Mostly wires up the code from the previous commits and adds the logic for first selecting a starting point and then a target for a new wall.

But maybe a short videos says it better: