Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

New functions for deprecated glVertexPointer, etc

1,119 views
Skip to first unread message

anton

unread,
Oct 5, 2012, 5:01:14 AM10/5/12
to
Hi all,

I have a small graphics library based on OpenGL which I use for
educational purposes. For drawing primites, the library uses vertex
arrays, using glVertexPointer, glNormalPointer and glTexCoordPointer
functions.

The problem is that these functions are now deprecated, and I should use
vertex attributes instead. Looking on the web, I came up with this link:

http://www.opengl.org/registry/specs/ARB/vertex_program.txt

which states (Section 2.7):

Implementations may, but do not necessarily, use the same storage for
the current values of generic and certain conventional vertex
attributes. When any generic vertex attribute other than zero is
specified, the current values for the corresponding conventional
attribute in Table X.1 become undefined. Additionally, when a
conventional vertex attribute is specified, the current values for the
corresponding generic vertex attribute in Table X.1 become undefined.
For example, setting the current normal will leave generic vertex
attribute 2 undefined, and vice versa.

and gives the following table:

Generic
Attribute Conventional Attribute Conventional Attribute Command
--------- ------------------------ ------------------------------
0 vertex position Vertex
1 vertex weights 0-3 WeightARB, VertexWeightEXT
2 normal Normal
3 primary color Color
4 secondary color SecondaryColorEXT
5 fog coordinate FogCoordEXT
6 - -
7 - -
8 texture coordinate set 0 MultiTexCoord(TEXTURE0, ...)
9 texture coordinate set 1 MultiTexCoord(TEXTURE1, ...)
10 texture coordinate set 2 MultiTexCoord(TEXTURE2, ...)
11 texture coordinate set 3 MultiTexCoord(TEXTURE3, ...)
12 texture coordinate set 4 MultiTexCoord(TEXTURE4, ...)
13 texture coordinate set 5 MultiTexCoord(TEXTURE5, ...)
14 texture coordinate set 6 MultiTexCoord(TEXTURE6, ...)
15 texture coordinate set 7 MultiTexCoord(TEXTURE7, ...)
8+n texture coordinate set n MultiTexCoord(TEXTURE0+n, ...)

Now my question :-) Reading the above quote, it is safe to assume these
transformations in the code will work (on all platforms, that is)?

glVertexPointer(...) -> glVertexAttribPointer(0, ...)
glEnableClientState(GL_NORMAL_ARRAY) -> glEnableVertexAttribArray(2)
glNormalPointer(...) -> glVertexAttribPointer(2, ...)
glClientActiveTexture(GL_TEXTURE0) -> glEnableVertexAttribArray(8)
glTexCoordPointer(...) -> glVertexAttribPointer(8, ...)

thanks in advance,

anton

Nobody

unread,
Oct 5, 2012, 7:05:48 AM10/5/12
to
On Fri, 05 Oct 2012 09:01:14 +0000, anton wrote:

> Now my question :-) Reading the above quote, it is safe to assume these
> transformations in the code will work (on all platforms, that is)?

No. If you want to avoid the deprecated functions, you have to install a
program with glUseProgram() and you need to use glGetAttribLocation() to
query the index for each attribute.

The deprecated functions won't be going away any time soon. However, if
you need the code to work with a 3.x "core profile" context, you have to
write your own shaders, as there is no fixed-function pipeline in the core
profile. There are no client-side vertex arrays either, so you have to use
VBOs (i.e. the "pointer" argument to glVertexAttribPointer() must be an
offset into the buffer bound to the GL_ARRAY_BUFFER target, not a pointer
to client memory).

Lars Pensjö

unread,
Oct 5, 2012, 8:00:47 AM10/5/12
to
And then, depending on what the educational purpose is, it may be wrong to use deprecated functionality even if it will still work.

anton

unread,
Oct 8, 2012, 3:08:29 AM10/8/12
to
Hi,

On 2012-10-05, Nobody <nob...@nowhere.com> wrote:
> On Fri, 05 Oct 2012 09:01:14 +0000, anton wrote:
>
>> Now my question :-) Reading the above quote, it is safe to assume these
>> transformations in the code will work (on all platforms, that is)?
>
> No. If you want to avoid the deprecated functions, you have to install a
> program with glUseProgram() and you need to use glGetAttribLocation() to
> query the index for each attribute.
>

thank you for the informative answers. So I assume that there is no way
for using glVertexAttribPointer without using shaders. Too bad, because
my idea is to introduce shaders later in the game: first explain the
fixed pipeline, and then use shaders etc. And I wanted to have the same
codebase in the library, but now I see I'll need to use conditional
compilation or something.

The thing is that doing the conversions I mentioned in the firts post
does really work in at least two platforms, but I suppose it was pure
luck. But the reading of the mentioned OpenGL document confused me ;-)

thanks again,
anton

fungus

unread,
Oct 8, 2012, 7:04:11 AM10/8/12
to
On Monday, October 8, 2012 9:08:30 AM UTC+2, anton wrote:
>
> thank you for the informative answers. So I assume that there is no way
>
> for using glVertexAttribPointer without using shaders. Too bad, because
>
> my idea is to introduce shaders later in the game: first explain the
>
> fixed pipeline, and then use shaders etc. And I wanted to have the same
>
> codebase in the library, but now I see I'll need to use conditional
>
> compilation or something.
>

Stuff like this should be wrapped up as an object
anyway. That way you only change code in one place
when you move things around.

Littering your code with calls to glVertexPointer()
(or whatever) is never a good idea.

Nobody

unread,
Oct 8, 2012, 12:37:56 PM10/8/12
to
On Mon, 08 Oct 2012 07:08:29 +0000, anton wrote:

>>> Now my question :-) Reading the above quote, it is safe to assume these
>>> transformations in the code will work (on all platforms, that is)?
>>
>> No. If you want to avoid the deprecated functions, you have to install a
>> program with glUseProgram() and you need to use glGetAttribLocation() to
>> query the index for each attribute.
>
> thank you for the informative answers. So I assume that there is no way
> for using glVertexAttribPointer without using shaders.

No. And there's no point, either. The only place where you don't have the
legacy functions (glNormalPointer() etc) available is in a 3.x "core profile"
context, and that requires shaders (and VBOs).

> Too bad, because
> my idea is to introduce shaders later in the game: first explain the
> fixed pipeline, and then use shaders etc. And I wanted to have the same
> codebase in the library, but now I see I'll need to use conditional
> compilation or something.

You can do it the other way around, i.e. start with the fixed-function
pipeline, then introduce shaders using the compatibility attributes
(gl_Normal etc) and compatibility uniforms (gl_ModelViewMatrix etc), then
replace them with generic attributes.


0 new messages