Here's a few issues I've noticed so far with WebGL2 in Firefox Nightly,
latest Emscripten :
- Creating a texture format GL_RED, GL_RED_INTEGER, GL_RG or GL_RG_INTEGER
doesn't error out, but using them for rendering using framebuffers fails
(invalid framebuffer operations).
- Using GL_TEXTURE_WRAP_R parameter name in glTexParameteri returns invalid
enum.
On Saturday, September 19, 2015 at 8:30:50 AM UTC-4, Floh wrote:
>
> 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.
