Slashdot Mirror
An Open Source Direct3D 8.0 Wrapper for Open GL
Jason writes: "RealTech-VR, creators of the V3X 3D engine, also developed a Direct3D-to-OpenGL wrapper and they have now open sourced their work. They are seeking for more hackers to help porting the wrapper to Linux and MacOS. A lot of the functionality of Direct3D is already ported but it still needs quite some work. Get the scoop at OSNews."
It would be useful to (re)build this on SDL so that they don't have to re-invent the wheel for audio, 2D, etc. (all the non D3D parts). Already SDL allows (hell, requires) you to call OGL directly when you need 3d accel. So by implementing their calls as an SDL layer they would lose nothing and gain a very nice cross-platform layer.
Doesn't Wine already have a DirectX native library that can be used without Wine?
While it's been awhile since I've done anything in the 3D world, it seems to me that the slow parts were the drawing itself, not the API calls. As I understand it, what they've created is essentially an adaptor that passes calls from one API (D3D) to another (OpenGL). There will be some places that require a bunch of work, but I'm willing to bet that most of the translation is pretty simple. There might be a 1-5% performance hit with the D3D->OpenGL translation layer, but I wouldn't expect a huge performance gap.
This is similar to what VMWare does for the Win32 API, isn't it? Performance there is a bit slower, but it's perfectly acceptable. As a mac guy, this is absolutely fantastic.
It's allways nice to see a v0.0.2 version of a project that tries to port COM to Unix.
Because _THERE_ is the real challenge. Not the polypusher-code to transfer d3d calls to opengl calls. Besides the lefthand-righthand difference between OGL and D3D ofcourse.
D3D is COM based, OpenGL is plain C. Of course, COM is just a pile of C interfaces, but still, coding D3D is using binary objects with methods and properties. OpenGL is just a global canvas with global functions. I sincerely doubt this will ever succeed for 100%.
Never underestimate the relief of true separation of Religion and State.
DirectX support in Wine is pretty bad, and could definitely use something like this. Of course, OpenGL support in Wine has it's own problems, but this can only be a good thing for porting to non-Windows platforms.
I don't know if it's a good thing for Wine or not, though, because I couldn't find any details of the license. Wine is released under an artistic style license, so if this thing is GPL (or similar) it couldn't get merged directly into Wine.
However, they seem like nice enough people, so hopefully the Wine folks will check into it... Otherwise, we'll end up with a forked, GPL-compatible version of Wine for gaming, which wouldn't be so bad, but would be less than ideal.
pb Reply or e-mail; don't vaguely moderate.
If I could get DirectX games to play on a linux machine I guarantee there are at least 15 people I could have running Debian by the end of the week. It's a good thing.
Let's just be crazy and say this happens and everyone starts throwing their Windows CDs in the trash. One of two things might happen:
1. Developers say "Let's just keep writing for DirectX, the wrappers work." So what? A Microsoft technology sticks around, but if so many people are leaving Windows, MS won't really have the power to enforce changes to DirectX 9 that would make it incompatible, because the devs will ignore them.
2. Developers decide that since everyone has a linux box anyway, why not write in OpenGL since it would probably be more efficient?
Either way, who cares? A working DirectX wrapper would win users over, and that's a good thing.
My other
Umm, it is not just a reversal to map from one API to another. APIs don't map to each other cleanly. Writing a mapping from DX -> GL is much harder than writing one from GL -> DX because DX incorporates a lot more features, plus it is object based, which makes it harder to map to a C API.
This is not some kind of holy grail that everyone is looking for so stop it right now. OpenGL, which is a far better API IMO (and John Carmack thinks so too!) is and has always been the defacto standard portable API to code against. I will admit that recently with DX8, things got more in line with OpenGL and the D3D API is better than it was, but it's still COM based and completely not portable (among other problems). This product is just a wrapper to make COM look like C++ objects and underneath, make OpenGL calls.
So what does this give us? It does NOT give us a WINE implementation of being able to run DirectX apps. Yes, you could integrate the code into WINE but it's meant to wrap functions at the source level, not the executable level. It does give us a wrapper that DirectX code can, for the most part, compile against and product a working Linux/BeOS/Mac exectuable. So for the game developers it might mean their DirectX code will compile on other platforms, but any good game company would have abstracted out their graphics code so it would be API independant. That's what most of them do already and some do offer OpenGL/DirectX selection for rendering. Why they don't produce Linux versions of their apps if they can simply call OpenGL instead isn't clear, but that's their decision.
So are developers going to take DirectX code and compile against this to produce Linux OpenGL executables? I doubt it. Anyone who has coded their graphics sub-system directly against DirectX has probably coded other parts directly against the Windows API and if they haven't ported it to Linux already, they probably won't. Those that already have a clear decoupling of the graphics and the API don't need to and again, if they haven't ported they still won't for whatever reason (most likely support/business cases/etc)
On the flipside, I do applaud what these guys did as it is a big undertaking to wrap a system as big and complex as Direct3D so congrats and perhaps for the garage developer, it might be useful but to those people I say just code in OpenGL in the first place.
liB