You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems I have successfully implemented glVertexPointer (not to mention glColorPointer) in my wrapper on top of the necessary WebGL (ES 2.0) calls, but there is one fundamental difference remaining, which is quite an important one.
The difference is that these two functions, strictly speaking, represent the deprecated feature of client-side vertex arrays. In modern OpenGL, server-side (cached to the GPU's video RAM, in OpenGL server-side memory) vertex arrays are the only way to go. Deprecating these two functions was not really a matter of the functions themselves being obsolete, so much as it was the technical detail behind them that they referred to CPU-side system memory.
That is what I am not emulating in this wrapper.
In example: You can do this in GL [ES] 1.x.
#include<GL/gl.h>staticGLfloatvertex_array[] = {
-1, +1,
-1, -1,
+1, -1,
};
voiddraw_right_triangle(void)
{
glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(2, GL_FLOAT, 0, &vertex_array[0]);
glDrawArrays(GL_TRIANGLES, 0, 3);
vertex_array[1*2+0] =+1;
vertex_array[1*2+1] =+1; /* Now the right angle is at (1, 1), not (-1, -1). */glDrawArrays(GL_TRIANGLES, 0, 3);
}
In my current wrapper, this will not work because my implementation of glVertexPointer does not go through global state machine flags to pre-buffer the vertex array's pointer address to be uploaded for the next time that any and every subsequent call to DrawArrays or DrawElements is done.
It would need to be done this way at the moment if using my wrapper:
The long and short of it is that currently I have to call glVertexPointer repeatedly for every time I want to use the C language (or JavaScript or whatever) to update the vertex array that is about to be drawn to the screen.
Reasons I have not (yet?) implemented the client-side vertex array behavior:
I don't know how to do it in JavaScript. In C, glVertexPointer sends the address to system memory to a C array where your vertices are all currently looked at every time the array is drawn to primitives, but in JavaScript, I don't have any clue how to pass addresses (or references, I guess).
It is removed anyway. Server-side vertex arrays are faster because drawing the arrays doesn't need to constantly read from CPU-side system memory at the pointer address specified by the last call to VertexPointer.
To demonstrate that deprecating these functions was naively overzealous. Many people play "follow the leader" with Khronos' insistence to deprecate and remove these functions as a stereotypical gesture of enforcing low-level-only, performance-only graphics programming. For example, ES 2.0 replaces glVertexPointer with almost the exact same function but under a different name with only 2 differences (neither of which, the function name represents): a) being per-attribute, where each attribute is customizable/inventable within GLSL scripting, and b) setting the pointer to server-side video memory, not client-side vertex memory in C language arrays.
Maybe in the future, if I do see a way to construct reference-able symbols out of JavaScript arrays, I can implement the remaining client-side and deprecated portion of glVertexPointer's behavior, but until then, I think the current server-side method of handling it:
promotes better performance, esp. if re-using the same video memory over and over
successfully represents a transitive, mutually compliant practice of GL programming in between GL ES 1.1 and ES 2.0
The text was updated successfully, but these errors were encountered:
It seems I have successfully implemented
glVertexPointer
(not to mentionglColorPointer
) in my wrapper on top of the necessary WebGL (ES 2.0) calls, but there is one fundamental difference remaining, which is quite an important one.The difference is that these two functions, strictly speaking, represent the deprecated feature of client-side vertex arrays. In modern OpenGL, server-side (cached to the GPU's video RAM, in OpenGL server-side memory) vertex arrays are the only way to go. Deprecating these two functions was not really a matter of the functions themselves being obsolete, so much as it was the technical detail behind them that they referred to CPU-side system memory.
That is what I am not emulating in this wrapper.
In example: You can do this in GL [ES] 1.x.
In my current wrapper, this will not work because my implementation of
glVertexPointer
does not go through global state machine flags to pre-buffer the vertex array's pointer address to be uploaded for the next time that any and every subsequent call to DrawArrays or DrawElements is done.It would need to be done this way at the moment if using my wrapper:
The long and short of it is that currently I have to call
glVertexPointer
repeatedly for every time I want to use the C language (or JavaScript or whatever) to update the vertex array that is about to be drawn to the screen.Reasons I have not (yet?) implemented the client-side vertex array behavior:
glVertexPointer
sends the address to system memory to a C array where your vertices are all currently looked at every time the array is drawn to primitives, but in JavaScript, I don't have any clue how to pass addresses (or references, I guess).glVertexPointer
with almost the exact same function but under a different name with only 2 differences (neither of which, the function name represents): a) being per-attribute, where each attribute is customizable/inventable within GLSL scripting, and b) setting the pointer to server-side video memory, not client-side vertex memory in C language arrays.Maybe in the future, if I do see a way to construct reference-able symbols out of JavaScript arrays, I can implement the remaining client-side and deprecated portion of
glVertexPointer
's behavior, but until then, I think the current server-side method of handling it:The text was updated successfully, but these errors were encountered: