Patch for vertex > 4 shaders

[Chris Ahrendt]

Chris Ahrendt wrote:
>  >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
> 
> 
> 
the last comment I meant to say it ignores the types and calls it with 
all floats... not that it ignores it =)

chris