Add GLEW 1.10.0 emulation #1878
Conversation
ghost
assigned 
|
@juj, want to take a look at this one perhaps? |
| glewIsSupported: function(name) { | ||
| var extensions = Pointer_stringify(name).split(" "); | ||
| for (var i = 0, len = extensions.length; i < len; i++) { | ||
| if (!(Module.ctx.getExtension(name) | 0)) return 0; |
There was a problem hiding this comment.
In desktop GL/GLES2 world, extensions are prefixed with "GL_". In WebGL extension registry, all extensions start without that suffix: http://www.khronos.org/registry/webgl/extensions/ . In the function glGetString it was decided to be desirable that both unsuffixed and suffixed forms were reported, see here https://github.com/kripken/emscripten/blob/master/src/library_gl.js#L652 . Perhaps GLEW codepath should follow the suit, and be able to manage both unsuffixed and suffixed forms for consistency? (glewIsSupported and glewGetExtension)
There was a problem hiding this comment.
I agree, will change this.
|
@juj, should I rebase and open new pull request to keep history cleaner? // edit |
|
Squashing is ok - Also leaving the commits intact is ok, if there is value in having the commits individually present, like for bisecting. E.g. temp stuff, replacing commits and wip like Cloudef@1e87bb2 + Cloudef@453bebe could be amended, but it's not a worry to me when there is only a few commits. @kripken might have a more preferred recommendation. |
|
if separate commits help bisection they should be separate, otherwise might On Mon, Dec 16, 2013 at 7:27 AM, juj [email protected] wrote:
|
|
Since none of this code is not yet in emscripten (apart from the glew.h header change), it might be easier and cleaner to combine the commits and send new pull request when everything is good. |
|
This would be great to have. On a related note: PixarAnimationStudios/OpenSubdiv#247 (comment) |
|
Combining the commits sounds good then. Note that you don't need a new pull request, can just force-push to this one. Just be sure to comment afterwards, github does not send email updates on pushes, just comments. |
|
Sounds good, I just came back from some travels. I'll try to wrap up this and GLFW3 this week. |
|
Took a while to get back to track. So, if these looks ok I'll rebase against latest code and force push. |
|
Looking at the latest, I see you chose to do a different form than I recommended in #1878 (comment) . The code in Cloudef@34a97de has the inconveniency that multiple "Unknown error" strings can get cached in that array, instead of reusing the same string, so it's possible to unboundlessly grow the size of the cached state. Probably not an issue, unless client code has some kind of bug though. Feel free to rebase, looks good to merge by me. |
Includes library_glew.js that stubs the init functions, but also provides the other functions. GL/glew.h is now changed to work with GLEW_EXT_foo_bar constants, some missing constants that are in GLEW 1.10.0 are also provided. Otherwise it still uses SDL_opengl.h to provide function definitions and other constants. Linaro's GLEW (glew-oes) is also supported to some degree to make it easier to get ES1 and ES2 software using it running. What it lacks: - Some constants and function declarations that are in GLEW 1.10.0 might be missing. - The real glew-es fork also includes normal GL constants and function pointers, this does not. Tests ran: - tests/runner.py browser Real world example using this code (and upcomming glfw3 port) can be found here: http://cloudef.eu/glhck http://cloudef.eu/glhck/qb.html
|
@juj good point there, I made it so that when string gets sets to unknown error, it forces error to 8 as well, this should keep the array from growing more than that. |
Includes library_glew.js that stubs the init functions, but also provides the
other functions.
GL/glew.h is now changed to work with GLEW_EXT_foo_bar constants,
some missing constants that are in GLEW 1.10.0 are also provided.
Otherwise it still uses SDL_opengl.h to provide function definitions and
other constants.
Linaro's GLEW (glew-oes) is also supported to some degree to make it
easier to get ES1 and ES2 software using it running.
What it lacks:
might be missing.
function pointers, this does not.
Tests ran:
Real world example using this code (and upcomming glfw3 port) can be found here:
http://cloudef.eu/glhck