hybrid wrote:No, that's not true. What we basically do is to define a high-level API (IVideoDriver) and the actual "low-level" drivers in the actual driver implementations. I don't see any reason why this is not possible for dx9 and dx1x at the same time. There may arise features which are not possible for one or the other, but that happened to dx9/opengl also. Eihter we can work around such things with alternative implementations, or there are some things missing for some drivers. But there's no general limitation that a low-level API can under no circumstances implement the high-level interface.
Maybe I didn't explain what I meant exactly all too well, I know that it's perfectly possible to have a DX9 and DX10/11 driver at the same time, having built this from scratch myself in my engine (although I dropped support for DX9 some time ago). I'm completely aware of irrlicht's interface <-> implementation model
Maybe I should've mentioned actual implementations instead of interfaces, it's true that you can just not implement a feature provided by an interface if the underlying implementation does not support it, but the more features are added in an implementation (and D3D10/11 provides a decent amount of new features in comparison to D3D9) the more functionality you'll have to provide in your interface, which in turn will create more and more unimplemented functionality for older back-ends. This can be brought down to a minimum with a good design, but it will never be eliminated completely.
There's also a matter of varying performance based on how your functionality is implemented, emulation of older/newer functionality, executing code on the CPU/GPU , how much 'low level' control you want to give the developer, etc. These things are certainly not impossible to overcome, but the overall complexity and potential overhead grows, not to mention the user of the engine having to keep in mind which implementation provides which functionality and at which quality.