Live data from Hacker News

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

jwz.org

171–180 of 225 posts

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

#171
post #159

Earlier quoted context omitted.

OpenGL is a terrible, awful, crufty API, and the reason those methods were removed is that they are comically suboptimal. They do not reflect anything remotely like modern card capabilities But the guys who wrote it weren't idiots. They were in fact super smart engineers working at the cutting edge company of the day, SGI. And they made a philosophical call, which was that OpenGL should be an abstraction of geometry…

Thats not at all true. The original OpenGL API is very much a direct mapping of the original SGI graphics hardware. Most openGL calls on SGI are single cpu instructions feeding the data to the hardware, which fully implements the whole OpenGL state machine. Its just that modern GPUs work in completely different ways, so this kind of API is useless for them.

No, you have it backwards :-) SGI devised OpenGL and then implemented it in hardware, not vice versa!

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

#172

Earlier quoted context omitted.

Interesting. I hear what you are saying. To contradict everything I've said elsewhere on compatibility - I'm actually in favor of the 1.0/1.1 OpenGL ES standards and would have liked WebGL to offer 1.1. My self deceiving justification in this instance is that plenty of platforms that can touch the web are still running hardware only capable of fixed function (eg. Intel 945GM). Fixed function is easy to make safe, and…

Fixed function is no easier to make safe than shaders so that's a false assumption. OpenGL ES 1.1 on JavaScript would be a joke. Do you really think JavaScript is up to tens of thousands of glVertex glColor glNormal calls per model per frame? The rest of the graphics world left OpenGL 1.x long ago. OpenGL 4.0 has none of the fixed function stuff in it anymore either. Using fixed function features in 2012 is like usin…

I've delivered a paid contract that would say otherwise =)

(Not OpenGL ES1.1 but a similar narrow API. One frame latency penalty in my case as the calls enter a staging area for analysis one frame before tiling and dispatch).

Dont forget the original iPhone also has been fully sandboxed OpenGL ES1.x

So its already been done.

Things like PCC (NaCl) and Xax (to a lesser degree) also reveal surprising results as you would know.

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

#173

Earlier quoted context omitted.

Seven years is not a long time. My toaster is older than that, and I like to think the people who made that would be embarrassed if those cheap moving parts had decayed so quickly. You probably have enough horsepower at your disposal to emulate each and every computer you ever bought (simultaneously!) and run all that software forever. But instead we're going to require any tool you want to use to be rewritten half a…

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.

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

#174
post #131

Earlier quoted context omitted.

By the same reasoning, we should remove printf from libc. It's a terrible, awful, crufty API with threading issues, and it's overhead on modern windowed systems is just horrible.

Come now, be reasonable. If we released some sort of libc for embedded systems, specifying only fprintf(), your analogy would be valid.

In fact, the concept of "freestanding implementation" (as opposed to "hosted implementation", which is a implementation of the full standard) exists in C, and is sometimes used in embedded systems:

  a conforming freestanding implementation is only required
  to provide certain library facilities: those in ,
  , , and ; since AMD1, also
  those in ; since C99, also those in 
  and ; and since C11, also those in 
  and 
(source: http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Standards.html)

So yes, a conforming (freestanding) C implementation without printf for embedded systems can exist.

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

#175
post #150

Earlier quoted context omitted.

Eh, not any more. JWZ is a has-been, who admittedly did good things back in the 90's, but who has lost touch with the industry when he became a hobby coder. This post is a clear demonstration of that - if he knew even a little bit what he was talking about, he wouldn't make the outrageous claims he does. But no, he just want to hang on to his toys he wrote 15 years ago and have them work with just a recompile on plat…

That's just absurd. Its not absurd at all. He's got a massive collection of amazing GL-based screensavers that a LOT of people have learned graphics programming from, over the years. There are still contributions being made to this collection in 2012, and there have been consistent additions to the collection since the very early 90's. This is no toy collection. Fact is a lot of great OpenGL code could run on the iPa…

Anyone learning OpenGL from code as young as 5 years old (i.e., all fixed-pipeline code) is getting shafted because what they learn is so out of touch with the state of the art in graphics technology. Just like for the Nehe tutorials that whole generations have been brought up on. That's the whole point here, 3d graphics has moved on, and everybody working in it should, too; of course, as with anything, there are always grumpy greybeards who feel that their way of doing things is Good Enough For Them, and therefore should be supported indefinitely.

The arguments on why fixed-pipeline OpenGL should be deprecated have been re-hashed several times convincingly in this thread, I don't have to repeat them here. I don't quite see why the state of the art in graphics should be held back because some people want to see spinning teapots on their iPads without having to learn something new. You seem to be implying that programs written in the past can't be made to work on new platforms; while it's true that it would need changes to the code, please show me the decades-old program in Objective C or Java you mention that you'd like to see working on your iPad without having to change the code.

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

#177
post #175

Earlier quoted context omitted.

That's just absurd. Its not absurd at all. He's got a massive collection of amazing GL-based screensavers that a LOT of people have learned graphics programming from, over the years. There are still contributions being made to this collection in 2012, and there have been consistent additions to the collection since the very early 90's. This is no toy collection. Fact is a lot of great OpenGL code could run on the iPa…

Anyone learning OpenGL from code as young as 5 years old (i.e., all fixed-pipeline code) is getting shafted because what they learn is so out of touch with the state of the art in graphics technology. Just like for the Nehe tutorials that whole generations have been brought up on. That's the whole point here , 3d graphics has moved on, and everybody working in it should, too; of course, as with anything, there are al…

I'd love to have Electrogig 3DGO on my iPad.

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

#178
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.

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

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

#179

Earlier quoted context omitted.

Except he didn't port his code to OpenGL ES - he ported the missing API from OpenGL 1.3 to OpenGL ES. If it takes one developer three days to implement the missing API, then perhaps it suggests that this API wasn't in any way damaging to the new system and could have been left in place originally?

He didn't implement OpenGL 1.3. He ported an OpenGL 1.3 app to OpenGL ES 2.0. There's a HUGE difference.

He ported the OpenGL 1.3 app to OpenGL ES by implementing the missing parts of the API that he needed inside the OPenGL ES API (albeit, as some people have pointed out, imperfectly).

That is not the same as rewriting an app to conform to the new API. There is, as you say, a HUGE difference.

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

#180
post #178
post #173

Earlier quoted context omitted.

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

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.
Post reply on HN