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

13 of 246 comments (clear)

  1. DirectX wrapping of OpenGL -- too slow? by slithytove · · Score: 4, Informative

    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.

    1. Re:DirectX wrapping of OpenGL -- too slow? by dair · · Score: 5, Informative
      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
  2. SDL integration by moebius_4d · · Score: 5, Interesting

    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.

    1. Re:SDL integration by Cuthalion · · Score: 4, Informative

      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

      --
      Trees can't go dancing
      So do them a big favor
      Pretend dancing stinks!
  3. Direct3D and the Mac by feldsteins · · Score: 4, Insightful

    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.

    --
    You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
  4. SDL/OpenGL vs DirectX OR the end of open standards by XRayX · · Score: 4, Insightful

    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.

    --
    Boycot? Blackout? Subscriptions?
    I don't care!
  5. Allways nice.... by Otis_INF · · Score: 5, Interesting

    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.
  6. Re:SDL/OpenGL vs DirectX OR the end of open standa by Nerds · · Score: 5, Interesting

    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 .sig is 'The Art of Computer Programming'
  7. Wouldn't it be quicker... by volpe · · Score: 4, Funny

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

  8. Make it a non issue by DeadBugs · · Score: 4, Insightful

    STOP buying D3D games
    KEEP buying OpenGL games

    --
    http://www.kubuntu.org/
  9. I send you this api to have your advice... by Mongoose · · Score: 4, Informative

    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.

  10. Not much there by gavriels · · Score: 5, Informative

    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

    1. Re:Not much there by IGnatius+T+Foobar · · Score: 4, Insightful
      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.
      --
      Tired of FB/Google censorship? Visit UNCENSORED!