2010-09-07, 02:07 AM
I'm still trying to focus on the .mdl related stuff, but I think I've also begun working on a fairly involved vertex shader framework.
I think everything Som needs can just barely fit into the minimum number of Vertex/Pixel Shader 1.0 registers (96) which is guaranteed by the standard to be on any card that does programmable shaders at all.
extern int vsWorldViewProj[4];
extern int vsWorldView[4];
extern int vsInvWorldView[4];
extern int vsWorld[4];
extern int vsInvView[4];
extern int vsTexture0[4];
extern int vsFogColor;
extern int vsFogFactors; //start/end/density
extern int vsMaterialAmbient;
extern int vsMaterialDiffuse;
extern int vsLightsAmbient[16];
extern int vsLightsDiffuse[16];
extern int vsLightsVectors[16]; //point (w=1) / directional (w=0)
extern int vsLightsFactors[16]; //range/attenuation (dir=1,0,0)
I say barely but Som probably does not require a couple of these and I've allotted space for 8 additional lights in case the number of on lights can be increased via an extension.
So very likely even quite old cards can support a dither shader and other effects once the vertex shader is setup.
Basically the Direct3D code will just blindly track these values if they're assigned to registers, then there is a shader override framework so the game can swap in its own shaders at the right moments. I don't mix anything Som specific with the D3D code so that the code could be adapted to other games. If the D3D code had to manage it's own shaders it would be impossible to manage, but I think Som only has about three distinct rendering states (one for 3D stuff, one for transparent 3D stuff, and one for the overlay sprites) so that's not so bad.
Tracking all of those variables is still a lot of work. After this is working it should really open up some possibilities, however perhaps more interestingly it could make a more or less direct port to D3D10 conceivable.
I think everything Som needs can just barely fit into the minimum number of Vertex/Pixel Shader 1.0 registers (96) which is guaranteed by the standard to be on any card that does programmable shaders at all.
extern int vsWorldViewProj[4];
extern int vsWorldView[4];
extern int vsInvWorldView[4];
extern int vsWorld[4];
extern int vsInvView[4];
extern int vsTexture0[4];
extern int vsFogColor;
extern int vsFogFactors; //start/end/density
extern int vsMaterialAmbient;
extern int vsMaterialDiffuse;
extern int vsLightsAmbient[16];
extern int vsLightsDiffuse[16];
extern int vsLightsVectors[16]; //point (w=1) / directional (w=0)
extern int vsLightsFactors[16]; //range/attenuation (dir=1,0,0)
I say barely but Som probably does not require a couple of these and I've allotted space for 8 additional lights in case the number of on lights can be increased via an extension.
So very likely even quite old cards can support a dither shader and other effects once the vertex shader is setup.
Basically the Direct3D code will just blindly track these values if they're assigned to registers, then there is a shader override framework so the game can swap in its own shaders at the right moments. I don't mix anything Som specific with the D3D code so that the code could be adapted to other games. If the D3D code had to manage it's own shaders it would be impossible to manage, but I think Som only has about three distinct rendering states (one for 3D stuff, one for transparent 3D stuff, and one for the overlay sprites) so that's not so bad.
Tracking all of those variables is still a lot of work. After this is working it should really open up some possibilities, however perhaps more interestingly it could make a more or less direct port to D3D10 conceivable.