Digging through the source code tree of Dota 2, developers discovered Valve's latest creation, ToGL. Simply put, it's a Direct3D to OpenGL translation layer, which works to reduce duplication of effort in developing games for multiple platforms (such as Windows, Linux, and OS X). The software can translate Direct3D calls to their OpenGL analogues. So far, it can translate only certain kinds of calls within the Direct3D 9.0c API, which should fit Valve's needs adequately. It features a bytecode-level HLSL to GLSL shader language translator. It features only a limited shader model 3.0 support. ToGL is currently being provided by Valve as-is on GitHub, and is unsupported. Developers are free to incorporate it into their projects, and make modifications to it.

I never cease to be surprised that so much ignorance can fall upon one thread like flys around s**t, a warning was issued a while back, it has been ignored, so sadly pain is a coming, any more crap in here and we wont be talking modest 45 day holidays....... Thank You.

in this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.

in this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.

Absolute silence without compromising performance is my only benchmark score.

This is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?

This is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?

Click to expand...

I disagree, if they can get close with minimal overhead, that save a lot of programming hours porting an engine from one 3D API to another. While it might be slower, it's a step in the right direction. It also create a framework for how to port DX applications to OpenGL since there is a library that does the translation for you.

The real question we have to ask (before we start bashing it,) is what kind of performance will we see out of this compatibility layer. Until our questions are answered we shouldn't judge it. Additionally, it's a lot more than double work to port a game from one API to another. Consider for a moment how many bugs and incompatibilities you come across between the two APIs then remember that they need to thoroughly test it once they even get it working.

This makes sense for games that were coded for DX and only DX to run in OpenGL. I don't see the problem with that. It's giving you an option where you wouldn't otherwise have one.

Sure, Direct3D also had "minimal" overhead which now turned into a massive one...

Click to expand...

Please start citing your sources if you're going to make claims like that. DX interfaces with hardware-level APIs so overhead will be minimal anyways in most cases, so I'm reluctant to believe that. Any API call is going to have some overhead and take some time to call it, but taking time to call an API doesn't mean that it has a lot of overhead. Some API calls are just simply costly.

As far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.

As far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.

Click to expand...

I saw translated calls and not a whole lot of pre-prossessor directives. I don't think it's done at compile time, but it doesn't do much more than add another reference frame to the call stack as most of those translated calls are pretty simple (direct one-to-one translations with one line of code,), but any extra calls take time to do and I'm sure there are things that DX does faster than OpenGL and things that OpenGL does faster than DX.