Stefan Dösinger wrote:
and those currently fail, because that case isn't handled at all in the FVF loading code. It thinks this is a multi-stream case, when in fact only the 0th stream is used. Jason Green has a demo - dx9_hdr_texture_loader, which is broken exactly by this.
How about getting rid about the fvf in the device entirely and converting the fvf to a vertex decl in SetFVF?
That's what I was suggesting in the next sentence of that email :)
This would make the drawprim code simpler(only vertex declaration to consider) and avoid inconsistency. In GetFVF we convert the declaration back to a FVF(and propably cache the result, but don't use that for rendering).
Well, caching is already accomplished by storing the FVF [ so no need for backwards conversion]. Furthermore, the backwards conversion isn't very clear at the moment - the tests show that almost all FVF fields are 0'ed when a declaration is implicitly converted to FVF by windows. I have no idea why that is yet...