Hmm. Does the application use a fixed function texture coordinate specified with D3DECLUSAGE_FLOAT4?
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 ??? D3DDECLTYPE_DEC3N ??? D3DDECLTYPE_FLOAT16_2 2 D3DDECLTYPE_FLOAT16_4 4
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.
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.
I could not answer that it uses a drawprim float 4 before it calls drawprim with the 7 parm. I started to work on a better fix for this rather than the one where I just added the extra values in. But the extra values seemed to solve it. While I am not sure its behavior on windows calling the same call (whatever that call is).
Correct in some cases the vertex is a short or a byte that must be normalized. However I am assuming or assumed that that is done by the application calling the API and not the actual API itself. This assumption seems to work but not 100% sure as I don't know how it works on windows.
The DEC 3 and DEC3N specify 3 variables q,r,t with the 4th being I think the link said a 1. The N specifies if the values are normalized.
Chris