* GL_TEXTURE_MAX_LEVEL acts as a bound on the number of mips for either
immutable or non-immutable textures. Instead for non-immutable textures
we do the standard mip calculation and that's what's necessary for a
"complete" texture.
* This way if someone updates their install without clicking the menu item
to clear this flag, it will still detect the update after a few days.
* (And when I forget to update which beta is latest, it will fix itself
eventually. Oops).
* I need to investigate this more. It seems that on AMD the compressed
image size returned is the size of the whole cubemap, and then you get
each face one-by-one. On nVidia the compressed image size is the size of
one face, so dividing by 6 gives too little space.
* I don't know which one is standard correct, but that kind of doesn't
matter since I probably need to query the size for maybe a 1x1 cubemap
or a known dimension & compression format (like BC1 1 byte per pixel).
* This won't work if the feedback is started before the captured frame then
captured inside it, either by being paused or actually active across the
SwapBuffers call.
* ie. not just an unnormalised mantissa plus biased exponent, it has proper
IEEE style float properties with hidden bit on the mantissa etc. So full
decoding is necessary, contrary to what some of the docs say :(.
* Note that the uniform subroutines are saved and restored by the render
state, but they are not properly restored anywhere where we fetch &
restore the current program. Will probably need a special helper class
to push/pop that correctly.
* We want the application to pass us real GLSL shaders so we can do all
kinds of juicy things to them. This is generally indicated by the program
having a LINK_STATUS of FALSE or similar, and we can pretty much get that
by just not passing through the call.
* This means that all APIs pass byte string types. ALL strings everywhere
in the entire codebase must be assumed to be and treated as UTF-8 content
not ASCII.
* Gets rid of all the horrible %hs specifiers that caused warnings on
linux! Hooray.
* We convert to wide strings, or use wide characters, only when necessary
to use the Win32 API. Some windows specific code will stay in wide chars
just for convenience.
* Files are already serialised as UTF-8 strings for linux/windows binary
compatibility, so this change doesn't break backwards compatibility.
baldurk