This is vkQuake3 running on macOS 10.14 using gfx-portability with Metal backend.
2 Likes
Hmm, I suppose it looks just like a GL version of ioQuake3. 
Here is a bit of init log for proof:
Active 3D API: Vulkan
Vk api version: 1.0.66
Vk driver version: 1
Vk vendor id: 0x0 (unknown)
Vk device id: 0x0
Vk device type: DISCRETE_GPU
Vk device name: Intel(R) Iris(TM) Graphics 550
---------- Total Device Extension Supported ----------
VK_KHR_swapchain
VK_KHR_maintenance1
VK_EXTX_portability_subset
---------- -------------------------------- ----------
Vk instance extensions:
VK_KHR_surface VK_MVK_macos_surface VK_KHR_get_physical_device_properties2 VK_EXT_debug_report VK_EXT_debug_utils
Image chuck memory(device local) used: 0 M
Create Staging Buffer: 8388608
Stagging buffer alignment: 256, memoryTypeBits: 0xf, Type Index: 1.
R_CreateImage: *default
--- Device memory allocation ---
alignment: 4, Type Index: 0.
Image chuck memory consumed: 8 M
2 Likes
Wow! And indeed, the project you referred to is really ioquake3 based as it seems, not another vQ3 project!
It was told that Doom 3 comparisons Vulkan vs. OpenGL should increase performance by 30%-50%, I can’t confirm this, but it would be nice to have similar results for ioquake3’s renderer2.
Hopefully the author will maintain Vulkan support for ioquake3 on the long run!
1 Like
It was told that Doom 3 comparisons Vulkan vs. OpenGL should increase performance by 30%-50%,
I’d be interested as well, although my work here is more of a Metal port from Vulkan than Vulkan port from GL 
It would also heavily depend on the architecture and code quality of that Vulkan port, since idiomatically Vulkan doesn’t make things faster - it just gives the author an opportunity to do so.
Hopefully the author will maintain Vulkan support for ioquake3 on the long run!
Apparently, the author indents to eventually merge Vulkan renderer upstream (discourse doesn’t let me link to that for some reason…).
2 Likes
Very awesome project! I was curious to see how this might work on the ioquake3 based game Tremulous, and attempted to port it. I ran into some bumps when porting due to our Tremulous project making use of C++, and this vulkan project being in C, but I did get it working enough to try it out a bit on some maps. In some cases it does look better than renderer2, the fog definitely looks better, although my implementation is in need of fixing as there are noticeable bugs/glitches (also I didn’t get the dynamic library version of the renderer working, only the static library build so far).
I’m very interested to see how this vulkan on ioquake3 project develops. I don’t know when I’ll be getting back to working on this for Tremulous, but others are certainly welcome and encouraged to help with fixing it if they would like, regardless for reference here are the links to my commits and to the current opened issue:
2 Likes