Live data from Hacker News

Direct3D to OpenGL abstraction layer

github.com

91–100 of 111 posts

Re: Direct3D to OpenGL abstraction layer

#91
post #90
post #81

Earlier quoted context omitted.

I left it out on purpose, because DOS was a Microsoft platform as well.

> I left it out on purpose, because DOS was a Microsoft platform as well. MS-DOS was a Microsoft platform, but not DOS itself: > http://en.wikipedia.org/wiki/DR-DOS Also Glide was not a Microsoft API.

I just wrote DOS as I always abbreviated MS-DOS as DOS.

DR-DOS actually came with the first PC I bought and it was for all effects a MS-DOS clone, hence a DOS clone, like PC-DOS from IBM and a few others on those days.

Re: Direct3D to OpenGL abstraction layer

#92
post #47

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?

I wonder if you could use ToGL and Wine... Wire up the D3D graphics stuff at compile time, and translate the rest of DX at runtime.

Re: Direct3D to OpenGL abstraction layer

#93
post #91
post #90

Earlier quoted context omitted.

> I left it out on purpose, because DOS was a Microsoft platform as well. MS-DOS was a Microsoft platform, but not DOS itself: > http://en.wikipedia.org/wiki/DR-DOS Also Glide was not a Microsoft API.

I just wrote DOS as I always abbreviated MS-DOS as DOS. DR-DOS actually came with the first PC I bought and it was for all effects a MS-DOS clone, hence a DOS clone, like PC-DOS from IBM and a few others on those days.

> DR-DOS actually came with the first PC I bought and it was for all effects a MS-DOS clone, hence a DOS clone, like PC-DOS from IBM and a few others on those days.

Under this argumentation GNU/Linux or even OS X is a UNIX clone and both should be abbreviated to UNIX (or UN*X to avoid trademark violations ;-) ). Indeed both originate from UNIX clones - but then new features were added that made them better than the original in a sense. The same happened to DR-DOS. Read DR-DOS' wikipedia article to read about features that DR-DOS added over Microsoft's original.

Re: Direct3D to OpenGL abstraction layer

#94
post #66

Earlier quoted context omitted.

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.

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.

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.

Re: Direct3D to OpenGL abstraction layer

#95
post #94

Earlier quoted context omitted.

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.

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.

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.

Re: Direct3D to OpenGL abstraction layer

#96
post #93
post #91

Earlier quoted context omitted.

I just wrote DOS as I always abbreviated MS-DOS as DOS. DR-DOS actually came with the first PC I bought and it was for all effects a MS-DOS clone, hence a DOS clone, like PC-DOS from IBM and a few others on those days.

> DR-DOS actually came with the first PC I bought and it was for all effects a MS-DOS clone, hence a DOS clone, like PC-DOS from IBM and a few others on those days. Under this argumentation GNU/Linux or even OS X is a UNIX clone and both should be abbreviated to UNIX (or UN*X to avoid trademark violations ;-) ). Indeed both originate from UNIX clones - but then new features were added that made them better than the o…

Did you failed to read I was a DR-DOS user?

I use computers since the early 80's.

Re: Direct3D to OpenGL abstraction layer

#97
post #66

Earlier quoted context omitted.

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…

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.

As mentioned in the other comments it's not consistent nor always supported. And you can do the multithreading only by sharing already rendered fbo's.

In D3D it works as OpenGL display lists would, except with arbitrary commands. So you have multiple threads composing the scene and then a single thread just issues few commands to replay the command buffers created by the other threads.

It would be rather simple to implement the same in OpenGL as we already have the display list concept, even if it originally was made to reduce the amount of glvertex3f calls.

"complete lack" was maybe bit of an exaggeration, however in practice it is true.

Re: Direct3D to OpenGL abstraction layer

#98
post #55

Earlier quoted context omitted.

> Basically any engine thats runs on PS3/PS4 does like UnrealEngine, Cryengine, idTech, Unity and most indie/open source engines are OpenGL anyway That's completely wrong. PS3 never used OpenGL and PS4 doesn't do either. Unreal while having somewhat working Mac port is usually ported via Cedega and not the Mac version which is largely unmaintained. The Linux port of Unreal was never merged back either. Presently ther…

Quote from Wikipedia >> The current release is Unreal Engine 3, designed for Microsoft's DirectX 9 (for Windows and Xbox 360), DirectX 10 (for Windows Vista) and DirectX 11 (for Windows 7, Windows RT and later); OpenGL (for OS X, Linux, PlayStation 3, Wii U, PlayStation Vita, iOS, Android); Stage 3D (for Adobe Flash Player 11 and later); and JavaScript/WebGL (for HTML5). You are right that CryEngine doesn't use OpenG…

Crytek uses libGCM on PS3, not PSGL.

Re: Direct3D to OpenGL abstraction layer

#99

Earlier quoted context omitted.

>>OpenGL is years behind D3D (not DirectX, it's not comparable!) in many areas, Explain please?

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…

I figure you're talking about DX11's multithreaded submission? While it's true that GL doesn't have support for this yet. AFAIK, DX's implementation is very slow, and all the major engine developers end up implementing their own batched dispatch anyways which ends up being faster on PC.

Re: Direct3D to OpenGL abstraction layer

#100
post #52

Earlier quoted context omitted.

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 f…

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 h…

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

And this is Valve releasing their particular variant mostly targeted at other major game studios. There is no reason every studio should be forced to create their own in house compatibility layer.

Post reply on HN