This adds code for handling fixed function fragment processing with the
GL_ATI_fragment_shader extension. This is a sort-of programmable
interface for fragment processing at the level of shader model 1.4 in
d3d. This code is of use on r200, r250 and r280 cards(radeon 8500 to
9200) which do not support GL_ARB_fragment_program, but support pixel
shader 1.4 on Windows. This code is somewhat a counterpart to the
existing fragment processing code using GL_NV_register_combiners and
GL_NV_texture_shader.
The whole control structures in directx.c get terribly confusing with
the various codepaths for texturing and different shader
implementations. It is also hard to reflect the shader model
decisions this way too. This patch moves the shader specific parts of
the caps code into the shader backend where we can set our caps
dependent of the shader model decisions and without complex caps flag
checks.
Generating the shader ID and parts of the shader prolog and epilog was
done by the common vertexshader.c / pixelshader.c, which is ugly.
This patch doesn't get rid of all the uglyness, somewhen we'll still
have to sort out the relationship of [arb|glsl]_generate_shader and
[arb|glsl]_generate_declarations.
Add a new property of the shader backend which indicates whether the
shader backend is able to dirtify single constants rather than
dirtifying vshader and pshader constants as a whole. Depending on this
a different Set*ConstantF implementation is used which marks constants
dirty. The ARB shader backend uses this and marks constants clean
after uploading.
The GL_ARB_vertex_program extension does not define a standard value for
output texture coordinates. This makes problems when using vertex
shaders with fixed function fragment processing because fffp divides the
texture coords by its .w component. This means that gl shaders have to
write to the .w component of texture coords. Direct3D shaders however
do not.
I'm resending this patch because my reply to Henri's concern came too late.
Henri noted that I am enabling lights that do not exist. Existing tests show
that if no light is assigned to the index, LightEnable creates a light with a
set of default parameters, so the tests should be fine.
From 9ee4c61805b50886f79e87d744b52f27b7b00b4e Mon Sep 17 00:00:00 2001
From: Stefan Doesinger <stefan@codeweavers.com>
Date: Thu, 29 Nov 2007 13:22:47 +0100
Subject: [PATCH] WineD3D: Enabling too many lights is silently ignored
This patch adds tests for all d3d versions that show that Windows
pretends that enabling more lights than supported succeeds. D3D_OK is
returned, and the light is reported as enabled.
What is not tested in this patch is the rendering output of this
situation, thus the FIXME is still written.
If an attribute has type D3DDECLTYPE_D3DCOLOR, the red and blue channels
are swizzled in the shader. Since the attribute is stored in the vertex
declaration and not the vertex shader, it can change by setting a new
vertex declaration. If this happens, we have to recompile the shader
with the swizzling of that specific attribute turned on or off.
Alexander Dorofeyev