Re: [Shallows-devel] Should glProgram::activate/run call glEnableClientstate?

[Jon H. <jon...@gm...>]

Hi,
 my main concern is how to disable the client state. Therefore I do not
think that activate() should set the pointer and enable the client state.
What we can do is to add a drawArrays function that enables the client
states, draws the arrays (indexed or not) and then either disables the
client state or pops the previous state.
 The next question is what to do with the pointer itself. If the pointer is
kept and glVertexAttribPointer is called every time the drawArrays are
called then the pointers are read and the data are transferred into graphic=
s
memory each time the draw function is called. This may not be the behaviour
expected from the user.
 If we decide to start implementing such functionality we should probably
also implement support for VBO and render (copy) to vertex array as well...
 Jon

 On 10/6/05, Johan Seland <jo...@if...> wrote:
>
> Hello!
>
> I am currently developing a program where we are using vertex
> attributes, and in order to get my attributes read correctly from an
> array I have to to the following:
>
> shader.setAttribPointer( "VerLod", 1, GL_FLOAT, 1, &attribs[0], false );
> shader.enableClientState( "VerLod" );
> shader.activate();
>
> Should not glProgram::run/activate enable this by itself? The user has
> clearly stated that he intends to use a vertex attributes from a
> pointer, why must he say so one more time.
>
>
> --
> Help a man with his math problems and you get him off your back for a day=
.
> Teach a man math, and you scare him off for the rest of your life.
>
> Regards Johan Seland
> PhD Student
> Center of Mathematics for Applications
> University of Oslo
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Shallows-devel mailing list
> Sha...@li...
> https://lists.sourceforge.net/lists/listinfo/shallows-devel
>