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
- 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.
- 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.
- 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.