mhh, no thread regarding the OpenGL 2.0 Spec ? Ok, then I will start one 
After a quick read I’m missing the float texture formats. Shouldn’t they become part of the OpenGL 2.0 spec?
Yes, originally floating point texture formats should be a part of OpenGL 2.0 but AFAIK they didn’t make it in time. There will be an extension covering this feature but I don’t know when it will be released.
But I’m a little bit confused about the extensions which where promoted into OpenGL 2.0 core. For example they say for two sided stencil they use ATI_seperate_stencil and a state of EXT_stencil_two_side. So which extension should be used for Windows where only OpenGL 1.1 is available? Will there be an ARB extension or simply use ATI_seperate_stencil?
There is no need use the ARB, EXT or vendor specific versions of the core routines. OpenGL 2.0 Drivers will expose entry points all core routines, but they have to be loaded via the standard extension mechanism (ie wglGetProcAddress(“glGetHandle”); instead of wglGetProcAddress(“glGetHandleARB”); )- of course wglGetProcAddress(“glGetHandleARB”); should still return the correct entry point, since most drivers include extensions which have already gone into core.
The ATI_seperate_stencil is weird! I don’t know what to use… I think the extension to use is ATI’s but what state does it get from EXT_stencil_two_side?
Originally posted by mw:
…
Oh, thanks! Didn’t know that!
Hi!
I hope I’m wrong, but I didn’t find how to change render target. Could it be that it isn’t part of OpenGL 2.0 spec? Hope not 
Could it be that it isn’t part of OpenGL 2.0 spec? Hope not
Abandon all hope.
There was quite a bit of debat about the separate stencil issue. The API that is in OpenGL 2.0 does not exactly match ATI_separate_stencil or EXT_stencil_two_side . Basically, the API in OpenGL 2.0 adds functions to set the new state, like the ATI extension, but allows all state to be separately specified, like the EXT extension.
If you’re on pre-2.0, use whichever extension is available. AFAIK, there won’t be an ARB version of the extension. That shouldn’t matter because all of the existing cards that support either of the existing extension can support 2.0. 
My personal opinion is that new code wanting to use two-sided stencil should just use the 2.0 API.
Originally posted by idr:
My personal opinion is that new code wanting to use two-sided stencil should just use the 2.0 API.
And where is this “2.0 API”?
Originally posted by idr:
There was quite a bit of debat about the separate stencil issue. The API that is in OpenGL 2.0 does not exactly match ATI_separate_stencil or EXT_stencil_two_side . Basically, the API in OpenGL 2.0 adds functions to set the new state, like the ATI extension, but allows all state to be separately specified, like the EXT extension.
I didn’t quite get it. I though that if you use glStencilOp, it sets up both faces.
If you use the separate version, you can select front or back.
Which would be good, cause it matches the blending behavior where you can specify how RGB and alpha can be treated. glBlendEquationSeparate I think it was called.
Originally posted by V-man:
[b]I didn’t quite get it. I though that if you use glStencilOp, it sets up both faces.
If you use the separate version, you can select front or back.
Which would be good, cause it matches the blending behavior where you can specify how RGB and alpha can be treated. glBlendEquationSeparate I think it was called.[/b]
So, the ATI extension allowed separate state for everything except the stencil ref value and the mask value. The ATI extension was a little bit quirky in that one function takes a face selector value (like glMaterial), and the other function takes explicit front and back values (like glBlendFuncSeparate / glBlendEquationSeparate).
The EXT extension was fully orthogonal for all current and future stencil state. It did this by way of a single new function that selected which facing (front or back) was to be updated (like is done with multitexturing).
The debate was about whether it would be better to, basically, just move the EXT version into the core or do something different. The decision was to follow the model of glStencilOpSeparateATI and add a facing selector to StencilOp (calling the new function StencilOpSeparate) and StencilFunc (calling the new function StencilFuncSeparate). The new API looks more like the ATI extension but provides the orthogonality of the EXT extension. The pre-2.0 functions work exactly like calling the new functions with GL_FRONT_AND_BACK.
Looking at the Delphi3D entry , I suspect that all hardware that currently supports the EXT version will get OpenGL 2.0 support. Since the hardware doesn’t seem to be fully front/back stencil orthogonal, I don’t think the same can be said for the ATI version. If I were to write an app that had to support multiple flavors of two-sided stencil support, I would write wrapper functions that made the extensions look like the 2.0 API. For the ATI extension, it should probably print a warning if impossible state (i.e., front mask != back mask).
Thanks that cleared it up. Is it certain that ATI cards can’t do the GL2 version in hw?
It’s not certain, but it seems reasonable that if the R300 family was fully orthogonal, then the ATI extension would have exposed everything the hardware could do. My guess is that the hardware can do exactly what the extension exposes. The newer hardware can probably do everything. Like I said, that’s just my guess.