Comment by hesdeadjim | Hacker News Reader

Comment by hesdeadjim | Hacker News Reader

God what flamebait, how is this near the top of the front page?

When your primary argument that the ES designers were idiots is lack of immediate mode, I'm sorry, you are the idiot. These are embedded systems with highly constrained resources and that immediate mode API is horrible for a lot of reasons:

* Requires tons of driver calls.

* Stupidly hard to optimize on the driver side when you have no idea just how many vertices or other per-vertex data are to follow your call to glBegin.

* Trivial to replace with a much better, and much, much higher performing vertex representation either through vertex buffer objects or simple calls to glVertexPointer/etc.

* Teaches beginners the Wrong Way of doing things -- you won't use this API for anything beyond a toy program as the last thing you would do is load an exported mesh from Max or Maya and then iterate through every vertex.

Having learned OpenGL initially with the ES 1.1/2.0 spec, then transitioning back to the desktop version, I couldn't believe how bloated the API had gotten. There is a reason they want to deprecate most of it and move to a spec that is similar to ES in its simplicity.

> God what flamebait, how is this near the top of the front page?

Because the source is widely respected and has an amazing demonstrated grasp of what good programming involves.

Yes but in this case he's an idiot. Try asking Carmack. Any GPU programmer knows GL 1.x was utter crap. Good riddance.

jwz, if you've been following him, is inherently pragmatic. He's a follower of the philosophy that the computer, and by extension the frameworks and languages to program it, should be subservient to the programmer. They shouldn't tell you how to live your life or behave like a stubborn mule when, for whatever well intentioned reason, people decided to overhaul the spec everyone depended on.

I think his argument is that OpenGL ES should have had an "optimal" mode, where performance is best using the newer calls, and "compatible" mode, where if you don't care about performance and just want to port, you can get by. This appears to be what the jwzgl layer does.

Essentially he's just whining that porting his project is difficult because the API doesn't have the more beginner friendly(but inefficient) drawing calls that used to be there. OpenGL ES is not designed to be beginner friendly, it's meant to give low-level access for high performance graphics. It's perfectly reasonable to use an abstraction layer on top of that for simple drawing, it's not that hard, and a quick google would probably find many projects that have done so.

Personally if your going for simple, and not performance, there are much better ways to design the api than glBegin(). So all those calls are the worst of both worlds, awkward, and slow.

OpenGL ES is for "embedded systems" which basically means phones. That means inefficient programming drains the battery. Sure if jwz want's to punish his user's I guess that's his prerogative but it seems like a good decision to provide an API that discourages bad practices.

Basically they decided to get rid of the cruft. OpenGL 1.x was designed in 1992? GPUs fundamentally changed in the mid 2000s and the decisions made for OpenGL 1.x no longer fit.

If you want 1.1 go contribute to this project. http://code.google.com/p/gles2-bc/

First rule of optimization still applies to these battery-operated GHz/GB machines. If it's not a bottleneck, don't waste complexity and time on it.

The iPad graphics subsystem absolutely destroys anything around when the OpenGL spec was released and many of these screen-savers were designed against hardware that's unbelievably slow compared to an iPad.

He's not making a game that's going to drain the battery in ten seconds flat, he's porting screensavers made in the late 1990s that were never heavy-duty to start with.

Sure. But OpenGL ES was not designed for the iPad. The decision to reject immediate mode was made in 2003, for the mobile devices of that time. And it is used in the industry for devices much less powerful than the iPad, even today.

It continues to be a popular choice for anything like the iPad, where there is no legacy software based on regular OpenGL, because it is a much cleaner and much easier to implement stack, and because if you are writing new software you should never be using all of that old deprecated cruft anyways.

Yes

GL 1.x is good for GLXGears and not that much more

(Yes, even though some games used it, etc, still...)

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 platforms that don't even remotely resemble the platforms he wrote them for back then. That's just absurd. And yes, I too complain (loudly) when I have to change code to accommodate changes in the platform (like how VS12 doesn't support WinXP) but in the end, deep down, I recognize that that's just how it has to go, and so should somebody who knows (or should know) much better than me, like JWZ.

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 iPad today, if only the false ideology of cutting 'archaic things' out of the ES profiles wasn't getting in the way. There are plenty of opportunities for OpenGL apps from decades ago to be re-targetted to the new platforms, if only for this problem - and jwz is right to point it out.

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.

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

I hadn't heard of it, but a quick google shows that it's (or rather, was) a closed-source 3d modeler that was discontinued in the late 1990's. That is another situation than the one under discussion; API backwards compatibility doesn't even apply to that product, that product would require a way to run native-code binaries, written for (presumably) Windows (or otherwise, some Unixes), unmodified on the iPad.

The point of my last sentence was that it's impossible, because that long ago Java, iPads, Cocoa etc. didn't even exist. For somebody who wants to port a C++ codebase from those days to a mobile platform, having to re-do the 3d rendering (which is only a very small part of any well-engineered large application anyway) in a programmable pipeline is the least of his worries.

> These are embedded systems with highly constrained resources Gigahertz quadcores with several gigabytes of RAM is "constrained resources" nowadays? I agree with you though - it's flamebait. But it's also true.

These "embedded systems with highly constrained resources" are machines with 512MB+ of memory and monster CPU/GPUs. It's perfectly OK to write code for them that you haven't bled over to optimize the hell out of.

And JWZ just showed you don't need "tons of driver calls" unless you mean simple function calls that don't cross the kernel boundary.

Reply on news.ycombinator.com