Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

OpenGL has so many APIs which can modify different states. It's not so obvious whether an API has global effect or local effect.

For example, rumour says glTexEnv has global effect while glTexParameter has local effect (it only affects the current bound texture). Is this true? How to determine whether an API has global or local effect?

share|improve this question

closed as not constructive by Nicol Bolas, bummzack, Byte56, Trevor Powell, Josh Petrie Apr 17 '13 at 4:30

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Are you simply looking for authoritative API documentation? –  Seth Battin Apr 14 '13 at 2:06
1  
this might be a good starting point.. opengl.org/sdk –  Jari Komppa Apr 14 '13 at 5:20
    
@SethBattin To make it precise I'm looking for a table that clearly separate all APIs into global/local. It's better if it can further separate them into client/server. –  Cyker Apr 14 '13 at 6:57
    
Just read the documentation. –  Darth Satan Apr 14 '13 at 21:06

2 Answers 2

up vote 3 down vote accepted

The OpenGL API is pretty clear, the official documentation and a good book will get you going with it easily!

You can check things like that directly by looking up the reference of the function. For example, in the sample you gave us, its made clear in the name of the function itself, one configures the texture environment, which means the "space" of all textures, the other a parameter of a texture, which applies to the currently bound texture for that target, at that texture unit.

Hope its clear enough.. :)

share|improve this answer
    
Thank you! Actually as I learn more I begin to realize -Env APIs are usually global. But to get familiar with these conventions is not quite easy for a newbie. I hope OpenGL will have some mnemonics for its API names... –  Cyker Apr 14 '13 at 6:56
    
Don't rely on -Env naming for "global" state changes. You would be better of learning opengl by functionality groups. First understand the concepts about texturing, then about other things. If you take a modular approach to learning opengl you will see it is not that hard. Also, my best advice for you right now is to understand the modern graphics pipelines and use GLSL for your learning. It will make much more sense to you if you program yourself the "server-side" of OpenGL. You will have a better understanding of the stages of the pipeline and how the functionality of OpenGL integrate it. –  Grimshaw Apr 14 '13 at 11:59

Given the definitions you've outlined here, "global effect" means "context state" and "local effect" means "object state".

Broadly speaking, no. OpenGL does not have a consistent naming scheme for what functions change object state and what functions change global state. This is primarily due to the fact that many of the functions that change object state were once only changing global state.

Yes, even glTexParameter. Texture objects only came into existence in GL 1.1. The reason OpenGL requires you to bind objects to modify them is precisely for this: so that you can't tell the difference. This way, if they later decide to make some state "object state", you would use the same APIs to set that data, rather than having separate function calls for the "old way" and the "new way".

This is better nowadays in core profile OpenGL, as most functions that modify object state are named in accord with the objects that they modify. All of the glTex functions modify texture object state (glTexEnv was removed from OpenGL in 3.1). All of the glBuffer functions modify buffer object state. All of the glFramebuffer functions modify framebuffer object state.

But even here, there are exceptions. glUniform modifies program object state, but since it doesn't take the program as a parameter, it omits the word "Program" from the name (unlike glProgramParameter or the more recent glProgramUniform). Futhermore, older calls like glReadBuffer and glDrawBuffer(s) modify framebuffer object state, despite not using the word "framebuffer". Again, that's for backwards compatibility reasons; the glFramebuffer functions were all new functionality, but setting the read and draw buffers was old stuff, and thus had to use the old APIs.

So generally speaking, no, there is no way to be certain just from looking at a function's name to know whether it modifies context state or object state.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.