Formerly, there were "6 frames" with a precalculated change factor on each frame.
This allowed to use Flick Stick exclusively on vsync 60 Hz screens only (6 *
16.6 ms = 100 ms). By using any other refresh rate, or just disabling vsync,
these 6 frames could take any time, normally much less than the intended 100 ms.
Now delta time is used to calculate the angle change on each frame displayed,
so the entire flick duration remains at 100 ms, independent of refresh rate.
Mostly workaround for vkAcquireNextImageKHR errors,
Create more cmdbuffers with slow vulkan implementation could produce
issues when old cmdbuffer is not finished but need to resize dynamic buffer.
Based on
```
Added additional image ready semaphore - this addresses validation errors
when calling vkAcquireNextImageKHR() which started appearing in SDK 1.3.275
```
88009a6149
* Build ref_gles1 only on Linux, it's of limited use under MacOS and Win.
* Fetch openal-soft from Github, the other mirror had several connection
problems in the past.
* Always include the latest curl.dll in Windows builds. Since this isn't
a stripped down build of curl, it's better to have it up to date.
* Make sure that we are on Ubuntu 22.04. Otherwise the binaries wouldn't
work on newer distros when `ubuntu-latest` becomes Ubuntu 24.04.
* Fix some typos.
Workaround for:
Validation Error: [ VUID-vkAcquireNextImageKHR-semaphore-01779 ] Object 0: handle = 0x90000000009, name = Semaphore: image available #0, type = VK_OBJECT_TYPE_SEMAPHORE; | MessageID = 0x5717e75b | vkAcquireNextImageKHR(): Semaphore must not have any pending operations. The Vulkan spec states: If semaphore is not VK_NULL_HANDLE it must not have any uncompleted signal or wait operations pending (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkAcquireNextImageKHR-semaphore-01779) (validation)
Using a more modern opengl code to make this part a little more efficient on modern cards to bind the buffers. We are simply binding and unbinding the buffer when it is full, on modern cards this is fine and perfectly efficient enough, same goes for CPU's.
29595b02f8
