Re: [PyOpenGL-Users] PyOpenGL Deprecation & New Methods

[Gijs <in...@bs...>]

On 10-12-2009 17:11, Mike C. Fletcher wrote:
> Prashant Saxena wrote:
>> Hi,
>>
>> Are there any docs, article available for the deprecated function equivalent in 3.x api. Converting old school code completely
>> using new api would be difficult with out good docs and references.
>>
>> For example
>>
>>              glEnableClientState(GL_COLOR_ARRAY)
>>              glEnableClientState(GL_VERTEX_ARRAY)
>>
>>              glColorPointer(4, GL_FLOAT, 0, self.colors)
>>              glVertexPointer(2, GL_FLOAT, 0, self.vertices)
>>
>>              glPushMatrix()
>>              glTranslatef(self.x, self.y, 0) #
>>              glDrawArrays(GL_QUADS, 0, 4)
>>              glPopMatrix()
>>
>>              # Disable vertex arrays
>>              glDisableClientState(GL_VERTEX_ARRAY)
>>              glDisableClientState(GL_COLOR_ARRAY)
>>
>> This is new way to draw quads using array method but glPushMatrix, glPopMatrix, glTranslate&  glColor has been deprecated.
>>
> Actually, that's the pretty-old-but-not-quite-the-oldest way to draw
> quads (it's from OpenGL 1.1, January 1997), which is about 1/2 of the
> way to legacy free.  To go legacy-free you then convert the code to use
> shader attributes instead of the hard-coded color, vertex,
> texture-coordinate etc. arrays (that's a trivial textual change) and
> write shaders to render *all* of the quads with a single call (that's a
> bit of work if you don't know GLSL yet).  Oh, and quads are
> deprecated... you render two triangles...
>
> Matrix operations are deprecated in their entirety, with only
> shader-uniform matrices being available, i.e. you define a uniform
> called "mv_matrix", another called "norm_matrix" and calculate the
> matrices, passing them fully-formed to the shader alongside your data
> for each object.  Point form description of what needs to happen is on
> the deprecations page[1].
>
> At this point I'd say "move to using arrays (and VBOs), investigate
> shaders" is the best path to take, rather than trying to go fully
> legacy-free all in one go.  Legacy-free operation has a higher barrier
> to entry than the original OpenGL API, and when you go legacy free you
> either have to provide fallback code for older hardware or just give up
> on the less featureful hardware (e.g. my 2-year-old laptop with a crappy
> Intel Integrated Graphics chip doesn't support GLSL at all).  I'm trying
> to write a series of introductory tutorials[2] for legacy-free
> operation, but I'm short on time (perennially), so you might not want to
> hold your breath on it.
>
> HTH,
> Mike
>
> [1] http://pyopengl.sourceforge.net/documentation/deprecations.html
> [2] http://pyopengl.sourceforge.net/context/tutorials/index.xhtml
>
Nice to have some documentation/examples on OpenGL 3.x code. I spend 
quite a bit of time trying to find documentation for it but it seems to 
be very very sparse on the net. I know roughly how to replace most 
functions, though glRotate and glScale will probably be a bit annoying 
to do in shaders. However, I've never found a good replacement for 
display lists. Nor do I understand why they are deprecated at all. The 
usual answer how to replace display lists is to convert "it" to VBOs. 
But display lists can contain a whole lot more than just 
vertex/color/tex data. Quite a lot of commands can be compiled into 
display lists as well. I use it to bind all my input textures for my 
shaders for instance. Sometimes I use different input textures so I use 
different display lists for those, which can save quite a bunch of extra 
calls. But I can't really find any replacement that does stuff like this 
in the new OpenGL 3.x functions. Do you have any idea Mike?

Regards, Gijs