Because the source is widely respected and has an amazing demonstrated grasp of what good programming involves.
Because the source is widely respected and has an amazing demonstrated grasp of what good programming involves.
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.
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.
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.
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.
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.
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/
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.
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.
GL 1.x is good for GLXGears and not that much more
(Yes, even though some games used it, etc, still...)