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

Interview with RealTech-VR

[Anonymous Coward]

Actually, OSNews has an interview with the guy behind the wrapper, and they even have some screenshots! I hope this wrapper comes to Linux soon!

DirectX wrapping of OpenGL -- too slow?

[slithytove]

I'm a game developer working on the Nel platform. 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.
Extra layers obviously have that property in general, but I see it as the wrong place to create that cross compatability. The nevrax team has said in the past that they have designed the system to be able to replace the OpenGL bindings with DirectX or gamecube api (what is gc api like?)
I hope that more developers will build games based on Opensource engines as our company is (in-orbit.net)- it has saved us a lot of money and allowed us to focus on gameplay and uniqueness.

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

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.

Re:SDL integration

[Cuthalion]

SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.

Just to provide one example (there are many others): In DirectDraw when you're blitting a sprite, you have the option of flipping it horizontally. There's no way to do that with SDL - you have to store two copies of your sprites if you think you'll want to blit it facing the other way. Or do it by hand each blit, but then you're not geting HW accel.

Now this may be a concious design decision. A complaint I have about DirectX IS that it's interface is sort of boroque. For the most simple of blits, there's a lot of unused parameters, which is kind of irritating, and makes the code harder to read and the interface harder to learn. My initial reaction to SDL was "This is great - it's so easy!" until I started noticing not-so-advanced features that are missing. I've basically concluded that if I want any kind of powerful 2d support I might as well just use OpenGL directly rather than fuck around with SDL's hamstrung (but admittedly very easy to use) interface.

So the upshot: DirectX is a proper superset of the SDL functionality, so writing an SDL plugin for directx would be a losing proposition at best (never minding the issues of adding a second, or on some platforms, third, layer of abstraction in what is already a time-critical interface)

ps: don't even get me started on SDL_mixer

Re:SDL integration

[CoughDropAddict]

SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.

SDL has had the ability to create OpenGL contexts for a long time. And we're talking about Direct3D, not DirectX, so the DirectDraw example doesn't apply.

Direct3D and the Mac

[feldsteins]

I have always viewed Direct3D as a Really Bad Idea for the Macintosh platform. I mean, that's all we need is to hitch our 3D waggon to Microsoft. We'd always be a version behind, some features would never be implimented, etc. And then when all game manufacturers were using D3D, whoops! Microsoft isn't supporting D3D on the Mac anymore.

Even some game developers I have spoken to seemed pretty positive about the idea. "if only we could do D3D," they said. I think otherwise for the reasons stated above.

And what does this new "wrapper" mean to us? I hope it doesn't mean that Game developers or porting companies don't bother with the OpenGL conversion (when necessary). For if this turns out to be the case I fear the sceneario above may come to pass in the long run. Bottom line is, this scheme seems to still leave 3D on the Macintosh platform vulnerable to the whims of MS.

What about WINE?

[Anonymous Coward]

It appears that this project,

("Direct X 8 port only support DirectX Graphics. The DirectX Graphics for BeOS is an OpenGL wrapper for the Microsoft® Direct3D API. Application written in Direct3D 8 will be able to compile on BeOS platform. At execution, the Direct3D 8 functions will be converted into the OpenGL ones with a minimal performance loss.

is a subset of WINE.
After all, The Sims uses DirectX and works over WINE. (I'm sorry, I can't find a link.)

A good idea?

[tempest303]

Is this really such a hot idea? Compatability is cool, but wouldn't developers' time be better spent improving or coding for OpenGL?

SDL/OpenGL vs DirectX OR the end of open standards

[XRayX]

I'm not sure if this is a good thing. Of course it might be great to have something like this integrated to Wine to play DirectX Games under Linux, but if the other wrappers (DirectSound/Input/Play etc.) are implemented and run something stable, me as a game developer would think twice about porting this to truly open standards like OpenGL and SDL ("Why don't use the DirectX wrapper?").
So if you see things on the long run, this might be more a damage than a boost to native Linux/OpenSource game-development.

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

Amen to that!

[pb]

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.

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.

Wouldn't it be quicker...

[volpe]

...to just walk around Redmond with a big "Sue Me" sign on their backs?

Re:what license

[spt]

Picking a file at random (dsetup.h) shows


*
* Copyright (C) 1995-1997 Microsoft Corporation. All Rights Reserved.
*
* File: dsetup.h
* Content: DirectXSetup, error codes and flags


so, whatever license the DirectX SDK comes under I guess.

Make it a non issue

[DeadBugs]

STOP buying D3D games
KEEP buying OpenGL games

Re:Make it a non issue

[Cryptnotic]

That's not really practical for the large majority of game buyers. It would be like telling Americans to stop speaking English. And since Microsoft has gotten DirectX into game consoles (Dreamcast, X-Box), developers have a strong incentive to develop using only DirectX (Easy ports of DirectX games).

Cryptnotic

useful? not really

[mysticbob]

so, this is useful why?

will it help people port to other platforms? doubtful, as they're probably using other ms stuff if they're using DirectX.

will it help people use more advanced features on other platforms? no, since they're just using underlying opengl (and extensions) anyway, which they could do in the first place.

is it more performant? no way - it's another layer of indirection, so it's at least an additional pointer dereference, and extra stuff on the stack.

so i'm left thinking this is a solution in search of a problem. if you want portability, you write to opengl. if you want extensions, you use the _portable_ extension mechanism that opengl already provides. check out nvidia's directx vs opengl extension comparison some time - guess which one has better & more support? hint, it doesn't start with direct..

so, again, why would any sane developer write to this?

(and yes, i read the faq.)

Good, bad, or ugly?

[prototype]

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

Re:Just what we DON'T need, MS API's in Linux

[Ryan Amos]

What sort of crack are you smoking? Extra compatability is always a good thing. Get the notion that Microsoft has nothing to offer out of your fucking head. At some point, Linux has to grow up beyond the "fight-the-power" angst-filled culture that is quickly alienating it from the corporate market (wonder why you don't see quite so many people pushing Linux anymore? It has a bad rep in corporate America.) If you're in favor of a less functional operating system just because "Microsoft is evil! Fight the man!" you need to grab a bottle of Clue (tm) and take twice daily. Sure, I don't approve of everything Microsoft does, but you don't see me running around like a spoiled 6 year old who is mad because a girl wants to play with his friends.

Karma to burn, baby.

I send you this api to have your advice...

[Mongoose]

Listen kids this is an early alpha of a D3D wrapper for WinGL, with minor ports of MacGL and others. This isn't DirectX, which handles the input, sound, and even ( directplay is horrible ) networking.

Things to note:

1. D3D is a huge moving target itself
2. This project doesn't support full D3D ( ATI/NV )
3. D3D isn't a 'standard', it's rewritten every release

Keeping these things in mind you won't get your windows games on linux, you won't get a wrapper for D3D for all GL cards, and you won't even get a finished release of this. I don't mean to sound negative, but by the time they have all the NV/ATI extentions supported DX 9.0 and maybe even OpenGL 2.0 will be out with an all new shader systems.

Too bad vertex and pixel shaders won't be used much until another few generations. You have to wait for the target (mainstream) consumers to get at least something like a GF3 or similar first generation consumer card shader support. However, I will say that doesn't mean you won't have some games and applications just requiring you to get a card with support or offer it as a runtime enabled option.

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

Re:Not much there

[IGnatius T Foobar]

They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.

True enough -- but there was a time when Linux wasn't keeping the SCO people up at nights either. Fear commoditization.