Request: Direct3D 10 Layer for Direct3D 9
Direct3D 10 Technology Preview Engine Abstractions / Separation Applications, including Games, that wish to support both Direct3D 9 and Direct3D 10 at the same time need to have the rendering layers abstracted from the rest of the code base. There are many ways to achieve this but key to all of them is the design of the abstraction layer for the lower level Direct3D device. All systems should communicate to the hardware through the common layer which is designed to provide GPU resource and low level type management. |
|
Maybe it’s only me but this is a step back in Direct3D usability. As much as I am like the idea of “No more caps” the price that especial small developers have to pay for it is high. I am sure we all can hardly afford to drop the big Windows XP and non Direct3D 10 hardware user base. This will force many developers to stay with Direct3D 9 as they don’t have the time or money to implement the abstraction and two render systems.
I know that Direct3D 10 had a long design process and I am mostly like the result. The “no more Caps” rule would be good for the future to build a common base. But from my point of view it would be better to have two Direct3D 10 “runtimes”:
·“capsed”: A version that internal use the Direct3D 9 interfaces and still have caps.
·“pure”: A version that is exactly what we currently have as technology preview today.
The capsed version could be a part of the SDK and redistribute the same way as the Direct3DX DLLs. I am already played around with this idea and build a little prototype (It runs the spinning cube from tutorial 04 on current hardware) as proof of concept. The core part is very easy to do but anything around (Effect System, Shader Reflection, D3DX10) would be much simpler for Microsoft as the already have most of the necessary code.
I think such a layer as part of the SDK would make the life for many developers much simpler.
Hopefully NOT. I think this is a really bad idea, if you have that kind of encapsulation in the core. This is the field of middleware... this companies need money too 
Instead I would suggest writing a seperate rendring DLL for each supported DX version... I don't think it is a good idea to expose the 9 interfaces under the 10 hood. I have always a seperated DLL for all supported version... Just have a data class that is shared and a rendering interface loaded from DLL. Let's get out of Caps hell... hehehehe.
The problem starts with the non-existant geometry processor prior to DX10... should the layer handle it? Surely not... to much high level code in a nice and clean framework.
I see that we disagree about this but that’s fine for me as it would be boring if anybody has the same opinion.
You call it middleware and you are right but with D3DX Microsoft already provide a big middleware library. You could even say the D3D10 effect framework is middleware as it did not talk direct to the driver.
Sure using multiple different DLLs is another solution for the problem of missing backward compatibility. But this will not get you out of caps hell as you simply replace the “normal” D3D caps with your own caps systems. Additional it will increase the size of the code base.
Missing features are not really a problem as a “capsed D3D10” would need an addition interface to query the caps.
