Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jwz.org

Post reply on HN
Print view View original

191–200 of 225 posts

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

#191

Post by roel_v »

seclorum wrote: post #177
roel_v wrote: post #175

Earlier quoted context omitted.

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.

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.

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

#192

Post by the_mat »

haxe wrote: post #157

Wow ... this guy is just an arrogant idiot ... You first need to understand that opengl specification are not made to be easy to use, but efficient. And the api design is highly constraint by the hardware. You also need to understand that opengl 1.3 is FCKING 11 YEARS OLD ! Back in the day you had immediate mode. You first call glBegin, then make one call to glVertex for each vertex and finally call glEnd. So if you…

You missed a key point: with OpenGL 1.3 you don't need to follow the glBegin/glVertex/glEnd paradigm. You can create a display list or you can use vertex arrays. In fact the reason for including display lists in the first place was to make it so you didn't have to send one vertex at a time.

I don't agree with JWZ, regardless. OpenGL ES was a good simplification to the overall system. But he is right in that an optional compatibility layer that lives on top of OpenGL ES would have kept the original API valid for those who need it (and without slowing down the core of OpenGL ES).

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

#193

Post by zurn »

greggman wrote: post #144
astrodust wrote: post #116

Earlier quoted context omitted.

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 th…

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 m…

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.

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

#194

Post by Spooky23 »

briandear wrote: post #186
psykotic wrote: post #88

Earlier quoted context omitted.

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

The difference is that tens of thousands of business users used System 9. The Microsoft platform probably had hundreds of millions.

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

#195

Post by astrodust »

TazeTSchnitzel wrote: post #182
astrodust wrote: post #117

Earlier quoted context omitted.

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.

That's why it's bothering a lot of people that it has "GL" in the name at all.

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

#196

Post by astrodust »

greggman wrote: post #144
astrodust wrote: post #116

Earlier quoted context omitted.

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 th…

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 m…

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.

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

#197

Post by alttab »

seclorum wrote: post #164
johnl87 wrote: post #128

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.

Maybe not - but imagine the loss in hardware sales and ecosystem revenue if everyone ported old shitty games without re-writing them, causing batteries to die quickly and a poor user experience?

It was for the better of the industry. Boo-hoo. If it took him 3 days then hes a smart fucker. As someone with plenty of OpenGL AND OpenGL ES experience, I'd say it would have taken him just has much time to port his existing code.

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

#198

Post by gioele »

greggman wrote: post #105
bigiain wrote: post #101

Earlier quoted context omitted.

" … but to instead encourage third parties to distribute such libraries." What _I_ took away from jwz's rant (and agree with), is that if providing backwards compatibility to existing users is something one guy can do in three days (including doing the research to find out exactly what's getting taken out of an API), then it seems entirely reasonable to expect a "well behaved" standard like OpenGL to have provided th…

It's not something that can be done in 3 days. Fixed function on top of shaders is a PITA. If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit. glBegin, glEnd are shit APIs given how GPUs work now-a-days. Worse, things like flat shading require generating new geometry on the fly. Fixed functio…

> If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit.

I think jwz's point is that he prefers having his old code run very slow through a compatibility layer rather than having to port the same not-so-important old code over the new APIs.

He wants to trade developer time for execution time, something that may be very sensible in some cases (probably not in most, but for fancy screensavers...).

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

#199

Post by gioele »

retrogradeorbit wrote: post #148
bzbarsky wrote: post #119

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.

That is exactly what mercurial users say about code distributed on github. :)

Please respect the author's right to decide how to distribute his code.

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

#200

Post by w0utert »

gioele wrote: post #198
greggman wrote: post #105

Earlier quoted context omitted.

It's not something that can be done in 3 days. Fixed function on top of shaders is a PITA. If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit. glBegin, glEnd are shit APIs given how GPUs work now-a-days. Worse, things like flat shading require generating new geometry on the fly. Fixed functio…

> If you want any kind of speed you've got to generate shaders on the fly based on which features you've turned on or off. Otherwise you create an uber shaders that's show as shit. I think jwz's point is that he prefers having his old code run very slow through a compatibility layer rather than having to port the same not-so-important old code over the new APIs. He wants to trade developer time for execution time, so…

> I think jwz's point is that he prefers having his old code run very slow through a compatibility layer rather than having to port the same not-so-important old code over the new APIs.

If that's what you want, just write it yourself once (which he did) or use one of the many (subsets of) fixed-function pipelines running on OpenGL ES that others have made. The official 'Programming OpenGL ES 2.0' book even shows you how to do most of it, with example code included.

What jwz fails to recognize is that OpenGL ES does not only have to run on iPads, iPhones or other relatively high-powered mobile devices, but also on extremely low-powered devices with really small memory sizes (RAM and ROM) where every byte (code or data) counts. Compared to mobile devices at the time the first OpenGL ES API's were designed, an iPad could almost be considered a supercomputer. For OpenGL ES, small API size was one of the design constraints, simple as that.

Last but not least, OpenGL ES was supposed to become the industry standard for mobile 3D graphics, which means it needed strong industry support. Stuffing the API with loads of crap that almost nobody would use would drive up implementation costs for no good reason. Programmable shaders are called 'programmable' for a reason, if you want to do very specific stuff with them (such as emulating the fixed-function OpenGL pipeline), there is nothing preventing you to do so.

The single point I can kind of agree with is that maybe they should not have used 'OpenGL' in the name of the API, because it suggest at least some form of compatibility with previous OpenGL versions. Confusing indeed, but not really worth the kind of rant in this article.

Post reply on HN