stefandoesinger at gmx.at
Sat Oct 31 09:58:56 CDT 2009
Am 29.10.2009 um 21:29 schrieb Luis C. Busquets Pérez:
> Dear all,
> Since d3d10effect has advanced a lot during the latest weeks I was
> wondering what are the next steps that you are planning to develop.
I'm still working on d3d9-related stuff only, no guarantees that the
following is correct
> 1. Do DepthStencil and RasterizerState present major differences in
> terms of capabilities compared to D3D9? I mean that coding
> ID3D10EffectDepthStencilVariable is very easy once you have
> ID3D10DepthStencilState (just call
> ID3D10Device_CreateDepthStencilState for
> ID3D10EffectDepthStencilVariable::GetDepthStencilState and
> ID3D10EffectDepthStencilVariable::GetBackingStore should only be
> recovering the data from a private variable).
I see no additional features in D3D10_DEPTH_STENCIL_DESC. A
ID3D10Device::OMSetDepthStencilState could just call the proper
IWined3DDevice::SetRenderState calls, or a depthstencilstate could
contain a wined3d stateblock with the proper pre-recorded states.
> Furthermore, ID3D10Device::OMSetDepthStencilState is just a bunch
> of IWineD3DDevice_SetRenderState calls because I think that wined3d
> already implements all the required functionality, doesn't it?.
> ID3D10Device::OMGetDepthStencilState would be a bunch of
> ID3D10EffectRasterizerVariable. presents the analogous thing
> (together with ID3D10Device::RSSetState), doesn't it?
For OMSetDepthStencilState, your idea seems correct, as outloned
above. For GetDepthStencilState you'd probably cache the correct
interface pointer in d3d10core, since an app may create more than one
ID3D10DepthStencilState states and expect the one it set when it calls
> 2. For ID3D10EffectBlendVariable I think that that is different.
> what are the major difficulties concerning the capabilities that
> D3D10 offers compared to D3D9 conerning blending and do you see them
> achievable beofre this year ends?
You'd probably use a ID3D10BlendState for D3D10EffectBlendVariable.
D3D10_BLEND_DESC adds a few new features compared to d3d9.
AlphaToCoverageEnable doesn't exist per se, but there's a MAKEFOURCC
('A','T','O','C') hack ATI and nvidia added(sorta a d3d9 "extension").
ATOC is supported by opengl multisampling afaik. So the proper way is
probably to add a proper state to wined3d, and implement the atoc hack
in d3d9(using the newly added wined3d state), and also use this state
The separate blend enable isn't supported by wined3d yet, but you can
just add new render states and implement them via
GL_EXT_draw_buffers2. Should be pretty easy, unless EnableIndexedEXT /
DisableIndexedEXT complain if you enable/disable blend on a color
target that's not defined in the current FBO, which would tie blending
to the render target setting.
> 3. Last, for ID3D10Device::RSGetViewports/
> ID3D10Device::RSSetViewports and ID3D10Device::RSGetScissorRects/
> ID3D10Device::RSSetScissorRects, the difficulty may lay in accepting
> in the wine driver more thatn one rect/viewport. Do you agree? Are
> you planning an upgrade in wined3d to refer to *rect rather than
> rect in the stateblock definition? The analogous question applies to
Adding different viewports to wined3d and passing them to the
according GL function isn't too difficult - make the viewport and
scissor rect states arrays in wined3d, and modify the Getters,
Setters, stateblock apply/capture and state applying code accordingly.
What may be more difficult is finding the right GL functions. This is
not related to the functionality added by GL_EXT_draw_buffers2. From
the MSDN docs, it seems to be related to geometry shaders, but on a
quick search I couldn't find any hints in GL_EXT_geometry_shader4 and
More information about the wine-devel