Finish adding slot data to objects (add to object type and actual object instances)
Nothing much else to say, most of the configuration work is done now and the implementation of the actual logic can start now.
Ramblings about hobbyist game development
– 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
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!
– 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
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!
Add space as a hotkey for pausing/resuming the game
Fix #21
…and yet another quick one. As I found myself hitting space repeatedly expecting to pause/resume the simulation with nothing happening I quickly added it as another hotkey for just that.
– 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. 🙂
Hello!
While there was no “official” commit for quite some time, I haven’t been idle. After being intrigued about the possibility of doing so, I have been setting up a small CI pipeline based on GitLab that allows me to get automated and packaged Linux and Windows builds.
I will not publish these just yet, as I want to get some more basic features in before giving the adventurous a chance to see what OLives is or could potentially be one day. I will skip these commits from the blog as they have nothing to do with the actual development process. Stay tuned!
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.
Set the system timer resolution to the minimum (on windows)
This lessens the “jerky” feel the rendering had to when running under native Windows and puts it almost on-par with the Linux one. 🙂
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.
– 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. 🙂