June 17, 2006
10:19 p.m.
Ivan Gyurdiev wrote: > H. Verbeet wrote: >> On 17/06/06, Vitaly Budovski <vbudovsk(a)cs.rmit.edu.au> wrote: >>> Comments? >> A few points: >> - Taking only the first element of the declaration into account >> seems unlikely to be correct >> - Is there a reason you're using pDeclaration9 instead of >> pDeclarationWine? It would be usefull if dx8 applications worked as >> well. >> - Let's not dump large amounts of code in >> IWineD3DDeviceImpl_SetVertexDeclaration > Ditto. I should note that fixing the fvf -> decl conversion seems > rather important, because the FVF loading code will not work with a > vertex shader at the moment - as far as I can see this will break 3 > more demos, so that brings the count of broken demos up to 5 (ASCII, > Sketch, RollerCoaster, dx9_hlsl_* (2) ). Those demos will set a > shader, and then call SetFVF() afterwards (but > primitiveConvertToStridedData will see that shader != NULL and will > not do anything) Ok I kind of lied here - those demos will not be fixed since they use the DrawPrimitiveUP function, which works differently. However, there are certainly demos which follow this pattern: - setStreamSource[0] - setVertexShader - setFVF - drawPrimitive or drawIndexedPrimitive (not UP variant). 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. Instead of changing the FVF loading code, however, we should just translate it to a vertex declaration, and use the decl loading code.