I think there is one more thing to take into consideration here. I started doing tests for _ProcessVertices() with lighting in ddraw7, and came across a weird thing. It does not treat zero shininess in material the same way as normal DrawPrimitive workflow does. It outputs values like the previously used material shininess is left there, the results for that tests are different from DrawPrimitive() (while the same for the other ones). I suspect we can come across more differences in software vertex processing corner cases and might need to handle raw states a bit different from the hardware drawing pipeline.
On 5/17/19 18:18, Paul Gofman wrote:
Do you suggest to use wined3d_ffp_get_vs_settings() directly? It probably needs some redesign first for that, as it uses gl_info and hardware limits (light count, as well as bitfields in settings structure). Or do you mean factoring out some functions like init_light_sources() to use in process_vertices_strided() and init_light_settings() which would use some more generic structure and parameters not to depend on GL limits?
On 5/17/19 17:45, Henri Verbeet wrote:
Here too, it seems like init_transformed_lights() could reuse most of wined3d_ffp_get_vs_settings().