This causes memory corruption on MacOS, even if the app does not
reference undeclared arrays. Trying to avoid potential breakage in
broken apps which provoke undefined behavior is pointless if it causes
actual breakage in well-behaved apps (on ill-behaved drivers).
The view matrix that was set at the time the clipplane was applied is
hardcoded into the clipplane. With vertex shaders clip planes ignore
the view matrix in d3d. We implement that, but this also means that
the clip planes potentially change when we switch between vs and fixed
func.
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.
Add a new wined3d-internal PreLoad function to textures and surfaces
that takes a parameter specifying wether the rgb or srgb texture
should be loaded.
This reduces the number of srgb switching reloads quite a lot. The only
situation in which a reload is needed is if the rgb copy is modified on the GL
side and the srgb copy is needed.
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
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.
Most callers work on a stateblock rather than a device, and the main fields
we check (vertexShader and pixelShader) are part of the stateblock as well.
This is a first step towards cleaning up the fog mess. The fog
parameter is added to the pixelshader compile args structure. That way
multiple pshaders are compiled for different fog settings, and the
pixel shader can remove the fog line if fog is not enabled. That way
we don't need special fog start and end settings, and this allows us
to implement EXP and EXP2 fog in the future too.
Based on a patch by Stefan Dösinger. This is more flexible, and allows
the shader backend implementation to be simpler, since it doesn't have
to know about specific formats. The next patch makes use of this.
A number of considerations contribute to this:
1) The shader backend knows best which shader(s) it needs. GLSL needs
both, arb only one
2) The shader backend may pass some parameters to the compilation
code(e.g. which pixel format fixup to use)
3) The structures used in (2) are different in vs and ps, so a
baseshader::Compile won't work
4) The structures in (2) are wined3d-private structures, so
having a public method in the vtable won't work(its a bad idea
anyway).
Add a test that checks what happens if D3DRS_POINTSIZE, D3DRS_POINTSIZE_MIN
and POINTSIZE_MAX have conflicting values. D3DRS_POINTSIZE_MAX trumps
D3DRS_POINTSIZE_MIN, and both MIN and MAX clamp the D3DRS_POINTSIZE value if it is
outside of their range.
GL_ATI_envmap_bumpmap provides two things: Signed V8U8 pixel formats,
and bump mapping. The extension is only supported on fglrx, and this
driver also supports GL_ARB_fragment_program. Thus the bump mapping
code is never used on any driver out there. Furthermore, if it is
used, it tends to crash the driver
The signed pixel format is used, as it can be used by pixel shaders or
the ARBfp replacement. However, the format is broken in fglrx, and
negative values are clamped to 0.0. This results in test
failures. WineD3D has an alternative codepath using scale+bias to
enable V8U8 using a standard signed RGB which works correctly on
fglrx.
Turns out the original fix was correct for fixed function, but for the
wrong reason. The shader path was already correct. This fixes a
regresssion introduced by 932e95c111.
GL_ARB_fragment_program and GL_ATI_fragment_shader can disable
projected textures properly, and they can also handle
D3DTTFF_PROJECTED | D3DTTFF_COUNT3 properly.
ARB and GLSL don't need that. If a shader backend like atifs or nvts
need it in the future, the shader backend should deal with that rather
than the ffp pipeline.
If a format is not supported natively by opengl, a shader may be able
to convert it. Up to now, CheckDeviceFormat had magic knowldge which
GL extensions lead to which supported format. This patch adds
functions that allow CheckDeviceFormat to ask the actual
implementation for its capabilities.
ATI cards prior to the radeon HD series did not have unconditional non
power of two support. So far we've used texture_rectangle for that, or
created a bigger power of two texture with padding. This had the
disadvantage that we had to correct the coordinates, which causes
extreme problems with shaders(doesn't work, pretty much).
Both the MacOS and the fglrx driver have support for
GL_ARB_texture_non_power_of_two, and run it on the hardware as long as
we stay within the texture_rectangle limitations. This allows us to
have conditional non power of two textures with normalized
coordinates. This patch adds an internal extension, and the code
creates a regular GL_TEXTURE_2D texture with NP2 size, but refuses
mipmapping, filtering and texture_rectangle incompatible
operations. This makes np2 textures work with shaders on fglrx and
macos.
The opengl extension mentioned in that code was never finished, and as
far as I know there is no way to make use of tangent data in the d3d
fixed function pipeline as well.
Note that GL_ATI_envmap_bumpmap is not the same as
GL_ATI_fragment_shader. envmap_bumpmap is used together with the
regular opengl ffp pipeline and is not used (other than for
pixelformats) if GL_ATI_fragment_shader is used.
This patch adds a new field to the state templates. If this extension
field is != 0, then the line is only applied to the final state table
if the extension is supported. Once a line is applied to the final
table, all further templates for this state from the same pipeline
part are ignored. This allows removing some extension checks from the
state handlers, which cleans them up and saves a few CPU cycles when
applying the states.
As long as we have the shader constants in misc, it is best to keep
all the code that affects shader constants, like bumpenvmat setting,
in there as well.
This code creates the structures and the pipeline selection, as well
as the caps filling. It does not yet move the actual code around,
since this will be a bigger task.
When a sampler is changed and unconditional NP2 textures are not
supported, the texture matrix may need adjustment. The sampler state
function checks for that, and calls the texture transform setting
function in that case. However, samplers are a misc state, and the
texture transform flags a vertex state. Thus split up the code and
move the matrix changes to the vertex side.
Since atifs is only doing the fragment pipeline replacement right now
there is no need for the shader backend structure any longer. The ffp
private data is stored in new fragment pipeline private data(which
could potentially be set to equal the shader private data if needed).
It isn't related to the shader backend any longer. The nvts_enable in
the ffp code isn't quite right as well, it should be moved away once
there is a dedicated nvts fragment pipeline replacement
For now the atifs selection sticks to the old rules, thus it is bound to
the available and selected shader capabilities. We may want to change that
in the future.
The idea of this patchset is to split the monolithic state set into 3
parts, vertex processing, fragment processing and other states(depth,
stencil, scissor, ...). The states will be provided in templates which
can be (mostly) independently combined, and are merged into a single
state table at device creation time. This way we retain the advantages
of the single state table and having the advantage of separated
pipeline implementations which can be combined without any manually
written glue code.
glStencilFuncSeparateATI does not take a face argument, instead it
sets the front and back facing functions at once. This means the
renderstate_stencil_twosided helper function is somewhat pointless for
this extension.
Henri Verbeet