https://bugs.winehq.org/show_bug.cgi?id=45468
--- Comment #6 from Henri Verbeet hverbeet@gmail.com --- (In reply to Andy Clayton from comment #5)
I am just picking gl and d3d up again so I have to do some more reading and experiments to have a guess at what is going on with ffp_varying_diffuse's alpha. Or if you have any more insights to share that would also be great. I have been meaning to attach logs but need to cut them down to a reasonable size without losing anything important.
With GLSL disabled, you should be getting ARB_fragment_program shaders for FFP (fragment) emulation. Those should be equivalent to the GLSL code, but it may make sense to explicitly verify that.
We do use fixed-function vertex processing with GLSL disabled. The code for setting that up is select_vertex_implementation(), select_fragment_implementation() and select_shader_backend(). It should be possible to use fixed-function vertex processing together with the GLSL shader backend by returning "&ffp_vertex_pipe" in select_vertex_implementation(). It may be worth giving that a try, but note that that combination hasn't been used for several years now; it may not work at all anymore.
ffp_material.diffuse ultimately comes from the current material, set by wined3d_device_set_material(). It's probably also a good idea to check the ambient and emissive light and material values, particularly the alpha values. Alpha is usually set to 0.0f for those, but I'm not entirely confident we handle non-zero alpha values correctly there.