In general it might not be a bad idea to group GL specific data into a
separate struct, but IWineD3DSurfaceImpl is currently the only thing that
bothers. It doesn't get it quite right either, since e.g. the PBO isn't in
glDescriptor either.
b2f09fd204 accidentally got the
device->vs_clipping check wrong. The FFP replacement should emulate
clipping if GL can't do this natively with vertex shaders, not the
other way. Also don't emulate clipping if we're using fixed function
vertex processing because (a) clipping is always supported by GL in
this case, and (b), fragment.texcoord[7] is undefined. (Or in the
worst case set to something bad by the app).
Although these formats aren't lockable, we still explicitly set the initial
surface data when creating the texture. Unfortunately that means we'll need
the conversion functions, even though all they'll ever convert will be zeroes.
Many 2.0 and 3.0 shaders end with a "mov oC0, rx". If sRGB writing is enabled,
the ARB backend writes to a TMP_COLOR temporary, and at the end of the shader
writes the sRGB corrected color to result.color. If oC0 is not partially
rewritten after the mov, we can ignore the mov, not declare TMP_COLOR at all,
and just use the rx register as input for the sRGB correction code. This saves
a temporary and an instruction.
This reduces the number of methods in the shader backend(the instr
modifiers can be handled in that wrapper) and it will help flow
control emulation in the ARB backend.
In D3D10 shaders input/output semantics are strings rather than predefined
types. Unfortunately, the code in vshader_get_input() can be performance
critical, depending on application behaviour. Since vshader_get_input() is
only relevant for d3d9 shaders anyway, just store the usage and usage_idx for
these shaders.
This is the Nth attemt to make clipping work with GLSL shaders. The patch now
uses the GLSL quirk table to handle cards that need a custom varying for
gl_ClipPos, and the code is adapted to the changed state table and shader
backend system.
Stefan Dösinger