You can basically rewrite your example like this and it should work on
desktop GL (not sure if it works in Core Profiles though):
GLfloat verts_Init[] = {
-1.0f, 0.0f, 0.0f,
0.0f, 1.0f, 0.0f,
0.0f, 0.0f, 0.0f };
glBindBuffer(GL_ARRAY_BUFFER, 0);
glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, verts_Init); //
(x, y, z) for pos
glEnableVertexAttribArray(0);
This behaviour is a nice example why OpenGL has become so confusing,
because the same functions changed their behaviour over time. Note that the
function is called glVertexAttrib*Pointer*, and the last attribute is of
type 'const GLvoid*', even though current OpenGL docs say this is actually
an offset, not a pointer
(https://www.opengl.org/sdk/docs/man/html/glVertexAttribPointer.xhtml).
If you look at the documentation of older GL version, it talks about the
last parameter being a pointer, not an
offset: http://docs.gl/gl2/glVertexAttribPointer
The function basically has been retconned into having 2 different
behaviours, the pointer arg is either an offset or a direct pointer,
depending whether a buffer is bound or not.
Cheers,
-Floh.
Am Samstag, 19. September 2015 03:26:00 UTC+2 schrieb [email protected]:
>
> @Floh: Consider this example code:
>
> GLfloat verts_Init[] = {
> -1.0f, 0.0f, 0.0f,
> 0.0f, 1.0f, 0.0f,
> 0.0f, 0.0f, 0.0f };
> std::copy(verts_Init, verts_Init + 9, m_verts);
> glBindBuffer(GL_ARRAY_BUFFER, m_idVBO[0]);
> glBufferData(GL_ARRAY_BUFFER, 9*sizeof(GLfloat), m_verts, GL_STATIC_DRAW);
> glVertexAttribPointer((GLuint)0, 3, GL_FLOAT, GL_FALSE, 0, 0); // (x, y,
> z) for pos
> glEnableVertexAttribArray(0);
>
> I'm calling glVertexAttribPointer() "with an offset into a buffer" right?
> What's an example of calling glVertexAttribPointer() "with an actual
> pointer to the data"?
>
> "don't provide any input geometry to the vertex shader" - interesting. I
> see ( http://bit.ly/1F7vk83 ) shows an example where the vertex position
> is specified inside the vertex shader GLSL code instead of being passed in
> from C++ code.
>
> @jj: I'm glad to hear this is being worked on. I wonder if this has any
> relation to the fact that ANGLE does not yet fully support GLES3 since
> ANGLE is used by Chrome?
>
> Anyone know the ETA on when there will be a reasonably robust/stable GLES3
> support in Emscripten and a reasonably robust/stable WebGL 2 browser for
> the Emscripten-generated javascript to run?
>
> ---
>
> On Thursday, September 17, 2015 at 10:52:17 PM UTC-5, [email protected]
> wrote:
>>
>> What is the ETA on OpenGL ES 3.0 support for Emscripten?
>>
>> ( http://bit.ly/1Qjunsp ) says Emscripten supports OpenGL ES 2.0.
>> However, I see no mention of OpenGL ES 3.0?
>>
>> As for OpenGL ES 2.0 support, apparently this means the WebGL-friendly
>> subset of OpenGL + the ability to use glDrawArrays() without a bound
>> buffer. Does "without a bound buffer" mean without calling glBindBuffer()?
>>
>> Why would you want to call glDrawArrays() without first calling
>> glBindBuffer()? Wouldn't that mean to draw nothing?
>>
>>
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
