Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Open Source Games

Valve Open Sources Their DirectX To OpenGL Layer 130

jones_supa writes "A bit surprisingly, Valve Software has uploaded their Direct3D to OpenGL translation layer onto GitHub as open source. It is provided as-is and with no support, under the MIT license allowing you to do pretty much anything with it. Taken directly from the DOTA2 source tree, the translation layer supports limited subset of D3D 9.0c, bytecode-level HLSL to GLSL translator, and some SM3 support. It will require some tinkering to get it to compile, and there is some hardcoded Source-specific stuff included. The project might bring some value to developers who are planning to port their product from Windows to Linux."
This discussion has been archived. No new comments can be posted.

Valve Open Sources Their DirectX To OpenGL Layer

Comments Filter:
  • Winelib (Score:5, Interesting)

    by Wootery ( 1087023 ) on Tuesday March 11, 2014 @08:50AM (#46453723)

    Could this be of use to the Winelib [winehq.org] project?

    (As the name implies, it's the compile-time analogue of Wine.)

  • Re:Winelib (Score:4, Interesting)

    by Anonymous Coward on Tuesday March 11, 2014 @08:55AM (#46453743)

    Possibly, I havn't looked at the source yet. But the readme says its a subset of the DirectX 9.0c features, making it not only obsolete, but incomplete. Fortunately, its open source so a bit of wrangling could make it swallow dx10 and 11

  • by Anonymous Coward on Tuesday March 11, 2014 @09:37AM (#46454035)


  • by JDG1980 ( 2438906 ) on Tuesday March 11, 2014 @10:24AM (#46454365)

    Swapping to OpenGL provides significantly less functionality than DirectX as DirectX isn't just a graphics API.

    Pretty much all aspects of DirectX except for Direct3D have been deprecated by Microsoft. They still work, but aren't recommended for new code, and have been superseded by other APIs.

  • Re:question (Score:3, Interesting)

    by Anonymous Coward on Tuesday March 11, 2014 @11:50AM (#46454983)

    Speaking as someone who's written a native D3D 9.0c implementation from scratch (on the PS3), implementing it is not the issue. I probably implemented the exact same subset as Valve did - only the shader-driven part, no fixed-function emulation - and it took maybe 4 weeks total (160 hrs). My implementation was 10x faster (seriously) than the D3D 9.0c implementation on X360. (That's CPU usage of the API; obviously the GPU ran at comparable rates. The X360 port team on the project I was on hit frame rate just issuing too many D3D calls, while the PS3 port was running the exact same D3D calls using 10% of the CPU. It correctly handled locking, sync, cache flushes, etc. so it gave the exact same guarantees as the real D3D; I guess Microsoft's 9.0c still had a lot of Windows cruft in it's X360 incarnation. Probably doing too many kernel transitions - I had zero except at the end of the frame.)

    The reason I never turned this into a product and sold it was because to get the D3D 9.0c headers you have to accept an EULA that says it's all confidential, and my dog simply isn't in that fight. Valve's dog is in that fight now, but they have a much bigger dog than I do. Using their code as a starting point I could in theory release my code now (only to PS3 developers though because of Sony's NDAs ... and that's no click-through EULA, that's a cast iron contract between my company and Sony). A bit late though, who the hell needs D3D 9.0c on PS3 in 2014? Direct3D 12 on PS4, now that might be worth considering ...

If I had only known, I would have been a locksmith. -- Albert Einstein