Tag: cross-compiling

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. 🙂

– 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. 🙂