
Direct3D to OpenGL abstraction layer - weslly
https://github.com/ValveSoftware/ToGL
======
paraboul
For the interested, google's Angle is the opposite :
[https://code.google.com/p/angleproject/](https://code.google.com/p/angleproject/)

~~~
cscheid
Now someone needs to start a project to find a large, documented subset for
which ANGLE(ToGL(x)) = x so we can all get rid of this historical two-
standards-that-do-exactly-the-same-thing nonsense.

~~~
kirkbackus
All that reminds me of is this: [https://xkcd.com/927/](https://xkcd.com/927/)

~~~
cscheid
Yes, one must be careful not to define a _new_ standard, but rather to
_observe_ a strict subset of both for which that "equation" holds.

------
slacka
Valve covered how these tools are used in their Porting Source to Linux:
Valve’s Lessons Learned talk:
[https://www.youtube.com/watch?v=btNVfUygvio](https://www.youtube.com/watch?v=btNVfUygvio)

slides here: [http://adrienb.fr/blog/wp-
content/uploads/2013/04/PortingSou...](http://adrienb.fr/blog/wp-
content/uploads/2013/04/PortingSourceToLinux.pdf)

------
kayoone
Not sure here but don't all major engines already support OpenGL ootb ?
Basically any engine thats runs on PS3/PS4 does like UnrealEngine, Cryengine,
idTech, Unity and most indie/open source engines are OpenGL anyway. All
engines that target Android/iOS are OpenGL too. Even for things like XNA which
was Xbox/DirectX only there is MonoGame to port it to *nix platforms easily.

So if you have rolled your own DirectX-only engine this is awesome of course,
but do people really do that?

~~~
throwaway2048
PS3/PS4 commercial games do not use OpenGL and never have. This myth needs to
die.

[http://scalibq.wordpress.com/2010/05/15/sony%E2%80%99s-plays...](http://scalibq.wordpress.com/2010/05/15/sony%E2%80%99s-playstation-3%E2%80%99s-main-
graphics-api-is-not-opengl/)

~~~
Justsignedup
"the advantage of a console: hardware is fixed". YEP! Why use an abstraction
layer when you can just code to the metal.

~~~
taybin
Many games run on multiple consoles.

~~~
chucknelson
Still a pretty small number (2-8 max?) compared to all of the PC
configurations you have to worry about in DX and OpenGL land.

------
dimillian
This is huge, really huge for anyone who write DirectX games and want to make
them run on OSX/Linux. This is basically what a part of Wine do, am I wrong?

~~~
Morgawr
Wine is a bit different, I'm not 100% sure but it's more like a
reimplementation of native calls than anything.

But yeah, this is awesome. As a side note, developers who want to make games
run on OSX and Linux should just stop targeting DirectX. This is good for
already-existing games and port them over, but in 2014 if you're still writing
games in DirectX, you're most likely doing it wrong.

~~~
maaaats
>> _but in 2014 if you 're still writing games in DirectX, you're most likely
doing it wrong._

No, you are not. There is no wrong and right, it's just a stupid statement.
OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas,
and writing using the whole DX stack can be much nicer than setting up a GL
stack with a lot of different libraries.

~~~
gambiting
>>OpenGL is years behind D3D (not DirectX, it's not comparable!) in many
areas,

Explain please?

~~~
sharpneli
Complete lack of multicore rendering.

You can practically issue render commands only from one thread. And there is
no way to save bunch of commands anymore as display lists were deprecated.
Also it's still very much state machine based. So you have to do a lot of
individual calls to set everything up for actual draw call.

I personally love OpenGL and use it on my work. However this is one of the
biggest drawbacks on OpenGL currently.

~~~
kosinus
No clue what multicore rendering D3D offers, but 'complete lack' is an
overstatement.

OpenGL has context sharing, which means several contexts in different threads
sharing the same objects. You can issue commands as long as you synchronise
access to objects yourself. In practice, that means filling buffers, rendering
to an off-screen framebuffer, etc. from other threads.

~~~
kevingadd
Multithreading in GL does not work consistently. If you ask the driver vendors
(AMD, NVIDIA, etc) they will tell you it doesn't work at all or across
platforms. If you ask engine developers (like Valve) they will tell you in
talks that it doesn't work across platforms.

~~~
kosinus
What's cross platform? I guess what matters in this specific argument is
feature parity with D3D on all the platforms it can compete on.

If it works on Windows, then I wonder if it really matters. I've seen a lot of
games (e.g. Team Fortress 2) still offer multithreading as an option in the
UI, so there's already two code paths there.

~~~
kevingadd
I have been told by driver vendors that GL multithreading does not work on
windows, yes.

D3D multithreading works (even, to a lesser extent, with D3D9!), and this is
one of the reasons why our D3D9 renderer is dramatically faster than our GL
one - we can offload a subset of rendering work to helper threads instead of
keeping it all locked on the thread that owns the window.

TF2/etc do offer a multithreaded rendering option, but IIRC on Windows their
engine still uses D3D. Also, note that it's an _option_ , because the feature
used to be very unstable (still might be, actually) - I suspect people using
the GL version of those games may have to disable it on certain
hardware/driver configurations.

------
archagon
In a thread not too long ago, I asked why CS:GO might have such terrible
performance in OSX, and olegoandreev hypothesized that it might have to do
with poorly compiled shaders. Maybe with enough eyes on the code, this can
finally be fixed? We already know that the OSX port of the Source engine can
have close-to-Windows performance based on benchmarks done in Parallels, and
yet it's still shamefully only half as performant.

[https://news.ycombinator.com/item?id=7303753](https://news.ycombinator.com/item?id=7303753)

------
Keyframe
_Limited subset of Direct3D 9.0c_

~~~
ygra
Now that I'm reading that ... isn't _every_ subset of a finite set itself
finite (and thus limited)?

~~~
Demiurge
I'm not a native English speaker, but I think in colloquial terms, "limited"
means "smaller than you might want" or something like that.

~~~
TazeTSchnitzel
A limited subset would not be a complete implementation, yes.

------
foxhill
kind of preaching to the choir, no?

i mean, there are more open source games that use OpenGL than DirectX, and are
already cross platform as a result. similarly, i would imagine if a AAA game
studio wanted to do such a thing, they would roll their own (or just use GL in
the first place).

perhaps i'm being too cynical (but this _is_ hacker news..)

~~~
this_user
So far most AAA games are still developed for DirectX only. Those are the
games that make or break a platform. Doom 95 was arguably the kind of killer
app that established Windows as the primary gaming OS. In the context of
Valve's SteamOS strategy it makes perfect sense to encourage more major
developers to build games on a portable API like OpenGL or possibly AMD's
Mantle by making it as easy as possible. If they fail at this, SteamOS, Steam
Boxes and gaming on Linux in general won't have a chance at mainstream
success.

~~~
foxhill
sorry if i wasn't clear, but i am aware that most AAA games use DX. the same
is not true for open source.

there are already DX->GL compatibility layers, although most of them are in
house, by companies that produce ports (ala Feral Games).

yes, i entirely agree with you.. almost. ideally, i'd like DirectX to.. go
away, forever. proprietary APIs that result in lock in to a software or
hardware platform are seriously holding back computing in general. and i'd
never recommend anyone use AMD's Mantle for the same reason (which is a
massive waste of everyone's time)

~~~
AimHere
Well there are possibly smaller studios and devs who perhaps don't have the
resources to roll their own translation layers, for whom this might be a
tipping point towards supporting SteamOS and/or Linux.

Since Valve has already written this for their own purposes, it'll cost next
to nothing for this to be published if they can stop people expecting support,
and they might get a few bug reports into the bargain.

------
orionblastar
This is a good start, I'd also like to see a Dotnet and VCRUN conversion to
Linux libraries like Mono and GNU C++ to help port even more Windows games to
GNU/Linux and Mac OSX.

------
Yuioup
Nice. Does this mean that developers can start porting their existing (pre
2013) games over to Linux? Or are we missing a DirectX to SDL translation
layer?

~~~
foxhill
well, SDL will do the job of getting a window from the OS. when used with GL
(in the way valve do), it doesn't really do much else.

~~~
Yuioup
It handles sound, input and a bunch of other stuff which DirectX also handles
besides window management and rendering.

------
bhouston
This seems like a new version of this previous effort:

[http://en.wikipedia.org/wiki/Cedega_(software)](http://en.wikipedia.org/wiki/Cedega_\(software\))

~~~
outworlder
Not really. Cedega is a version of Wine.

This is a library, intended to be used in your application in lieu of calling
the APIs directly. You cannot take a full application and ask this library to
run it.

~~~
ZoFreX
WINE does however contain a DirectX -> OpenGL translation layer that can be
used separately from the rest of it.

