jwz, how about porting the ~Aaron extension to Mac OS X now. Too bad SGI isn't around to hold a funeral like Apple did for OS 9 :)
If you were involved in the OpenGL ES specification, you are an idiot
151–160 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#152Stealing this quote: "As with all things, the first 90% took the first 90% of the time, and then the second 90% took the second 90% of the time."
Sorry to be that guy, but that quote is over 25 years old - http://en.wikipedia.org/wiki/Ninety-ninety_rule .
Re: If you were involved in the OpenGL ES specification, you are an idiot
#153Earlier 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.
To be fair, 64-bit Windows 7 (and Windows 8) don't support Win16 (as I understand it, because you can't sneak real-mode code into x86 64-bit mode the way you can in x86 32-bit mode). OTOH, let's be clear about what Win16 is. Win16 is an API that Microsoft deprecated in 1995 (not coincidentally, when Windows 95 was released). In other words, Microsoft took 14 years to go from deprecation to significant (partial) non-s…
Sure, MS took 14 years to deprecate this
Which it absolutely doesn't mean you should wait 14 years to stop writing for Win16!
And I think that's what the rant is implying
Re: If you were involved in the OpenGL ES specification, you are an idiot
#154One committee, ten years. One jwz, three days. This is the stuff "10X" is made of.
It took NASA several decades to build a rocket to the moon, I build a Diet Code & Menthos rocket in 30 minutes. Guess I'm 1000 times the space scientist those moron at NASA are rollseyes.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#155Earlier quoted context omitted.
> 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.
Yes
GL 1.x is good for GLXGears and not that much more
(Yes, even though some games used it, etc, still...)
Re: If you were involved in the OpenGL ES specification, you are an idiot
#156Earlier quoted context omitted.
You kind of miss the point. This is a philosophical argument ILLUSTRATED through OpenGL and a port. To quote, "thou shalt not break working code"
No, I understand that point. I just don't agree with it in this case. * "thou shalt not break working code". That's not some Universal Code of Software Engineering, that's just something he made up. * No one in their right mind would expect you could port 20 year old C using OpenGL 1.x code to an iPhone with no effort. * There are plenty of reasons APIs can benefit from breaking changes. Security fixes, major archite…
"Sorry JWZ, but your X screensaver project is actually not an overriding concern driving the evolution of OpenGL ES."
Seriously, if you think that's a valid response, then you did not understand his point. Repeating something does not make it any more valid an argument.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#157Wow ... 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 want to render one frame of a cube, that's 1+6*4+1=26 calls, and for each call your cpu send data to the graphic card. There are two huge problems with that : you need to the transfer the same vertex data to the graphic card for each frame and your cpu processing power limit your graphic card processing power (because cpu calls take way more time than your graphic card takes to render a vertex).
Why was it designed like that in the first place if it's inefficient ? Easy : there were no graphic card. All the 3D rendering was done by the cpu.
So with the development of more powerful graphic card, they updated the specification. With the new api you allocate memory buffers of vertex directly on your graphic card memory and you just need to call one function to render the whole buffer. So you don't need to transfer all the vertex data at each frame, and you don't need to do gazillion of function calls to render a cube. THIS WAS IN 2004 !
So when the khronos consortium (just a reminder, the "idiots" are : Apple, AMD/ATI, Nvidia, Intel, Google, Id Software, ...) decided in 2007 to make a mobile version (ES stand for embedded system) of opengl, did they choose to base their api on something conceived in 1992 and dropped in 2004 ? OF COURSE NOT !
But why not keep it compatible ? Well it's a waste of time. Developers shouldn't use deprecated functionality since 2004 in 2012, especially when it's highly inefficient.
This guy need to grow up, understand that opengl ES main objective is not screensavers, understand that he sometimes need to update a little bit his programming knowledge and acknowledge that he's not an expert in the very complex field of gpu.
tldr; he's the idiot
Re: If you were involved in the OpenGL ES specification, you are an idiot
#158Maybe the idiot is jwz.
There was a change in the technology that needed a change in the API. Not a single GPU use a fixed pipeline anymore, so the API needs to change.
I see OpenGL as a testing platform that learned by trowing to the wall and learning what sticks. Companies create extensions and if people find it useful they became part of the language, but in any API there is a need for removing what is not used anymore or can be done much more efficient with new ways.
Maintaining code takes a lot of resources and is a pain in the ass to program, I can tell you(you have to emulate a lot of things that do not exist anymore, including BUGS or HACKS).
I could understand not being Apple extreme here, e.g look at the Apple TV and you only see new digital ports, but the other extreme, don't touch anything for 20 years because it works is equally non sense..
I remember a brand new computer that was hanged 5 seconds on the start up by a 1.4M floppy disk because the people who assembled the computer were afraid to remove the thing. I had to remove the thing, left a horrible hole and I discovered the machine had the floppy check hardwired in the BIOS!!!
You buy a computer today and it has parallel, serial and PS2 ports with an outdated BIOS with 1981 timings they can't change so they don't "break legacy standards".
You buy a computer in 2012 with a 1900x1080 pixels and the first thing you see is a horrible black screen with fuzzy letters.
Non sense. openGL needs to be way more clean that what it is now, where it is impossible to remove anything because some company of the consortium find the feature "essential" because they have some legacy code they are too lazy to update.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#159I respect jwz, but this is very much a step backwards, and while I appreciate his complaint about breaking existing APIs, this would be for programs near 20 years old targeted at a different platform. 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, and their use directly cause…
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 and an idealized rendering pipeline with just enough hardware-specific hackery in it to make it perform[1]. They did the best they could operating under the constraints of the state-of-the-art of the time and the resources they had available. And people still use OpenGL, decades later, and have done amazing things with it.
Isaac Newton said "If I have seen further, it is by standing on the shoulders of giants". Kids these days, talking about legacy technologies, would be wise to remember that.
[1] Whereas Microsoft believed in an abstraction of physical hardware, with just enough geometry in to make it useful.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#160Earlier quoted context omitted.
I'd be interested in seeing an argument explaining why these API calls smother puppies when the premise of the original article is that you can in fact offer them as an interface to the shiny new better way of doing things, without accidentally summoning cthulu. If he's wrong on that point I'd like to see a clear explanation of why.
I'm not an OpenGL expert, but my understanding is that the fixed function pipeline (FFP) is like a set of big, generic shaders and state that everybody had to go through to actually do the work of displaying 3D graphics. You could write shaders a fraction of the size that does just the work you need without having to pay the performance price for features you don't use. FFP-using code looks nice in tutorials, but per…
The idea is very simple. With fixed pipeline you have a constant pipe diameter you could not change.
Imagine that you plan to manage 3Million vertex and to draw 6M points on the screen(fragments) so you make your pipes for it.
Now , what happens when you need to update only 200 pixels but want to draw 30 Million vertex on them? You can't do it on fixed.
What happens when you want to do 10 passes to the screen(60M points) but you just use textures with 4-8 vertex?. You can't do it on fixed.
With non fixed you could just use your compute units where you need them.