more namespace refactoring
No functional changes today!
Tag: c++
Commit 5c33f613
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.
Commit 7b9cd697
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.
Commit 256fc0cd
Refactor: Move utilty classes to a utility namepsace
As it says in the message!
Commit 8194ed90
split up inline getter/setters
Moves the logic for them from headers to the respective .cpp files.
Commit 41f6e2ff
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:
Commit 9d6c213e
add a further check (for walls in the way) for the building marker start points
Some cases were not covered yet, now they are!
Commit 7560e87f
– 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 .
Commit 68f1f15d
add more mutex locks to fix a race condition
It seems to be the solution to many problems.
Commit e2cdaa05
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: