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