I strongly vote against mix-n-match. You need to know FF and programmable pipeline pretty good in order to get to them play well together. Not recommended for a beginner.

Don't get me wrong - I certainly wouldn't recommend it as a long-term viable solution. The obvious objective is to get everything onto a shader-based API and the issue is finding the easiest way of getting there. Porting an existing program, where you can just port a small part of it at a time, is one way of doing this, and the ability to mix shader code with FFP code is useful there because it doesn't put you in a position where you need to junk everything and start over from scratch. Instead you can take something simple, like your 2D GUI, and invest some time and effort into getting that up and running with shaders while leaving the rest unaffected.

There's a rant somewhere inside me about how the old GL_ARB_*_program extensions made this kind of thing easier than GLSL, but that's for another time.

Can't you stay with GLES 1?

Earlier OpenGL versions were basically small engines, that handled the camera and lighting and materials for you, while the new versions simply map to rendering pipeline stages or hardware functionality. Making all the new stuff that's available now fit nicely into the old API is difficult, and an engine like that is both a complex piece of software and unnecessary for those who want to customize instead. Therefore the responsibility for those things were moved from the API to the application.

If you want something that handles those things for you while still enabling you to write shaders, I would recommend searching for engines that wrap GLES 2.

(Also, with the way hardware worked when the old GL was designed it made more sense to have that functionality in the API, while nowadays there's no benefit that can't be had by using an intermediate library instead).

Can't you stay with GLES 1?

Unfortunately not. Need environment mapping.

Can't you stay with GLES 1?

Unfortunately not. Need environment mapping.

What type of environment mapping?

That can probably be done with GLES 1..

I know what you feel. It seems like the entry level to using OpenGL ES 2.0 is pretty high. You need to understand shaders, binding variables, vertex buffers, and some of the math that opengl did for you before. It is a lot to take in at first and it can be difficult to manage all the different shaders. However, once you get past a lot of the boiler plate code for es 2.0 I find that I like the flexibility it offers. Those are some of my thoughts on it.

The entire point of using an API is to enable coding on a higher level of abstraction. That's it. There is no other point of using an API.

The programmable pipeline "upgrade" actually LOWERS the abstraction level, forcing the user to deal with pixel operations and other low
level stuff that used to be handled by the API. It's a classic case of one step forward, two steps backwards.

In what twisted, psychotic sense of the word is that progress?

A matter of opinion. The fact that the API is no longer doing some of those things for me is quite a welcome advancement to me.

I’d rather be in control over those things myself so that I can decide how pixels appear on the screen on my own terms.

I stayed away from shaders for a long time myself due to how daunting they can seem to the uninitialized, but to the initialized the step towards shaders and away from the fixed-function pipeline is nothing short of a blessing.

To put it bluntly, just because handling pixel operations may be a nuisance to you does not mean the rest of us should have to suffer. To the rest of us, that level of control is quite welcome.

And by the way, environment mapping is entirely possible in OpenGL ES 1.0, so if you are upgrading under the belief that it is the only way to do what you want you have been sadly mislead. However, it is easier in OpenGL ES 2.0, so it is still the correct actin to take.

L. Spiro

The programmable pipeline "upgrade" actually LOWERS the abstraction level, forcing the user to deal with pixel operations and other low
level stuff that used to be handled by the API. It's a classic case of one step forward, two steps backwards.

No it doesn't, version 1 is still there, you're not forced to deal with anything you didn't do before. If you choose to deal with new functionality that didn't exist before then there are some extra steps required. What you're talking about is a completely new engine that wraps the new functionality in a similar way as the old functionality is wrapped in version 1. There are engines that can do that for you, it's just that there's no such engine built into GLES. The old engine is still there as version 1.

With shaders there are 100 ways to do the same thing. Every engine chooses one way to do those things, that the implementers determine to fit their purposes the best. This is usually a matter of opinion, so for Khronos to include one of those ways as some sort of standard wrapper is meaningless, as 99 times out of 100 you would still have to rewrite it to get the best way for your particular situation or opinion.

When the original OpenGL was implemented there weren't 100 ways to do things, so back then it made sense. Now it doesn't.

Anyway, there are some great tutorials at learnopengles.com. Just completed the first one and I'm beginning to see the light;-)