Jules Blok

I think you should just use the encapsulated GL texture, perhaps through a fork on wine. That also makes it possible to submit OpenVR-support as a patch to wine at...

I wouldn't really call OpenVR an MS app, but I do see your point. Perhaps once OpenXR is ratified wine could support translating OpenXR calls to native SteamVR.

I'm still betting on native OpenXR support in wine once it's ratified. In which case if it would make more sense to translate OpenVR to OpenXR if that's needed.

> That means, from a graphics API perspective, Wine implementing OpenXR will most likely only change who's solving the problem, not the problem itself. If Wine implements OpenXR they would...

This seems redundant, why not just add MacOS to the `BUG_BROKEN_DUAL_SOURCE_BLENDING` in the driver details and update the description to make it more general?

D3DX Math functions are being used heavily in the sun shadow mapping code, however those functions already have equivalents in the XRay Matrix classes. As part of the OpenGL port...

That's pretty good, I can probably make use of that in the OpenGL port, will make the code a bit cleaner. This is how I did it in OpenGL: https://github.com/Armada651/xray-16/blob/opengl/src/Layers/xrRenderGL/glBufferUtils.cpp

There's still an OpenAL backend that we can port to Linux, right?

This change only affects threads that would previously be marked as "Unknown", it doesn't affect threads that have an actual name associated with them. I don't actually use the thread...

It should be possible to fix this issue without the need for the hexchat core using the same patch used in the Ubuntu repository, please see the above PR.