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

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

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: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