Ramblings about hobbyist game development
– 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.
– add a concrete implementation for a simple container (that displays widgets in a rwo) (sic)
– add the minimal implementation of the UI manager (that only adds the empty bottom bar so far)
The newly introduced RowContainer is just a small implementation of the abstract container class. It does not do much, but draw its child elements in a row. Apart from that the concept of “padding” was introduced, so that child elements have some spacing in-between them.
To give everything a central place, the InterfaceManager was introduced, which itself implements the AbstractWidget class.
Since it is a widget itself, its children can calculate their size relative to it. For instance the newly introduced “bottom bar”, which will house most of the upcoming UI can be defined as follows:
slight refactoring of the widget constructors to make them easier to instantiate. added more setters to the abstract widget, so that we can have fewer required ctor parameters
As it says on the label!
– add some bookkeeping to the abstract container
– use a different way to write memeber variable comments (sic)
The book keeping in this case means calculating the absolute size of the children inside a container as well as recalculating it when adding/removing children.
– do more refactoring
– add a first concrete implementation (a “button” that does nothing but draw its background colour)
– change the interface (and implementation) of the abstract container class, use smart pointers instead of references so that we can actually use abstract classes
That basically says it all, that new button does not do much yet besides existing.
more namespace refactoring
No functional changes today!
add very basic UI logic, nothing works, all WiP and not integrated into the renderer at all
This adds a whole lot of base logic for the UI, the next big step in the evolution of OLives, as so far the entirety of user input is done through hot keys. While it is very exciting to keep pressing ‘o’ after switching to the right game mode, it also does not work as a long-term solution.
This commit adds logic for widgets, a container class which is also a widget, but can contain other widgets and a whole chunk of base logic about calculating sizes and positions.
Widgets can be relatively (in relation to their parent) or absolutely (in pixels) sized.
They also can already create model data (vertices), using the same type of ModelData structure as is used for the elements that can be rendered, meaning the models, walls, tiles and build markers.
As it also says, this logic is doing nothing except that it can get compiled and linked, it is as of yet completely unused.
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!
split up inline getter/setters
Moves the logic for them from headers to the respective .cpp files.