On 2/12/20 00:06, Paul Gofman wrote:
On 2/12/20 00:02, Henri Verbeet wrote:
That won't work; see the way e.g. d3d9_device_SetRenderState() works after Zebediah's recent changes.
I.e., if the application does something like the following:
SetRenderState(..., D3DRS_POINTSIZE, ...); SetRenderState(..., D3DRS_POINTSIZE, ...); SetRenderState(..., D3DRS_POINTSIZE, ...); DrawPrimitive(...);wined3d will never see the first two D3DRS_POINTSIZE values, and will only see the third one once the DrawPrimitive() call is made.
Oh yeah, I just realized that too. So maybe it is better to move the logic to d3d9 and provide blend state object from there? Or maybe just ignore this state triggering logic and let those states behave like normal states until we find an application which wants it the other way?
After a bit of more testing I found out that state blocks favour ATOC state. So it is no straightforward way to deal with it in d3d9 unless we want to add blend object to wined3d state block. The other solution I can think of is to handle ATOC states in wined3d_stateblock_set_render_state(). That is, to introduce an internal blend state object in wined3d_stateblock, update it from wined3d_stateblock_set_render_state() if necessary, and apply STATE_BLEND on state block application.