Find a way to systematically implement OpenGL state accessor functions

[hikari-no-yume]

There are a lot of things that could be improved about the GLES-1.1-on-GL-2.1 layer we have right now. This issue is about one of the areas that most badly needs attention.

This commit is a good example of the problem: https://github.com/hikari-no-yume/touchHLE/commit/8e9eb0c02f118cc0bb83a599bbf9cb69530fbdf2. (Warning: glTexEnv's documentation (both for GLES 1.1 and for GL 2.1) is a nightmare to try to comprehend if you need to know the names and types for the parameters it can set. Thankfully, there is a more helpful listing in the State Tables section of the GLES 1.1 specification.)

OpenGL has a lot of function families following a pattern like:

glFooBari(GLenum target, GLenum pname, GLint value);
glFooBarf(GLenum target, GLenum pname, GLfloat value);
glFooBarx(GLenum target, GLenum pname, GLfixed value);
glFooBariv(GLenum target, GLenum pname, const GLint *values);
glFooBarfv(GLenum target, GLenum pname, const GLfloat *values);
glFooBarxv(GLenum target, GLenum pname, const GLfixed *values);

These are all interchangeable! This makes it difficult to systematically handle every possibility. Among other things, our layer must:

• Validate that the parameter name (enum value) is one we support.
• Find out how many values should be associated with that parameter.
• Support using mismatched integer/float types and letting the runtime convert (integer -> float, float -> integer).
• Support using fixed-point types and doing the conversion ourselves (float -> fixed-point).
• Support using mismatched fixed-point types and not doing any conversion ourselves (fixed-point reinterpreted as integer). Yes, that's what the standard requires…
• Do all of the above both for single-value and multiple-value cases.

I think glTexEnv is the only function family that actually does all of these right now, and it's very verbose. It wasn't much fun to write and it's difficult to read it and be sure it's correct.

At the very least we probably need some helper macros, but I wonder if we could somehow generate the code programmatically. I'm guessing the state tables aren't available in a machine-readable format, though. 😢

[hikari-no-yume]

11bf28a1364f770c64047cd8f985a5900db81e8b, b646fde03179cf997aff73543e2551cbff2fe0cf, 9fb22d65938e14339d7b8764c052b5ac265f5fd8 and 065c47c2d1b2174a4457c93653a79254e0ba46db make some progress towards a systematic approach. There's now a standard type (ParamTable) that can be used to query type info for parameters, and it can do most of the work of implementing the dreaded fixed-point accessors.

[hikari-no-yume]

Relevant: https://github.com/KhronosGroup/OpenGL-Registry/issues/571.