Am Samstag, 18. August 2007 19:59 schrieb Ivan Gyurdiev:
The shader stuff uses two different backends and an intermediate interface (SHADER_OPCODE_ARG) to isolate the asm parser. Other parts of wined3d could do the same thing - you are interface constrained from the top (d3d) and from the bottom (gl), so it makes sense to focus on intermediate representations of the data. If it's hard to replace your GL backend, then the code isn't properly structured.
...and splitting things up is being considered yet again. I'm not sure I like the idea of throwing away working code to start "fresh" - but I'm no longer writing d3d code, so :)
No question it is possible to keep things merged, but keep in mind that d3d10 throws away some things that are a major thing the current d3d->gl wrapping code is dealing with, like having sampler states device global. The step from d3d9 -> d3d10 is much bigger interface wise than d3d7(*) -> d3d8 or d3d8 -> d3d9 have been, it is so big that Microsoft decided to throw away their internal implementation and start over. This is why we discuss this. If Microsoft hadn't entirely changed the way d3d works internally there wouldn't be any reason for us to do the same too.
D3D10 is a present. It is much closer to opengl than to d3d9. Having a common code means to deal with the overhead of mapping d3d9 to opengl in code that also runs d3d10. The question is how to deal with that overhead.
(*) d3d7->d3d8 was a huge change too because it got rid of the ddraw stuff in d3d. However, the differences are initialization-wise only, rendering once the device is there works the same way in d3d7. d3d10 has a different "run-time" interface.