Vulkan compatibility

[jclc]

It would make sense for this library to support both OpenGL and Vulkan coordinate systems. One difference that comes to mind is that screen coordinates in Vulkan range from 0 to 1 instead of -1 to 1 like in OpenGL.

[UserAB1236872]

This is a bit tricky, not in execution but in design. Unfortunately, since Go doesn't have optional arguments or overloading, we can't make a version of each method where you can specify coordinate ranges without breaking compatibility.

To give context, this library was initially created when I was trying to follow some OpenGL tutorials in Go, and needed a math library. Vulkan hadn't even been announced yet IIRC (at the very least, it hadn't been released), so it's not a surprise it's not compatible.

I'm not hostile to the idea, but I'm not sure what a satisfying solution is. One is to add two new targets to the generation: mgl32_vk and mgl64_vk (mvk32/64?). The other is to add a matching method for each function that uses coordinates with a VK suffix, or at least a coordinate-agnostic one that lets you pass in your min/max (as well as testing to make sure a min of 0 doesn't divide by zero or something). I see drawbacks to both approaches.

[jclc]

As far as I know, only the screen coordinates are different in Vulkan. Texture coordinates are also flipped to be more in like with Direct3D, but that's unrelated to mathgl. All other functionality should be identical. I'll fork the library and make a pull request once I iron out the details.

[galsjel]

What about naming schemes like matrix_gl.go and matrix_vk.go with build constraints as described here?

https://golang.org/pkg/go/build/#hdr-Build_Constraints
https://stackoverflow.com/questions/36703867/golang-preprocessor-like-c-style-compile-switch

Then you could build the library specifically for Vulkan adding the -tag to the go build command with something like MGL_VK.

[jclc]

Hi, since making this issue, I've personally come to the conclusion that adding separate Vulkan functions isn't worth the effort when you can just multiply your transform matrix so that the coordinates match. For example, I'm transforming my matrices on every frame to change my game's coordinates to use Blender's coordinates and adding a matrix on top of that to change from GL coordinates to Vulkan coordinates doesn't cost anything.

At the very least having to build the whole library with a build tag just for that sounds like a bad idea, to be honest.

I'll leave the issue open in case the maintainers still want to consider this, but personally I don't think it's something this library really needs.