Add support for importing correct Vulkan types#40
Merged
hazeycode merged 2 commits intozig-gamedev:mainfrom Oct 4, 2025
Merged
Add support for importing correct Vulkan types#40hazeycode merged 2 commits intozig-gamedev:mainfrom
hazeycode merged 2 commits intozig-gamedev:mainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR adds support for importing external Vulkan types to improve type compatibility with popular Vulkan implementations like vulkan-zig. The changes enable users to optionally provide their own Vulkan module to resolve type mismatches between zglfw's default opaque types and more sophisticated typed Vulkan handles.
- Added a build option
import_vulkanto enable external Vulkan type imports - Replaced hardcoded Vulkan type definitions with conditional imports
- Updated Vulkan-related function signatures to use the imported types
- Modified
getInstanceProcAddressto return the function directly without error wrapping
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| build.zig | Adds new enable_vulkan_import build option for conditional Vulkan type importing |
| src/zglfw.zig | Implements conditional Vulkan type system and updates function signatures to use imported types |
| README.md | Adds documentation for Vulkan usage with example build configuration and fixes spelling error |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR adds the ability for users to add their own module, which will be used to determine correct types for Vulkan implementation.
Most popular Vulkan implementation in Zig is vulkan-zig (made by Zig maintainer), and it uses fancy
enum { .null_handle = 0, _ }types to add type checking to Vulkan opaque handles. This creates some type mismatches with zglfw.First, thank you, @Fincap, for providing initial implementation. I had to change
getInstanceProcAddressto not be wrapped in zglfw error handling. This function will be passed to the other C libraries (i.e. VulkanMemoryAllocator) , and should not return Zig error union. (Also, this happens with OpenGL #33).There are few additional issues here.
VkAllocationCallbacksisn't opaque. It has defined format, which users can supply.createWindowSurfacereturnsError.APIUnavailablefor any result besidesVK_SUCCESS. That isn't true if for exampleVK_ERROR_OUT_OF_DEVICE_MEMORYis returned (docs with possible results).I have tested this in Vulkan app with vulkan-zig and OpenGL app to see that everything still works.