These days you could just ask a bot to port your stuff from OpenGL to a newer API.
Backward compatibility is less of an issue when fixing legacy stuff takes $25 in tokens.
Backward compatibility is less of an issue when fixing legacy stuff takes $25 in tokens.
> Comparing traces, the render pass "OpenGL mode" sets an unknown bit in this kernel-processed block. If we set the same bit in our OpenGL driver, we find the clip space changes to -1/1.
Edit: I guess no, Angle is OpenGL ES. My bad.
In practice this is sufficient for the overwhelming majority of apps. Apple never went past GL 4.1 on the desktop side, and doesn't support most of the interesting desktop-only features (tessellation and geometry shaders, mostly), so ES 3.1 targets desktop macOS fairly cleanly.
The point of OpenGL was to have an API universally supported everywhere
Both are os-specific graphics apis. It seems pretty comparable to me.
Also, see pjmlp's comments. Everything he said is spot on.
That was always more like a dream than reality. OpenGL implementations between GPU vendors and platforms all have significant "implementation defined behaviour", interesting bugs and different performance "hot paths". And as soon as you need to start using extensions, portability is out the window anyway. Even setting up a GL context across different operating systems (e.g. the very first thing every GL application needs to do) is a royal PITA unless bringing in additional helper libraries like GLFW or SDL.
Arguably the only actually portable GL flavour is WebGL.
It shouldn't be user's responsibility to have to get their binaries to work at all costs.
/s