Commit b1fbe3c7

– Extend the slot (object-in-object) configuration of types (WiP)
– Added a third concept of slots (job context, next to sitting and lying)
– Add code that validates the slot configuration for sitting, lying and job
– Add the O2 flag for release builds

Relates to #13 and #12

Once again, not the most exciting commit, but that can probably be said for many commits in the early phase of bigger features.
This commit adds the concept of a third type of slot (the term also happened to be introduced in the context of this commit): the job slot. That means it will also be possible to define special slots that can be used in the context of a specific task, as opposed as to the “passive” slots for sitting and lying down.
A bit of code was written to finally validate and assemble the configuration information of all three slot types so that they can be added to the object types loaded when starting OLives. That very last step of added the newly assembled (and verified) information is what is still missing, and will be added in the next commit.
Once that is done, newly created objects will also hold information about their respective slots, which paves the way for the more exciting (and visible) changes. As always, stay tuned!

Commit c56146c4

– Add boilerplate code for seating point (etc.) configurations
– Make the way in which embedded configuration options are being loaded more generic
– Add new object categories in relation to seating (etc.), still unused
– Fix file name information for embedded configuration options, i.e. fix the error message in case of an invalid configuration property

Relates to #13, #14 and #12

Hi! On the outside this commit not particularly exciting, but it does get some of the rather cumbersome boilerplate type work done as well as addressing some issues that have been bugging me for some time, but not enough to actually look into them
As an added plus, writing the configuration option definitions and parsing (and also making the changes to the configuration files themselves) made me think a bit more about the concrete requirements for some of the concepts.
So while nothing can is visible yet, project “get those human-shaped things to sit down and also have them take showers” is finally off the ground. Stay tuned!

Commit 457433ec

– Do not ignore x and y positions with a value of 0
– Fix mutex deadlock when switching from full-screen to window mode

Fix #4, Fix #1

Hi! Scrolling is now working as expected in full-screen mode. While fixing that I also noticed a deadlock when switching from full-screen back to window mode which was caused by a mutex that was locked, but never unlocked for that specific code path – everything should be fine now. 🙂

Commit 7e4c3f66

Take the portal state into consideration when calculating the wall state hash

Once again, not really a great candidate for a screen shot, but still slightly exciting, at this “officially” puts an end to the whole portal topic for the time being, meaning it’s time to pick something new to work on!
In terms of what it actually does, if a wall or door gets placed you will get immediate visual feedback and will not have to wait until the mouse starts hovering and so implicitly forces a refresh of the wall drawing data.

Commit 3e6bdc79

Try to create the instance using Vulkan 1.1, but fall back to 1.0 if necessary

Does exactly what it says! Turns out that without explicitly installing new graphics drivers, most Windows installation only support Vulkan 1.0 out of the box.
Vulkan 1.1 is already preferred, but in no way needed, so we can easily fall back for the time being.

Commit f104363e

– do not use blitting when copying pixel data for selection purposes
– only copy the single, pertinent pixel
– Convert remaining C-style enums to enum classes
– Do not try to forcefully re-draw before the marker rendering data has been updated

Happy new year!
This commit message may not sound very exciting, it is fixing the issue of the input not working properly on Windows though, so check this out in all its glory:

This is a binary that was produced via cross-compiling and worked out of the box on Windows. It still feels weirdly choppy in comparison to running it on Linux (same machine) or even running the Windows binary on wine using Linux, but I’ll get it eventually.
This opens up the possibility of actually providing more or less regular builds using some sort of poor-man’s CI, let’s see what 2020 brings. 🙂