ps 1.x supports only 8 constants, so the shader load code dirtifies the
first 8 on a shader switch. However, the constant load code reloaded all dirty
consts with clamping. That potentially left constants > 8 clamped.
The code removed by this patch was a leftover from the time when we tried to
emulate MOVA with a plain ARL, which only supports one source in plain ARB.
This breaks the more sophisticated MOVA and 4 component ADDR register we have
now however.
If we have start = 4, count = 3, the highest dirty constant is the one with index 6. start + count gives 7,
so it already includes the zero-based array correction. Don't add an additional 1.
Additionally to the inefficiency of looking at one extra constant, this causes problems if the driver
rejects loading 257 constants on the initial load. In this case no constant is loaded if
GL_EXT_gpu_program_parameters is used.
If the replacement pipeline is used, ARBfp is always on. Disabling it
can break shaders or the replacement pipeline, because the shader and
ffp code assumes the extension is on.
I don't like that I have to do this because the posFixup is in all
vertex programs, so its at the same position and could be loaded
globally. Unfortunately, there are only 256 env parameters usually,
which makes it impossible for any shader to use c256, even if it does
not use indirect addressing, and so we can't claim 256 constant
support.
I find it helpful for debugging to have this controlled at a central place,
without having to disable the entire GL extension or manually find all the
places where GL_SUPPORT(NV_VERTEX_PROGRAM2_OPTION) controls clipplane use. It
is useful for debugging the emulation code on NV cards and for debugging mac
driver issues.
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).
Stefan Dösinger