He probably won't be very happy to know OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1.
If you were involved in the OpenGL ES specification, you are an idiot
21–30 of 225 posts
Re: If you were involved in the OpenGL ES specification, you are an idiot
#22OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…
An incremental only approach to design is non-design in my view. Nearly all design is incremental. That's how design works. That's partly why chairs are still recognizably chairs, and other useful stuff like that.
Quite true. But there is another word there "only".
Re: If you were involved in the OpenGL ES specification, you are an idiot
#23My understanding is OpenGL ES is intentionally designed to be a subset of OpenGL so mobile devices can be simpler and therefore cheaper. It shouldn't be surprising mobile hardware and software is more limited. If deleting 80% of the platform features made your iPhone $50 cheaper and last another hour on battery, surely that's worth it?
Also, I believe the reason glVertex was removed is because it is a very inefficient way to draw. It wastes a lot of CPU time in "jump in to glVertex function, do a tiny amount of work, jump out of function, jump in to glVertex function, do a tiny amount of work...". It's to the extent that glDrawArrays is always faster. Take a buffer, fill it with data as fast as memory can transfer it, then a single function call to send all the data in one go, resulting in negligable overhead. Interesting anecdote: at least in my work in 2D games, modern GPUs are so fast they can render a quad faster than you can write its vertices to a vertex buffer on the CPU. So performance is limited by the CPU overhead! So this really makes a huge difference to the performance of some applications. And on mobile performance is usually more of an issue. So by removing the old functions, you're forced to do it in a more efficient way which may boost your framerate. Not so bad, huh? Unless, of course, you write a compatibility layer on top, which will reverse the performance gains.
Another reason there isn't a compatibility layer is it isn't OpenGL's job: it's supposed to be a super thin layer on the hardware so you can interface to the capabilities of the hardware as efficiently as possible. I also expect writing a compatibility layer that is standards-compliant in the general case is extremely difficult - check out all the effort that went in to ANGLE, for example.
So I think it's just a misunderstanding of the purpose and design of the tools. In future, I guess porting from OpenGL ES to desktop OpenGL would be a lot easier. 0.02
Re: If you were involved in the OpenGL ES specification, you are an idiot
#24I don't know much about OpenGL ES in particular, but backwards compatibility arguments are very tricky in general.
On the one hand you have all the people maintaining legacy apps and not interested in improving their code. They'll scream at you for breaking BC. On the other hand you have other people complaining that the library sucks due to all the old stuff and why they don't just remove all the crap.
I noticed this in particularly in the context of PHP. People really hate some parts of the language (for good!) and commonly demand a big BC breaking release that fixes all the bad parts. But every time something is fixed (obviously breaking BC in some way) there is a big outcry about wtf the developers have been thinking and whether they are all braindead - well, the usual stuff.
So really, before you start calling people idiots because they didn't keep comparability with an older version (or here even a completely different version), think again. There probably was a lot thought put into the decision. It's not like people just say "Oh, let's drop this, just so everyone can change his code!"
Re: If you were involved in the OpenGL ES specification, you are an idiot
#25My understanding is OpenGL ES is intentionally designed to be a subset of OpenGL so mobile devices can be simpler and therefore cheaper. It shouldn't be surprising mobile hardware and software is more limited. If deleting 80% of the platform features made your iPhone $50 cheaper and last another hour on battery, surely that's worth it? Also, I believe the reason glVertex was removed is because it is a very inefficien…
Part of the story here is that OpenGL ES isn't a new version of OpenGL, it's a different API for different platforms. It's nice if you can take old code and make it run on a mobile device easily but overall that's probably a small consideration compared to having an clean API that performs well.
If we want to focus on immediate mode specifically, it arguably shouldn't be used even in regular old OpenGL. It's slower and results in overly verbose code. Most people seem to use immediate mode because that's what most of the tutorial examples use.
Maybe one way to tackle the switch from immediate mode -> vertex arrays (and maybe quads -> triangles) is just to make some macros that take old code blocks and generate new ones.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#26One committee, ten years. One jwz, three days. This is the stuff "10X" is made of.
You're comparing completely incomparable tasks. JWZ did nothing but write a thin wrapper. The committee didn't omit such a wrapper because they couldn't accomplish it, they ommitted it as a deliberate design decision.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#27This rant should probably say "my iPhone could run a full OpenGL implementation, and instead I'm provided a subset. I proved that it could run full OpenGL by writing most of the missing parts". "(OpenGL ES) is a subset of the OpenGL" according to http://en.wikipedia.org/wiki/OpenGL_ES
Was there ever any question over whether an iPhone could run a full OpenGL implementation?
Perhaps the people JWZ should be complaining about are those who decided to provide OpenGL ES instead of OpenGL proper on the iPhone in the first place.
Re: If you were involved in the OpenGL ES specification, you are an idiot
#28OpenGL ES is not designed to be OpenGL. It has a different set of constraints. The point is to prune back the API for small devices - NOT - to make make migration of legacy code simple. For sure it would be nice if it came with a client side library to emulate OpenGL to assist in migration where people dont care about foot print size or perf. JWZ is a very smart guy and I respect his opinion, but he is coming from a…
Now that smartphones and tablets have respectable GPUs in them, is there any reason why they shouldn't implement the full OpenGL spec?
Re: If you were involved in the OpenGL ES specification, you are an idiot
#29Wasn't the whole point of the reduced API surface area in ES so that implementors only had to write the code that actually interfaces to the graphics hardware and let higher level libraries and engines deal with abstracting it appropriately for the task at hand?
Re: If you were involved in the OpenGL ES specification, you are an idiot
#30My understanding is OpenGL ES is intentionally designed to be a subset of OpenGL so mobile devices can be simpler and therefore cheaper. It shouldn't be surprising mobile hardware and software is more limited. If deleting 80% of the platform features made your iPhone $50 cheaper and last another hour on battery, surely that's worth it? Also, I believe the reason glVertex was removed is because it is a very inefficien…
Part of the story here is that OpenGL ES isn't a new version of OpenGL, it's a different API for different platforms. It's nice if you can take old code and make it run on a mobile device easily but overall that's probably a small consideration compared to having an clean API that performs well. If we want to focus on immediate mode specifically, it arguably shouldn't be used even in regular old OpenGL. It's slower a…
Are you sure it's fair to call it a different API? OpenGL ES is officially described as "well-defined subsets of desktop OpenGL" [1], which would suggest it has a great deal in common with desktop OpenGL.