Live data from Hacker News

If you were involved in the OpenGL ES specification, you are an idiot

jwz.org

181–190 of 225 posts

Re: If you were involved in the OpenGL ES specification, you are an idiot

#181

He probably won't be very happy to know OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1.

I wasn't. I can understand getting rid of immediate mode; as jwz demonstrated it's not that hard to rewrite glBegin/glVertex code to use vertex buffers. But 2.0 has an absurdly steep learning curve if this tutorial is accurate: http://developer.android.com/resources/tutorials/opengl/open... . Multiple custom shaders to draw a single triangle, really?

The first hurdle is a little steep, yes. You need a shader to project your points, and a shader to texture your triangles.

But once you have those, it can scale to far more triangles.

Thing is without shaders it's still fixed-function, wich is bad.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#182

This guy needs to get over himself. The world doesn't revolve around his pet project. His rant is stupid for at least four reasons. First, OpenGL ES is not regular OpenGL. If it were, it would just be called "OpenGL". It's a different thing, based on OpenGL, but targeted at mobile phones and "small" devices. It's almost like complaining that DirectX and OpenGL have different interfaces. They're different things, ther…

If you were porting GL-based screensavers that were written a decade ago you'd probably be feeling the same way. You don't want to rewrite code that already works on an earlier version of the spec.

What earlier version? GL ES is NOT GL.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#183

JWZ is so right. The whole "FFP is slow" argument is completely wrong. Most graphics drivers are broken and inefficient. Its just a lack of decent dedicated programming effort coupled with over-management at NVidia etc. My own brush with Khronos group back when this was being done still makes me shudder. http://williamedwardscoder.tumblr.com/post/14011115100/openg...

Yeah, graphics drivers are broken and inefficient, and one reason is they have to implement ALL of the LEGACY, DEPRECATED SPEC in SOFTWARE, because some people's code could break.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#184

"I wrote this because you are all idiots." Speaking as an idiot, why do I want to run a screensaver on my iPhone?

You don't, especially an ancient one written for a deprecated graphics API optimised for SGI Graphics workstations.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#185
post #173

Earlier quoted context omitted.

If bread had changed as much as GPUs have in the past seven years, your toaster would be obsolete, too. This isn't about good engineering vs bad, this is about mature technology vs a rapidly developing field. Different characteristics beget different engineering trade offs.

Cars are switching from petrol to hybrid to electric motors, but roads still work... "Rapidly developing" is a red herring.

>Cars are switching from petrol to hybrid to electric motors, but roads still work...

Yes, and this is what makes this a bad analogy.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#186
post #85

Earlier quoted context omitted.

But it's not OpenGL. It's OpenGL ES. Windows 8 is also not Windows 95.

> Windows 8 is also not Windows 95. Windows 8 is backwards compatible with Win32 and even Win16. If it wasn't, there would be hell to pay. WinRT is a somewhat clean break with the Win32 legacy. But that's only required for Metro apps.

Ok Mac OS X Lion is not System 9. And no, Lion isn't backwards compatible to System 9 and there hasn't been hell to pay.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#187
disclaimer: I write OpenGL ES implementations for living. I occasionally deal with some of the guys writing (parts of) the GL specs.

This article is a load of bollocks. It actually isn't the first article I read that complains about the removal of immediate mode in GLES. This article, like the others I've read, leaves me with the impression that the author is rather clueless.

The article essentially complains that a feature from a 20 year old API should have been included in an API designed 10 years ago. The glBegin/glEnd API is a horrible mistake from the start and it should have never existed. It's a good thing it's removed from the GLES API. OpenGL 1.x and GLES 1.x are both deprecated, more than 10 years old and should not be used any more. In any case, he's complaining about mistakes(?) made more than 10 years ago.

One major flaw in jwz's reasoning is that something was removed. Immediate mode was indeed removed from the spec but an implementation of GLES w/ immediate mode never existed. It was dropped from the spec to avoid having the GLES implementers to waste time adding a legacy drawing API that is essentially useless and has awful performance.

GLES1 was a stripped down API for early mobile 3d applications that used rather primitive hardware or software.

There are lots of flaws in the GL(ES) API, but removal of immediate wasn't one of them. If anything, they should have fixed/broken the API more and intentionally destroy backward compatibility.

The the committees designing the API's are understaffed and have too much work on their hands. They're trying to make the interests of hardware manufacturers, content creators and OEM's match. Because of all these pressures, they're not really doing a great API but at least we have some kind of well-specified standard. Calling these people idiots doesn't help anyone.

With modern 3d API's, the vertex data is pushed into buffers in video memory. If you're writing 3d code in the 21st century, that's what you should do.

So a legacy feature that the author depended on was removed and rather than updating his code to run on modern software and hardware he re-implements it in software. He spends 3 days doing it, gets pissed off and writes a blog post.

Re: If you were involved in the OpenGL ES specification, you are an idiot

#188
post #173

Earlier quoted context omitted.

If bread had changed as much as GPUs have in the past seven years, your toaster would be obsolete, too. This isn't about good engineering vs bad, this is about mature technology vs a rapidly developing field. Different characteristics beget different engineering trade offs.

Cars are switching from petrol to hybrid to electric motors, but roads still work... "Rapidly developing" is a red herring.

Bad analogy.

Car engines and transmissions are the heart of the vehicle, and those change frequently as well. Roads are a fundamental, static, landscape feature today. They're like telephone poles and fiber conduits, neither of which have changed much in recent times.

Software APIs change to match the features/needs of the users and developers. Part of this is based on the changing hardware, part on desired features. The hardware today is vastly different than when OpenGL 1.1/1.5 was available so why should we be constrained to use it in the same fashion?

In short, APIs shouldn't be static for now and forever, we'd only be limiting ourselves and ignoring the fact that sometimes things change and sometimes early decisions were wrong (or less effective than desired).

Re: If you were involved in the OpenGL ES specification, you are an idiot

#189
post #180
post #178

Earlier quoted context omitted.

Roads still work because they are too expensive to replace. GPU's and bread are not, so your argument does not make sense.

Expensive things are more likely to work? I can tell you've not worked long in this industry, my friend.

I think that paraphrase was slightly closer to the opposite of what tinco said than what he did say.
Post reply on HN