Re: [1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used

[Ivan Gyurdiev]

Stefan Dösinger wrote:
> Up to now we've been lucky that all the games requireing manual fog coords 
> haven't used vertex buffers, thus we always went through drawStridedSlow. 
> Make sure that the fog also works with vertexbuffers
>
> As for the rejected patches from yesterday, I've moved them back to the bottom 
> of the queue when I fixed them, so I will resend them later.
>
> ------------------------------------------------------------------------

This patch is probably fine, but it makes me look into the surrounding 
code [ software blending, changing the strided data ], which is still 
incredibly misleading. That should go into its own function, with the 
FIXVBO macro removed (since all such macros are evil, without 
exception), and a big comment should be added that named access to the 
strided data is only valid in the fixed function pipeline and will not 
work in the shader pipeline.  Maybe it makes sense to use two different 
structures to make this clearer - not sure.

[1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used

[Stefan Dösinger]

> This patch is probably fine, but it makes me look into the surrounding
> code [ software blending, changing the strided data ], which is still
> incredibly misleading. That should go into its own function, with the
> FIXVBO macro removed (since all such macros are evil, without
> exception), and a big comment should be added that named access to the
> strided data is only valid in the fixed function pipeline and will not
> work in the shader pipeline.  Maybe it makes sense to use two different
> structures to make this clearer - not sure.
> Yes, I think you're right about the macro, a function and a comment. I will 
> make a patch for this. As for the separate structure for named and numbered 
> attribs I am not sure either. We might need extra checks for useVS, but in 
> theory we shouldn't because code that would need them is broken, since it 
> either uses named access with shaders, or numbered access with fixed 
> function.

Another thing to consider is getting rid of the strided vertex structure 
altogether. I am not sure if it will work, or improve things. It may make the 
code simpler and faster to use the vdecl directory, but otoh there's 
IDirect3DDevice7::DrawPrimitiveStrided. We could handle that call with a bit 
of memcpy() calling, this method is hardly used(only one dx sdk sample, and 
the Ogre based 3D games. Ogre has a gl renderer too).