Fix some clang-tidy warnings
A newer Clion version brings more clang-tidy, fix most of these.
Ramblings about hobbyist game development
Fix some clang-tidy warnings
A newer Clion version brings more clang-tidy, fix most of these.
Simplify code to remove unused widget data from the ui pipeline somewhat
This reads: use std::none_of instead of manually iterating over some things.
Do not use invalidated iterators
Another maintenance commit, this time meant to remedy some seemingly random renderer crashes. Some iterators would implicitly move even if the element they might point to next might have been invalidated already.
– make things compatible with current libglm releases
– make olives compile and run with recent libvulkan releases (WiP, breakage occurring still)
– fewer magic numbers
Maintenance changes, before that I was forced to downgrade to older versions of both in order to make OLives compile. Not a fun change, at all. 🙁
This is the first in a series of maintenance commits before going back to more feature driven development.
add the script to the objects themselves and use it in a proof-of-concept type of way when selecting a human
Further integrate the loaded script by moving the script instances from the ObjectType to the actual Objects. This way we can actually interact with the instantiated Python module, meaning we have the first more or less meaningful interaction between the Python and C++ parts:
update .gitignore
It makes sense not to have precompiled Python bytecode in the repository.
– add a (one way) binding from C++ to python for the time being
– automatically load scripts on a per object type basis
– add the ability to have optional configuration settings
This marks the introduction of Python by using pybind.
At this point it is not doing much except for laying groundwork for what is to come: adding new properties to the Object and ObjectType classes and extending the ObjectType configuration to define a script file that needs to be loaded when an Object is added to the GameState.
Right now, a script file is being loaded and a script interpreter instance is being instantiated when an object is being created and this is where the integration ends: no Python code is actually executed at this point.
The single Python file currently loaded looks like this:
It is relatively easy to tell where this is going by looking at the function names, but as mentioned before, so far the only important thing is that this is a syntactically correct Python file.
add new padding and sizing modes in order to allow for near pixel-perfect widget alignment
This took a while and was fairly frustrating. This is visually a considerably better result, but by no means perfect. It essentially tries to bring the concepts of “relative sizes” and “pixel specified sizes” closer together, but still suffers from some rounding problems. Be that as it may, it’s a clear improvement, as can be seen in this before/after shot:
Add support for showing a colour specturm instead of a plain white progress bar that changes depending on the status
shown
Comes as advertised, adds the ability to the brand-new status bars to now just show their value in plain white. Whether or not to use an interpolated colour value or just a plain white can be set as required.
Add the first semi-working version of the status bar
For the time being this is the most complex widget, the StatusBar.
Next to a text label, one can also set a percentage value, the eponymous status, that it will translate into renderable model data that looks like, well, a status bar.
To make the distinctions between the different widget types work, they can now all return their type, thanks to the introduction of a new WidgetType enum class.
In order to showcase this in action the new status bars are being shown when a ControllableObject is selected, showing the values of health and hunger.
Furthermore, a bit of preliminary game logic is added in order to decrease an object’s food value when it moves. Check out the result: