The Many Problems With OpenGL

[DDF420]

Devs had been nut-hugging MS for so long that OGL and other tech withered on the vine. Now with the breakout of mobile devices and SteamOS, etc., devs are scrambling to target alternative platforms, and finding that the years of neglect need to be undone. Hopefully a lesson was learned here.

LOL http://programmers.stackexchange.com/a/88055
.

[Ancurio]

Devs had been nut-hugging MS for so long that OGL and other tech withered on the vine. Now with the breakout of mobile devices and SteamOS, etc., devs are scrambling to target alternative platforms, and finding that the years of neglect need to be undone. Hopefully a lesson was learned here.

Frankly, these two screeds didn't come off on me too well. I develop software for a living myself. The fact is, everything sucks. It's just part of the job. I understand his frustration boiling over but to the unwashed masses it does not present Valve in a good way. After the big Steam Dev Days and talk about how open platforms are the wave of the future and everyone follow us along this wonderful journey -- and here you have one of the top guys who ported Source ripping OGL pretty hard. A bystander reading this thing would definitely not have warm feelings about any potential Steam Machines coming down the pipe.

He never said a single word about "open platforms". OpenGL sucking majorly in certain aspects is not being blamed on it being open (this is in fact unrelated, it could be closed and still suck), he's just stating what is wrong with OpenGL today and what needs to be fixed in order to compete with DirectX in the future. Please don't be that delusional fanatic that sees any kind of criticism of an open API as a full on attack on the entire FOSS ecosystem.
The blogs title is "Things that drive me nuts about OpenGL", not "Pros and contras of OpenGL". Nobody expected there to be praise because that was not the point, things that don't need to be fixed don't have to be pointed out in the first place.

Oh, and to a "bystander" that hasn't ever written a hello_triangle.c let alone knows any programming at all, this blog post is just tech mumbo jumbo anyway. SteamOS and Steam Boxes aren't even mentioned at all; this could have been anyone's critic (and in fact the Dolphin emulator guys have had similar feelings about OGL, although nobody seemed to bash them for it).

And we don't know anything about D3D12 yet and he's already singing its praises.

That's not true. There was a tech preview blog that outlined a few new core techs in D3D12: http://blogs.msdn.com/b/directx/arch...irectx-12.aspx

[log0]

It didn't come off on me to well either. Lots of work is being done to improve OGL and there's massive potential in using OGL as explained at the Steam Dev Days and now this guy comes along and publicly trashes it. No doubt this would have been music to Microsoft's ears and I doubt that his bosses at Valve would have been impressed.

If he has frustrations in using OGL perhaps he should have conveyed his thoughts privately to the Khronos group instead.

This is not trashing, it is a situation assessment. And you will find plenty devs, who will agree with him on the state of OpenGL drivers and support. So nothing new here. While it could have been a more "diplomatic", it is important to be able to talk about this issues in public, imho.

[Ancurio]

It didn't come off on me to well either. Lots of work is being done to improve OGL and there's massive potential in using OGL as explained at the Steam Dev Days and now this guy comes along and publicly trashes it. No doubt this would have been music to Microsoft's ears and I doubt that his bosses at Valve would have been impressed.

The first step to improving something is pointing out the weaknesses. This is not a "trashing" for gods sake, it's a rant that focuses on the negative aspects (because everyone already knows the benefits of OpenGL). By the way, the concept of "bosses" doesn't exist at Valve.

If he has frustrations in using OGL perhaps he should have conveyed his thoughts privately to the Khronos group instead.

Yeah, that sounds really healthy, let's discuss the problems of an open API behind closed doors so nobody can chime in and feelings don't get hurt. A very Free and Open way to do things.

[gamerk2]

Devs had been nut-hugging MS for so long that OGL and other tech withered on the vine. Now with the breakout of mobile devices and SteamOS, etc., devs are scrambling to target alternative platforms, and finding that the years of neglect need to be undone. Hopefully a lesson was learned here.

Frankly, these two screeds didn't come off on me too well. I develop software for a living myself. The fact is, everything sucks. It's just part of the job. I understand his frustration boiling over but to the unwashed masses it does not present Valve in a good way. After the big Steam Dev Days and talk about how open platforms are the wave of the future and everyone follow us along this wonderful journey -- and here you have one of the top guys who ported Source ripping OGL pretty hard. A bystander reading this thing would definitely not have warm feelings about any potential Steam Machines coming down the pipe.

Nor does Valve give the impression that they write impeccable software either. (I'm being charitable here.) As I said, I know how the business goes and there's no such thing as bug-free software. But they took a guy who built his career at MS and asked him to port some 5-yo games and the Source engine using a to-GL translation layer. What could possibly go wrong?

And his fascination with Mantle / D3D12? Explain it to me. Mantle works on one piece of hardware and one OS only. And we don't know anything about D3D12 yet and he's already singing its praises. Look at any AAA PC game released on D3D... it's a trainwreck for at least a few months (e.g., BF4) until all the bugs get worked out.

I'm sure he has a lot of valid points but some of it reminds me of those old "anti-Java" rants you'd read about every now and then. "I'm used to C++ so Java sucks."

Mantle is attractive because it has the POTENTIAL to be adopted (though NVIDIA will never sign on, so no) and open, and DX12 is finally dealing with the driver overhead problem, which has been lingering since DX9 and is BY FAR the most requested thing MSFT needed to do with the API. I really can't stress how big the overhead reduction will be for devs.

[GreatEmerald]

SDL2 supports scaling and hardware acceleration.

That said, yes, the approach you are using is reasonable. Your OpenGL 1.x commands are translated to shaders by the driver automatically (so the emulation layer you were talking about already exists, it's hidden inside your OpenGL drivers.)

Modern hardware simply doesn't support fixed-function functionality, so emulating that with shaders is the only way you can implement OpenGL 1.x on new GPUs (were "new" is >2004 or so.) The problem with that is that a complete OpenGL implementation requires you to emulate hundreds of OpenGL 1.x functions that are simply not that useful anymore. Not an exaggeration: the complete OpenGL spec has (IIRC) 2659 different functions as of May 2014. This makes drivers extremely difficult to implement, as well as buggy and unstable.

A clean start is looking mighty attractive once you spend some time working with OpenGL... I, for one, would fully support an initiative starting from the open-source developers of intel, nouveau and radeon.

It supports scaling individual bitmaps? Nice. I'm still using SDL 1 for my game (have to wait a bit until SDL2 support matures).

So I agree that things which are supposed to be shared across all drivers anyway (like this instance of creating shaders when calling fixed functions) shouldn't be in the drivers. However, with the huge variety of graphics cards, how does one tell what should and what shouldn't be in the drivers? Maybe OpenGL could specify that hardware should only expose hardware accelerated features as extensions (so current hardware would not expose the fixed pipeline support), and then have a companion library that has common wrappers to make those extensions available to programs by using different methods to achieve the same thing?

[b15hop]

LOL http://programmers.stackexchange.com/a/88055
.

Solution is to move to OpenGL ES.

EDIT: That was a damn good read by the way. Thank you for sharing!!

[Azpegath]

Solution is to move to OpenGL ES.

EDIT: That was a damn good read by the way. Thank you for sharing!!

I constantly see that statement, but I don't understand it. Why not just use OpenGL3/4 and turn off the compatibility profile. That's more or less the same thing as OpenGL ES, isn't it? His points in the article and not regarding "old" OpenGL, it's about all versions of OpenGL, including OpenGL3.x/4.x. And I doubt he is referring to the fixed function pipeline, even though he doesn't mention it specifically. But I might be wrong.

[zanny]

I constantly see that statement, but I don't understand it. Why not just use OpenGL3/4 and turn off the compatibility profile. That's more or less the same thing as OpenGL ES, isn't it? His points in the article and not regarding "old" OpenGL, it's about all versions of OpenGL, including OpenGL3.x/4.x. And I doubt he is referring to the fixed function pipeline, even though he doesn't mention it specifically. But I might be wrong.

The benefit of writing to GLES is that any engine written against it instantly works on every device ever as long as they are up to date on the GL enough to support GL 4.3. And the Mesa Intel driver already has the GLES3 compatibility extension.

The alternative is to write one OpenGL backend for desktop and GLES one for mobile. Makes more sense to just have one, at least for me, because I'm an advocate that the value of a game is in its story, characters, and content and not just the eye candy GPU crushing dozen phase pipeline shaders you get that differentiate Core from ES.

[Azpegath]

The benefit of writing to GLES is that any engine written against it instantly works on every device ever as long as they are up to date on the GL enough to support GL 4.3. And the Mesa Intel driver already has the GLES3 compatibility extension.

The alternative is to write one OpenGL backend for desktop and GLES one for mobile. Makes more sense to just have one, at least for me, because I'm an advocate that the value of a game is in its story, characters, and content and not just the eye candy GPU crushing dozen phase pipeline shaders you get that differentiate Core from ES.

Yes, I guess that's true. But that's beside the issue I stated in my post. The aspect of "A clean API" is not different at all, right?