Ramblings about hobbyist game development
– specify the right shader type when setting the push constants for the model pipeline
– transfer the dummy texture data to the right image layout type, even if it is unused
This fixes some Vulkan errors/warnings, nothing particularly exciting about that, besides that Vulkan is sometimes surprisingly lenient.
– use the same cmake changes as for cross compiling when doing native windows builds
– make sure to always pick discrete GPUs, if available
– properly initialise the maximum number of descriptor sets for the model pipeline
– increase API requirement for Vulkan from 1.0 to 1.1
– properly pass device features when creating a logical Vulkan device
– when allocating aligned memory under windows make sure to only pass alignment values that are powers of two
– change the buffer sharing mode from concurrent to exclusive (for now, ensure there are no problems due to that)
Hello! This required to set-up a complete development environment under Windows, after throwing away the somewhat naive hope of being able to simply run the cross-compiled binary, it required a fair but of debugging to be able to run.
After setting up the environment, most tasks revolved around Vulkan specific issues, that made me seriously wonder how some things worked under Linux in the first place, only one memory issue was an actual platform issue and luckily pretty quickly solved. 🙂
At the end of this we finally run OLives under Windows, albeit without any selections, besides the UI. It is also pretty crash-happy, but it starts!
– Refactor names of enum class members to camel case
– Move some more existing enums into enum classes
– Fix some implicit VkImage => vk::Image conversions
– Do not use plain C types (ushort/uint)
– Fix mingw build
A little respite before going for the finish line of the door/window project. This commit is not all that exciting sounding, but this enables building OLives for the Win32 (64, actually) target again. With some tweaking it is actually building again, however, it does crash when trying to fully initialise the Vulkan code.
Hopefully there’ll be more to report in form of a screen shot soon. 🙂
– Apply the same selection colour to the portals as the surrounding wall piece
– Re-work how selection states are shown on models (use the extra flags as opposed to piggy backing in another variable)
– When hiding portals altogether, do it in the vertex not the fragment shader
Now, when hovering over a portal (door/window) the same mechanisms are triggered as if the user was hovering over the surrounding wall.
Additionally, the hover state handling was improved quite a bit, so that the portal models now also reflect the current state. As the portals are drawn like any other model, these changes also affected how the object preview models are drawn – a nice side effect as how the selection state was brought to the shader was more than a little hacky until now.
Visually it does not look like much, but a nice improvement nevertheless, check it out below:
– Use the CHANGE_POSITION message to determine if there are doors in the way of an object in order to hide it
– Use the same message to reset the other three positions
– Fix regression in python bindings introduced by new optional parameters in the addJobMessage function
Building on the previous commit this wires everything up to finally hide/show doors so that objects no longer go through visible doors in T-1000 fashion.
Check it out in the video! 🙂
– Implement a way to detect when an object moves from one logical tile to another
– Parse and pass through vertex colour values from the IQM loader to the shader
– Implement hiding of vertices with an rgb value of (255, 0, 0) which will be used to hide certain vertices in doors when an object passes through (WiP)
The TODO list about portals keeps getting shorter. This commit paves the way for hiding doors (and not the door frames) while the surrounding wall is fully drawn.
This is/will be realised by hiding certain vertices, namely everything except the door frame when an object passes through them. This commit provides the building blocks for that by
For the time being this state is currently always enabled to test the hiding mechanism, it currently looks like this:
Hide portals (doors/windows) when the surrounding wall piece is hidden
The portal saga continues – but we are getting closer to the end of it. While at first glance the portals and the surrounding walls are a unit they are actually drawn very differently, as the portals themselves are actually models, while the wall pieces are geometry which is calculated programmatically.
This distinction requires a special solution to determine when portals need to be hidden. Luckily, the code that determines whether a given wall piece needs to be drawn lowered could be refactored and re-used, getting the information into the shaders was slightly more tricky, but it got there in the end. Check it out below! 🙂
– Use references where appropriate
– Properly clean up all non-used objects in the UI render pipeline
As mentioned in the previous post this commit was all about performance improvements (or regressions). Luckily the changes were rather trivial, but had promising effects:
These two screenshots were taken after randomly switching around between the game modes as quickly as possible for 30 seconds.
While not exactly very scientific, we can see a big difference in the CPU load, as data structures weren’t properly discarded in the UI code before (among other problems). So I’m back in the door/window business and can hopefully quickly finish this up. 🙂
– Draw portal models
– Make sure to always reset portal data as well when removing a wall piece
While the second of the two changes here gets more space in the commit message, the first one is arguably the more exciting one, check out the screen shot below!
A bit of bad news though: when that screenshot was taken the CPU usage was up considerably and the input (when rotating) started feeling a bit sluggish. This is in all likelihood not related to the door/window topic but something that crept in over time and went unnoticed, as usually test runs of OLives focus on a very specific feature without much further interaction.
Long story short, before doing the finishing touches on this topic I will have a look at those performance issues.
– Fix drawing of the “lower” state of wall meshes that have portals
– Change the path finding so that it also considers walls with doors
Until now there were some, to say the least, odd things happening visually when showing the wall pieces that included doors/windows in the “lowered” state. Luckily, that has been fixed now!
A lot easier to fix, but equally nice is that finally the path finding treats walls with doors in them as navigable, check out the video to see this in action! 🙂