On Mon, 25 Feb 2019 at 12:51, Józef Kucia joseph.kucia@gmail.com wrote:
I'm not sure about the exact design, but I think it would be preferred to introduce an abstraction in wined3d for the state translation to new d3d11-like state objects. Mainly because, there are no reasons to duplicate code in client libraries, and the state translation won't be entirely trivial, e.g. we need some caching mechanism for the state objects. I expect that d3d9_device_SetRenderState() should just call some wined3d helpers methods. In theory, the state translation code could even reside in a separate library outside wined3d, but we don't have strong reasons to introduce a new library.
Also, I don't think that we want to create rasterizer and blend state objects in d3d9_device_SetRenderState(). We should create and set state objects just before draw calls.
You may want to ask Henri for his opinion. Hopefully, it aligns with my description.
Yeah. I'd put this in roughly the same category as the wined3d_private_store helpers. I think it's fine for the wined3d_stateblock_state structure to be in the public header, but probably not the details of wined3d_stateblock itself. State object extraction should happen on draws.