This was exposed by adding EXT_vertex_array_bgra support, previously we would
almost never hit this because color data being present would already prevent
us from using drawStridedFast(). Thanks to Stefan for spotting this.
The fog settings do not depend on wether the shader writes to oFog or not,
instead they depend on the FOGVERTEXMODE and FOGTABLEMODE settings, and if a
vertex shader is bound at all.
It works the same way as with the fixed function, and having a vertex shader
is the same as using pretransformed vertices, just that the fog coord comes
from the shader instead of the specular color:
FOGTABLEMODE != NONE: The Z coord is used, oFog is ignored
FOGTABLEMODE == NONE, with VS: oFog is used
FOGTABLEMODE == NONE, no VS, XYZ: Z is used
FOGTABLEMODE == NONE, no VS, XYZRHW: diffuse color is used
Other than being a bit nicer than passing function pointers all over the
place, this helps dxgi/d3d10. While the swapchain itself is created in dxgi,
its surfaces are constructed in d3d10core, which makes it impractical for dxgi
to pass the appropriate function pointers.
Doing the levels calculation before the object is created prevents leaking
resources and avoids changing baseTexture.levels after it's been initialized
by basetexture_init().
This prevents fallout from the GL_EXT_fog_coord emulation. glEnable
and glDisable calls other than those that change GL_FOG are not
hooked. The glEnableWINE and glDisableWINE functions can be used to
add other hooks too if ever needed.
Remove some uncessary code and use more descriptive parameter names. Note that
max_vertex_idx isn't the same as "minIndex + calculatedNumberOfindices - 1"
but rather "minIndex + numberOfVertices - 1". calculatedNumberOfindices just
specifies the number of vertices that's drawn, while numberOfVertices
specifies the range of vertices that's drawn.
startIdx should be the first index to draw, either from the vertex
array or the index array, depending on if the draw is indexed or
not. Having both at the same time wouldn't make sense.
We want to know if this happens a lot. If the query is always called
from a different context than the one that created it, occlusion
culling would effectively be disabled, which could have a significant
performance impact, depending on the type of objects being culled.