>It has a different set of constraints. The point is to prune back the API for small devices
I came here to say something along these lines, but right now I'm limited on time so I don't have time to go into specific examples.
In OpenGL, there might be 5 ways to do something. Three of them are very much suboptimal, one way worked but was incredibly kludgy to write, and one was performant and pretty clean.
With OpenGL ES, they got rid of all the suboptimal and kludgy methods. The benefit today is if you write an OpenGL ES application, porting it to OpenGL nowadays is pretty easy. The other way around? Yes, that can be tremendously difficult. Honestly, I wish a lot more in OpenGL 3.x and 4.x was deprecated. Working with ES and the reduced extension hell is a big step up from the mess the full OpenGL API can be.
The point is to prune back the API for small devices
I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine.
I tend to agree that the API should have been renamed entirely once it was pared down this far, as 3Dfx did when they created Glide.
> I don't disagree with the general sentiment that it was time to clean out the cruft in OpenGL, but I find this part of the argument to be a bit humorous. These "small, constrained devices" we're talking about are probably 10x faster than a goddamned Reality Engine.
OpenGL ES 1.0 was released in early 2003, IIRC. The decision to exclude Immediate Mode from OpenGL ES 1.0 was made sometime prior to that.
2002-2003's typical mobile hardware was pretty damn weak, in particular in the areas of CPU cycles and memory bandwidth, which is where Immediate Mode really bites you in the ass. And the RAM/ROM sizes on most of these devices were small enough that every byte you could shave off the driver was a win for application writers, so there was little desire on the part of mobile graphic hardware vendors to spend memory budget on redundant features that an application could rebuild on top of lower level primitives if they so chose.
I came here to say something along these lines, but right now I'm limited on time so I don't have time to go into specific examples.
In OpenGL, there might be 5 ways to do something. Three of them are very much suboptimal, one way worked but was incredibly kludgy to write, and one was performant and pretty clean.
With OpenGL ES, they got rid of all the suboptimal and kludgy methods. The benefit today is if you write an OpenGL ES application, porting it to OpenGL nowadays is pretty easy. The other way around? Yes, that can be tremendously difficult. Honestly, I wish a lot more in OpenGL 3.x and 4.x was deprecated. Working with ES and the reduced extension hell is a big step up from the mess the full OpenGL API can be.