Patch for vertex > 4 shaders

[Chris Ahrendt]

 >Hmm. Does the application use a fixed function texture coordinate 
specified
 >with D3DECLUSAGE_FLOAT4?

I don't know I can look in my logs and see if I see it...
but don't remember off the top of my head at the moment.

 >It should be simple to support this. Essentially the "int coordsToUse =
 >sd->u.s.texCoords[coordIdx].dwType + 1" is wrong, this needs a better 
mapping:

 >decltype:                   coordsToUse:

 >D3DDECLTYPE_FLOAT1          1
 >D3DDECLTYPE_FLOAT2          2
 >D3DDECLTYPE_FLOAT3          3
 >D3DDECLTYPE_FLOAT4          4
 >D3DDECLTYPE_D3DCOLOR        4
 >D3DDECLTYPE_UBYTE4          4
 >D3DDECLTYPE_SHORT2          2
 >D3DDECLTYPE_SHORT4          4
 >D3DDECLTYPE_UBYTE4N         4
 >D3DDECLTYPE_SHORT2N         2
 >D3DDECLTYPE_SHORT4N         4
 >D3DDECLTYPE_USHORT2N        2
 >D3DDECLTYPE_USHORT4N        4
 >D3DDECLTYPE_UDEC3           3
 >D3DDECLTYPE_DEC3N           3
 >D3DDECLTYPE_FLOAT16_2       2
 >D3DDECLTYPE_FLOAT16_4       4

The app. should pass these in to us already in the correct format

 >Also the function calls below shouldn't be selected based on a 
 >switch-case statement, but rather on the declaration itself. q, r, t 
 >and s should be read in a different way too. The system used for 
 >providing other parameters like diffuse_funcs sounds sane here, 
 >although some extra care is needed to >keep working without 
 >GL_ARB_multitexture support.

ok explain... I am lost here..  like I said earlier I divided it into 
the gl calls (float, int, short) and the screen went a little bonkers...
so any suggestions here would be great =)

Was thinking about it on the trip to the airport and came up with the 
following pseudo code:


switch( vertex shader type)
{
case D3DDECLTYPE_FLOAT1:
                         g = value 1;
                         totalParms =  1;
                         break;
case D3DDECLTYPE_FLOAT2:
case D3DDECLTYPE_SHORT2:
case D3DDECLTYPE_USHORT2N:
case D3DDECLTYPE_SHORT2N:
case D3DDECLTYPE_FLOAT16_2: g = value1;
                             r = value2;
                             totalParms=2;
                             break;
case D3DDECLTYPE_FLOAT3:
case D3DDECLTYPE_UDEC3:
case D3DDECLTYPE_DEC3N: g = value1;
                         r = value2;
                         t= value3;
                         totalParms=3;
                         break;
case D3DDECLTYPE_FLOAT4:
case D3DDECLTYPE_D3DCOLOR:
case D3DDECLTYPE_UBYTE4:
case D3DDECLTYPE_SHORT4:
case D3DDECLTYPE_UBYTE4N:
case D3DDECLTYPE_SHORT4N:
case D3DDECLTYPE_USHORT4N:
case D3DDECLTYPE_FLOAT16_4:
                         g = value1;
                         r = value2;
                         t= value3;
                         s = value4;
                         totalParms=4;
                         break;

default: TRACE("Error\n");
          return;
          break;
}
switch(totalParms)
{
case 1: gl call with 1 parm
         break;
case 2: gl call with 2 parms
         break;
case 3: gl call with 3 parms
         break;
case 4: gl call with 4 parms
         break;
default: TRACE("ERROR\n");
          break;
}

 >Also I strongly recommend writing a test here. Generally, fixed 
 >function attributes with non-standard data types are spooky on Windows,
 >so the real problem may be somewhere else.

Is there currently a test case for this written?  I think on windows it 
just ignores the parms to be honest..

Chris