Oh dang, nevermind, I didn't notice the *2* after WebGL :) Am Dienstag, 29. September 2015 20:48:37 UTC+2 schrieb Floh: > > In general, even though emscripten tries to make porting GL code easy by > emulating some features and calls of desktop GL, you can only rely on the > OpenGLES2 feature set, since this is what WebGL is based on (plus optional > WebGL extensions defined here: > https://www.khronos.org/registry/webgl/extensions/) > > For instance GL_TEXTURE_WRAP_R is for 3D textures, which are not supported > on WebGL, and for uncompressed texture formats, you can only use a very > small subset of what desktop GL allows (see here: > https://www.khronos.org/opengles/sdk/docs/man/xhtml/glTexImage2D.xml). > > Cheers, > -Floh. > > Am Montag, 28. September 2015 19:54:28 UTC+2 schrieb Robert Goulet: >> >> 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.
