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
IWineD3DDevice_GetRenderState.
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
the getter.
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
from d3d10.
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
viewports.
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
GL_EXT_gpu_shader4.
