[6/8] WineD3D: Return a different success value if D3D is not available

Stefan Dösinger stefan at codeweavers.com
Thu Aug 6 11:54:04 CDT 2009

Am Thursday 06 August 2009 14:08:20 schrieb Henri Verbeet:
> 2009/8/6 Stefan Dösinger <stefan at codeweavers.com>:
> > That's why I still think we should use behavior flags as a last resort,
> > and use other problem specific ways where possible and reasonable. (an
> > example for what's not reasonable: Clone the entire private data code in
> > ddraw to avoid the AddRef - I clearly prefer a behavior flag for that)
> Actually, if you wanted to avoid create flags, handling that AddRef in
> ddraw would be less ugly than what patch 4 does. (And no, you don't
> need to clone resource.c for that, just return the flags from
> resource_get_private_data() and its callers, and immediately call
> Release() in the appropriate case in ddraw.)
True, that sounds like an idea.

I still don't see the problem with the SetRenderState(or any other state set 
call) though. For the app CreateDevice and Reset are atomic calls. We have 
full control over the wined3d device. If wined3d's setRenderState suddenly 
gets any new side effects a SetRenderState in CreateDevice is a pretty small 
concern. WineD3D will not start recording a stateblock after creation(in 
which case SetRenderState DOES have side effects¹).

I don't see in which situation it would matter that the WineD3DDevice initial 
state is different from the state we return it to the app. All the app 
bothers about is the D3D8Device's initial state(or reset state), and for that 
the outcome is the same. Thus I am more worried about the number of create 
flags getting out of control than a SetRenderState doing something 

¹: This is why I need a create flag for SetRenderTarget: If a stateblock is 
being recorded, I can neither update the viewport from d3d8/d3d9, nor attempt 
to restore the old viewport in ddraw - the change would go into the recorded 
stateblock, not the initial one.

More information about the wine-devel mailing list