Hi, group. 

I've been fiddling with OGL off and on for a while now, mostly working
from one of the early editions of the redbook. Recently it came to my
attention that the manual I'm using (and as far as I can tell, most of
the tutorials online) are outdated, and a lot of the stuff in them is
now deprecated. 

Since I'm working on it on my own time with small personal projects, I
don't really have to worry about interfacing with old code; I'm thinking
I might be better off discarding the techniques I've been using and
turning to whatever's now standard. My first thought was just to pick up
the most recent redbook, but from the reviews on Amazon it seems they
included large sections of deprecated material in that version. (and the
8th hasn't come out yet) 

My question is: is it worth the effort to switch to the more recent
form? (seems to involve shaders, which I know nothing of) And if so,
what's the definitive text for learning to do OGL entirely the modern
way? I'm looking for something a bit like K&R2 was for ANSI C. 

--

Andrew

On Mar 28, 7:19=A0pm, Andrew <n...@none.com> wrote:
>
> My question is: is it worth the effort to switch to the more recent
> form?

If you're achieving what you need to achieve then
there's no need to change.

Switching to shaders means a lot of background
work.

On Mon, 28 Mar 2011 13:19:34 -0400, Andrew wrote:

> My question is: is it worth the effort to switch to the more recent
> form?

That depends upon whether you actually have a use for the new features.

> (seems to involve shaders, which I know nothing of) And if so,
> what's the definitive text for learning to do OGL entirely the modern
> way? I'm looking for something a bit like K&R2 was for ANSI C.

	http://www.opengl.org/documentation/specs/

Note that you'll need to read both the OpenGL specification and the GLSL
specification to actually be able to do anything. OpenGL itself now just
deals with managing the data which is passed to the shaders; the shaders
do all of the work. The 3.3 specification is probably the best one to
read; using 4.x features will significantly harm portability.

Since the addition of shaders, the standard has been changing rapidly.
Basically, each new generation of video cards introduces new features, and
OpenGL typically needs to change to be able to use those features
efficiently. The end result is that the "red book" tends to be obsolete by
the time it hits the shelves.

OTOH, if you have trouble learning the newer versions of the API (which is
almost completely different to 1.x) from the raw specifications, a recent
copy of the red book will at least give you the general idea of the newer
API. As a quick guide:

* glBegin/glEnd is deprecated; use glDrawArrays, glDrawElements, etc.

* gl{Vertex,Normal,TexCoord,Color}Pointer have been replaced by
glVertexAttribPointer. Vertices now have an open-ended set of attributes;
it's up to the shader what to do with them. Only attribute 0 (vertex
position) has a fixed meaning.

* Most of the state-setting functions (glLight, glMaterial, anything
to do with matrices, ...) have been eliminated. State now consists of an
open-ended set of "uniform" variables which are set by the glUniform*
functions. Again, it's up to the shader how to use these variables.
Whereas attributes are per-vertex, and interpolated across each polygon,
uniform variables are constant for any given primitive (triangle strip etc).

* Buffers. Rather than passing pointers to arrays of data, you're supposed
to copy the data into a buffer (which may be in video memory), then bind
the buffer (glBindBuffer) and pass an offset into the buffer instead of a
pointer. This avoids copying large amounts of data over the PCI bus every
frame.

Having said that, existing driver still support the legacy fixed-function
API, which can be mixed with the newer features to an extent. E.g. you can
use the fixed-function API for transformation and lighting but use a
fragment shader for rasterisation. This means that you can take existing
code and change specific portions to use the newer features, checking that
it still works before changing the next portion.

On Mar 28, 11:02=A0pm, Nobody <nob...@nowhere.com> wrote:
>
> * Most of the state-setting functions (glLight, glMaterial, anything
> to do with matrices, ...) have been eliminated. State now consists of an
> open-ended set of "uniform" variables which are set by the glUniform*
> functions. Again, it's up to the shader how to use these variables.

In other words you have to supply your own matrix math,
lighting equations, etc., when you use shaders.

> Having said that, existing driver still support the legacy fixed-function
> API, which can be mixed with the newer features to an extent. E.g. you can
> use the fixed-function API for transformation and lighting but use a
> fragment shader for rasterisation. This means that you can take existing
> code and change specific portions to use the newer features, checking that
> it still works before changing the next portion.

Hello
Will it be always like that? I mean: will all the next OpenGL versions 
keep compatibility with 1.x versions (understand "glBegin"/"glEnd", 
"glLight",etc... for unnecessarily optimized code)?
Thanks
Cathy L.

On Mar 29, 6:35=A0am, "Cathy L." <n...@now.fr> wrote:
>
> Will it be always like that? I mean: will all the next OpenGL versions
> keep compatibility with 1.x versions (understand "glBegin"/"glEnd",
> "glLight",etc... for unnecessarily optimized code)?
>

It depends how you define "always" but in
the next decade or two...? Yes.

Graphics drivers are already emulating
the legacy OpenGL via shaders. There's
no reason to stop doing so.

> Graphics drivers are already emulating
> the legacy OpenGL via shaders. There's
> no reason to stop doing so.

Thanks Fungus