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

Comments

SDL integration

[moebius_4d]

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.

Allways nice....

[Otis_INF]

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

Re:SDL/OpenGL vs DirectX OR the end of open standa

[Nerds]

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.

Re:DirectX wrapping of OpenGL -- too slow?

[dair]

I've only dealt with app level code so far, but from my few perusals of the lower levels of the library and my browsings of simple directx code, it seems as if the complexity would make for pretty slow and buggy engines.

Probably not - my day job for the last 6 months was the Mac port of Black & White, and we wrote a similar D3D->GL shim for that. Mapping from one API to the other is fairly straightforward, and the most expensive part of both is simply shoving the geometry/texture data down from the app to the API (assuming you cache out redundant state changes).

It doesn't really matter if that goes down through DrawPrimitive (D3D) or glDrawElements (GL): if that's your bottleneck, the cost is pretty much the same either way.

-dair

Not much there

[gavriels]

While it sounds all nice and all, there is very very little that is actually supported in this library. Most of the Direct3D functions are simply stubs, and this library would be absolutely incapable of running anything more complex than the rotating-cube demo they have a screenshot for. They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.

-Gav

--
Gavriel State
CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com