-
-
Notifications
You must be signed in to change notification settings - Fork 428
Inconsistency on Vulkan Format enum #427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This depends on how they're defined upstream. We're fine with upstream-induced breaking changes such as these, but if how we're parsing it is consistent with upstream then it'd be much harder to justify such a break. Will investigate and get back to you. |
Ok so it looks like we actually special-case SNorm here. @HurricanKai do you think it's worth a break in 2.x? Also, should we discuss with the working group as this will affect OpenGL too? |
Can't we just add the |
That would be a very involved change, the current BuildTools pipeline doesn't really suit token overloading like that. |
Don't you think for this case we can just make that change manually? Otherwise I'd be unhappy to break, since |
We can just save this for 3.0, adding a lot of code just for this issue into BuildTools doesn't seem worth it. |
Summary of feature
Currently there's a small inconsistency on the Format enum names. The snorm formats have the
N
capitalized, so they areSNorm
, while the unorm ones aren't.Example:
I propose changing them to:
So basically, changing
SNorm
toSnorm
.For consistency. I hope it's not too late to do this kind of breaking change on the library.
The text was updated successfully, but these errors were encountered: