Live data from Hacker News

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

jwz.org

221–225 of 225 posts

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

#221

Earlier quoted context omitted.

Finally someone actually works in the cg industry replies. +1 to this. No one really uses fixed function stuff these days, everything is shaders and vertex and index buffers. There are no fixed function hardware units, everything in the graphics pipeline is programmable and done in shaders. Even using fixed function stuff on today's hardware forces the driver to compile a built in shader. In the interest of keeping d…

Old code doesn't just convert itself to using shaders and vertex and index buffers. Also: old code isn't necessary un-useful code.

And if that were the end of the story, I think we'd be able to call it a day. But everyone has this funny expectation that that old code should keep getting faster with newer GPUs, in spite of the fact that GPUs don't work the way those programs were designed to use them.

Getting modern GPU performance, or anything close to it, through the crufty old immediate-mode API code is like drawing blood from a stone. Eventually developers need to take some responsibility for the code they're maintaining and migrate to a more modern API. Even on the desktop they'll have to do this - when their customers ask for modern GPU features, they'll have to move to OpenGL 3, which doesn't have immediate-mode either.

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

#222
This all makes me wonder, is it hindering to learn open gl even if you want to develeop prmarily for android/iphone. On one hand I would say: Yes it is hindering. On the other hand, it feels like a good idea to learn open gl, in order to now how and what a rendering pipeline is, gl state machine, etc. What do you guys think ?

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

#223

Earlier quoted context omitted.

X11: 1987. Still works in 2012.

X11, not backwards compatible with X10 or X9. OpenGL 4.2, backwards compatible to OpenGL 1.0 (1992) OpenGL ES, not backwards compatible with OpenGL. There's an obvious parallel here of APIs being compatible within themselves but not across boundaries between major architectural revisions intended to throw out cruft and target new environments.

[deleted]

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

#224

Earlier quoted context omitted.

The source is available in http://www.jwz.org/xscreensaver/xscreensaver-5.16.tar.gz and he mentions that in his blog post. How much more help are you expecting him to provide? Why would it be any more "helpful" for him to put it in some revision control system instead of just posting the source?

I meant the OpenGL wrapper part, not the entire xscreensaver code base. It's kind of hard to fork a tarball.

How hard is it to untar, take the header and do whatever you want with it (including putting it on github if you want)?

It's definitely a lower barrier to entry than requiring people to create a github account!

Edit: the point being, that it's not just "in the tarball": it's in a specific header file, and the blog post says which exact header file you want.

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

#225

Earlier quoted context omitted.

* It costs money to document. * It costs money to implement. Three days for a lone coder, much more than that for a careful consistent development process. * It costs money to develop regression and validation tests. * It costs money to test, including collecting all the different hardware it needs to be tested on. * It costs money to fix bugs in it. * It costs money to answer questions from developers about it. * Th…

While that's all true - it completely ignores the externalities. It cost Jamie 3 or 4 attempts and eventually 3 days work to get his unbroken code running on the new OpenGL version. What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES? Sure, maintaining backwards compatibility is costly for a project like OpenGL. But if you choose…

> What's the multiplier needed to account for the cost this change incurred for all the other developers who wrote code using OpenGL before ES?

Let me ask you that - please list as many examples as you can think of of code written for OpenGL 1.x that would make sense to port to embedded devices.

I'll kick off the list:

* xscreensavers ...

Post reply on HN