deprecated functions?

hi! Is there any documentation stating which functions were removed in OpenGL ES 2.0 that were part of the fixed pipeline? Are these functions scheduled for removal?

I want to use OpenGL 2.0 in such a way.

thanks

Pretty much all fixed function stuff is gone from OpenGL ES 2.0 (you still have clipping and division by w and implicit fragment generation but that’s not what you mean I think). It is important to realize that desktop OpenGL still has all of the fixed function attributes and functionality in there though.

Of course zbuffer, stencil and color buffer blending still exist as fixed function stuff after fragment shading.

What this means is that OpenGL ES 2.0 needs a vertex shader and a fragment shader but all attributes are generic and must be defined for use in the vertex shader, there’s no such thing as material attributes or lights etc that you can just use in your shader. If you have no vertex and fragment shader there is no fixed function equivalent. So you MUST provide shaders, there’s no legacy fixed path.

Understand that this is a split with desktop OpenGL which has default fixed function vertex and fragment processing and that state to support that AND you can reference that state in your own shaders.

So 2 key difference; no default fixed function path and no legacy state or vertex attributes for use by the shaders you mush now write.

Do not confuse this with desktop OpenGL 2.0.

What I mean to do is develop in OpenGL 2 in such a way that I can port to OpenGL ES 2 in the future.

So I should rephrase my question: which functions should I avoid in order to port my OpenGL 2 app to OpenGL ES?

From your post, I assume all material/light func calls, glBegin/End (and I suppose all funcs that were not allowed outside a glBegin/End).

Thanks for the response.

No I think I answered it anyway.

There is no glBegin glEnd, with all versions of OpenGL ES you only have glDrawArrays and glDrawArrayElements, and again with 2.0 you don’t have all the various attributes to bind, just generic ones that are then referenced in the shaders.

You should realize that some drivers will only support binary shaders so no runtime shader generation/compilation but this is left to implementations to decide. There will be a mix of support, it’s an extremelty fundamental difference between implementations.

There will be a bit of low level stuff to do for example if you need to maintain an eyespace light position you’re on your own and you don’t want to compute it per vertex in your shader. If you have a stateful engine you want to port then good luck with binary only shaders, I guess you’ll have a lot of instructions on your slow path.