* E.g. this will change GL_TEXTURE_CUBEMAP_FACE_POSITIVE_X to just
GL_TEXTURE_CUBEMAP. We do it once on set rather than everywhere we expect
to use the current type.
* There was a report of renderdoccmd.exe doing --cap32for64 in an infinite
loop on itself (each process trying to inject the previous). I'm not sure
how this could get started, but assuming this was happening automatically
for 'hook into children', try to break the infinite loop by refusing to
inject into our own exes.
* AMD drivers (at least on linux, haven't tested windows) don't recognise
VERTEX_BINDING_BUFFER, so instead we create a dummy VAO with each attrib
bound to the corresponding buffer and then use
VERTEX_ATTRIB_ARRAY_BUFFER_BINDING to query the buffer out.
* For now we just store the highest core version and only re-fetch the
extensions when we see a context of a higher version that before. This is
just working off the assumption that there might be a low-version context
(especially on windows where it's necessary before getting a 3.2+ core
context), but otherwise all contexts will be the same level.
* This is a bit complex. If an application has a global symbol e.g.
GLENABLE glEnable; as their function pointers that they fill out from
glXGetProcAddress, then OUR glEnable global function gets replaced with
that symbol. It's weird. But it means crashes if we try and return the
address of that symbol as a function pointer.
* However it's also possible to get the reverse problem - if an application
has a shared library that has those symbols expecting them to be function
pointers, those symbols will get overridden with our global functions
and it will mean an instant crash when they try to assign to those func
ptrs.
* I'm not sure if there is an ideal fix to this Catch-22, as we also need
to export these bare functions in case someone just plain links against
libGL and expects them to be there, with no GetProcAddress/dlsym funny
business.
* You can choose which component will be used as 'position' when rendering
vertex inputs. Helpful if a position component isn't auto-detected, or
if you want to render UV co-ordinates onto the screen.
* Instead of fixed TEXCOORD0/Color options for solid shading onto the mesh
you can choose a secondary column yourself.
* Also the solid shading options are available on vertex output meshes as
well as inputs.
* Crash report was submitted indicating a crash here, which is either
memory issues or momentarily crazy-large window. We can catch the
exception and just clear to black.
* Until I have a sample that uses it, I'm not going to attempt to serialise
the tiled resource API. It has a lot of other potential knock-ons too
(e.g. to initial contents).
baldurk