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."
Re:performance? (Score:2, Informative)
Valves presentation on the topic http://adrienb.fr/blog/wp-content/uploads/2013/04/PortingSourceToLinux.pdf states better performance using togl for their games (togl starts at slide 18, performance is mentioned on 23).
Re:Makes sense (Score:5, Informative)
A limited subset, as in every PC game that still supports WinXP. Which is practically all of them.
Lessons learned (Score:5, Informative)
Re:performance? (Score:5, Informative)
Yeah, probably minimal, since it is bytecode level (what HLSL and GLSL compile into)
The bad - this is DX 9.0c, which is analogous to OpenGL 2.0 (with extensions - note that ATI drivers didn't support extensions at the time, so more like 2.2+ for them) and in console terms, XBox 360/PS3 tech. OTOH, OpenGL went through a major paradigm shift with OpenGL 3 and 4 that make it work more like HLSL, so I expect shader conversion is much easier. When I ported a DX10 shader to OpenGL 3 it was much easier (but much harder was porting the entire OpenGL 2 project to 3).
Re:Makes sense (Score:2, Informative)
The majority of games on Valve's catalogue use D3D9.0c. That could be what they're aiming for - the huge collection of DX9 games already there.
Re:On the road to replacing DirectX (Score:4, Informative)
Re:Winelib (Score:5, Informative)
Odd considering their (Wines) last copyright cockup was entirely due to an internal contributor committing decompiles of Microsoft binaries as contributed code...
Re:On the road to replacing DirectX (Score:5, Informative)
If you're going to be nitpicky, then yes, it's SDL+OpenGL.
However, the only DirectX system still relevant in Win8.1 is Direct3D. Everything else has been removed;
DirectDraw - Repaced by Direct2D [microsoft.com]
DirectInput - Replaced by XInput [microsoft.com]
DirectSound - Replaced by XAudio2 [microsoft.com]
DirectMusic - Legacy MIDI format - also replaced by XAudio2
DirectPlay - A complete joke, replaced by Games for Windows Live and XB Live.
DirectX Media/Media Objects: Deprecated and replaced/removed by all of above
That leaves DirectWrite and Direct2D as the only relevant (and minor) DIrectX components left. So yes, DX is more than a graphics API; these days and for gaming though, the only thing being used is D3D in DX.
Going the other way like Microsoft does... (Score:5, Informative)
Going the other way like Microsoft does is more interesting.
One of the biggest issues with OpenGL is that you can get shaders that won't run in bounded time. You can see this with a number of games in Flash, or natively in OpenGL, when run on a Mac. If the shader doesn't exit, it eats a channel, and there are a limited number of channels, and once they are gone, the renderer, which is also used for the desktop, basically crashes. There are nice system log messages from the video driver about it, but besically everything ends up restarted, which is pretty useless.
FWIW: this accounts for the majority of system instabilities in the card specific portions of both Mac OS X and Linux render pipelines.
DirectX doesn't allow things to run in unbounded time in its OpenGL to DirectX translator; instead, it loop unrolls shaders, and if it can't do that such that they run linearly, and therefore in bounded time, it omits them from the render. So you might not get distance blurring, haze effects, fog effects, rain effect, and so on, but at least the thing doesn't crash, and if the person porting the code to the Windows platform cares about these things, they fix the code so that it'll run using DirectX. Usually, this reduced the perceived "quality" of the final render, but you get at least a crude version of your effect back.
The other thing DirectX does is, in the video driver, keep a reserve channel for sending commands to the video hardware; the common reason for this is in-band signaling to comply with the DirectX 9 requirement that the video hardware be capable of being reset, without rebooting the system, such that a video card hang doesn't necessitate a reboot.
While a DirectX to OpenGL translation layer is a nifty idea (I lobbied very hard for a FreeBSD emulator for Linux, rather than a Linux emulator for FreeBSD so that developers would target FreeBSD rather than Linux as their development platform), I don't think that as long as the OpenGL shader looping issues don't also get addressed at the translation layer that translating from DirectX to OpenGL will be in anyway superior to translating from OpenGL to DirectX.
So basically, it's nice they released this, but the code is of little practical use in the real world, since there are features that will get lost in translation.
Re:On the road to replacing DirectX (Score:5, Informative)
Aside from the differences on paper, the actual implementations can be broken, buggy or inefficient. e.g. Some older desktop drivers might not offer an ES 2.x profile, or it could be hopelessly crap.
There is no GLU / GLUT either for ES 2.x and every platform implements its own equivalent but proprietary set of APIs. So you may discover a lot of work is required to fix that. Then you may discover that one platform or language's bindings are different from another in subtle but annoying ways, e.g. there are several OpenGL ES 2.x bindings for Java and one might return a handle in an int[] array while another expects you to supply a 1-element sized IntBuffer. Annoyances which add up.
In summary, yes you can port code, and OpenGL is definitely one family of APIs that offers support across a wide selection of devices. But it's not guaranteed to be simple and probably won't be. The best bet is use a good third party library (e.g. libgdx) and let the library hide as much of the work as possible.