Alon merged this feature into incoming, and there is now official
documentation in the wiki:
https://github.com/kripken/emscripten/wiki/Running-html-files-with-emrun
Let me know if you run into any issues!
Jukka
2013/12/4 Jukka Jylänki
> Ok, I submitted it as a pull request at
>
Hello,
here's season's greetings brought to you via a WebGL+WebAudio Emscripten
game: http://clb.demon.fi/xmas/
Merry Christmas to everyone in the Emscripten community!
Jukka
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubsc
launching your little game on iPhone, but the button Play doesn't work
> on iOS :(
>
> But all the part with the text on the snow work good.
>
> Tony
>
> Le 22 déc. 2013 à 19:01, Jukka Jylänki a écrit :
>
> Hello,
>
> here's season's greetings br
This issue is caused by exceeding temporary GL emulation buffer sizes. The
example is requesting 262144 * 16bytes == 4194304b (4MB) of vertex data,
but there is a fixed-size allocated buffer for emulation purposes that is
by default only 2097152 bytes (2MB). To work around this, try compiling
with
Oh, ignore those bindAttribLocation errors for now, that's a noisy error
message I created that doesn't mean anything, I though I submitted a PR
that fixed that already though :/ (the issue is that this loop accidentally
goes over-the-limit
https://github.com/kripken/emscripten/blob/incoming/src/li
Ah now I notice that my fix for that bindAttribLocation was already done,
but it's pending in an unmerged pull request here:
https://github.com/juj/emscripten/commit/0cd4d2034bbb0cf834ae1e84f81bef4e8f100f41
As for GL emulation, it's tricky to say where the issue is, since the GL
emulation is a par
This sounds like the file is not an archive file. Perhaps it's an LLVM
bitcode (.bc) file instead with just an .a suffix?
2014/1/9 Floh
> I'm currently trying to setup a Linux dev-env for emscripten (Ubuntu
> Precise 64-bit, running in Virtual Box on OSX), and I'm getting an error
> which I hav
I suppose you added the sys.exit() call to early-out quit and avoid
temporary directory from being removed? I think the temp directory cleanup
is performed as an atexit handler, so it might be that sys.exit() still
calls those and therefore the files could have been there, but got still
erased. (ju
out to see if it helps in debugging.
Jukka
2014/1/7 Jukka Jylänki
> Ah now I notice that my fix for that bindAttribLocation was already done,
> but it's pending in an unmerged pull request here:
> https://github.com/juj/emscripten/commit/0cd4d2034bbb0cf834ae1e84f81bef4e8f100f41
Oh wait, this reminds me of an issue with virtualbox folder sharing a long
time ago in a different project, where opening a file to truncate did not
work, but it always insisted on appending, and seeking in the file was
flaky as well. Trying completely outside virtualbox could be helpful in
seeing
Hi,
a new version of the SDK is now available. This includes the following:
- latest snapshot of the emscripten compiler, 1.8.2. See changes here:
https://github.com/kripken/emscripten/blob/ad83790c2ddbe5f59242ecf0965d658c9ca6eb73/ChangeLog
- fixes issues with emsdk installer and running on
This is a very recent regression. Several people have reported it already,
so I just went ahead and pushed a workaround to incoming. See
https://github.com/kripken/emscripten/commit/19a38d059bd6da1402edd3dc13c8485025059fa7.
That workaround is ok atm since glewExperimental is ignored in
emscripten
a
I think embind JS file comes in with the --pre-js directive, so the linking
phase unfortunately does not see these symbols being added in. I can't
remember outright if there is some problem with using --js-library for
embind, although it would require a bit of rewrite of the embind .js file
structu
The -s GL_FFP_ONLY=1 optimization is intended to work in the case where
there are no shader programs being used at all in the code. If you're using
glUseProgram in your own code, then that's not compatible with the -s
GL_FFP_ONLY=1 flag.
Sorry about the INVALID_VALUE: bindAttribLocation: index ou
Oh now I see what you are saying. Let me take a look..
Jukka
2014/1/22 wolfviking0
> Hi @jj
>
> For the -s GL_FFP_ONLY=1 trouble you can reproduce it inside the s3tc.c
> tests, it's doesn't use shader (like in my sample) but if I use the
> settings i have a black screen on the s3tc.c sampl
Thanks! I pushed fixes to incoming now, see
https://github.com/kripken/emscripten/compare/cc77e142465c...0b1df261d344ad53d82b8e86a17d619bc43eb3cb
2014/1/22 Jukka Jylänki
> Oh now I see what you are saying. Let me take a look..
>
>Jukka
>
>
> 2014/1/22 wolfviking0
>
&g
You need to have a web server to run the file in Chrome - running from a
local directory does not work. Try emrun (
https://github.com/kripken/emscripten/wiki/Running-html-files-with-emrun )
or "python -m SimpleHTTPServer" to host an ad hoc web server to run the
file in.
As for the fillrate requir
Hey, I manage to consistently crash Firefox Nightly on this - could you
freeze this exact version of the page to some location that stays alive?
I'm going to submit a crash report about this.
Jukka
2014/1/25 Bram Stolk
> Hi,
>
>
> Here's the first version of the emscripted port of my Crane
is
> incomplete.
> I use a depth-only texture, which Version 32.0.1700.77 chrome does not
> like.
>
> I tried adding glDrawbuffer( GL_NONE ) but this symbol is undefined during
> linking?
> Does emscripten link against GL or GLES2 when I build sdl sources?
>
> Bram
>
>
an put up a version
>>>> without the lzma compression?
>>>>
>>>> - Alon
>>>>
>>>>
>>>>
>>>> On Sat, Jan 25, 2014 at 1:16 AM, Bram Stolk wrote:
>>>>
>>>>> Sure,
>>>>>
>&
Hi,
last week, something very interesting landed to emscripten incoming: a new
set of C callback APIs for receiving various HTML5 events. See here
https://github.com/kripken/emscripten/blob/incoming/system/include/emscripten/html5.h
The task that it accomplishes is somewhat simple - the code prov
Hmm is that the full C++ side code? What did glCompileShader and
glLinkProgram say? Try reflecting the GL server state for the shader and
shader program objects to confirm that they match native, and the shader
and shader program info logs are ok and that there are no errors. For
reference, here's
Thanks! This is exactly what I was hoping to hear. While using GLUT, SDL,
etc. are useful for porting existing codebases, when developing your own
first party codebase, it's very useful to go directly to the HTML5 apis.
Looking forward to hearing if there's any issues,
Jukka
2014-01-28 Floh
As a random data point, compiling my math library MathGeoLib (
http://clb.demon.fi/MathGeoLib/nightly/ ), which is a rather small static
library, the link time went from about 30 seconds to a bit less than 20
seconds. Note though that this is with compiling fastcomp with somewhat old
VS2010 and usi
Very well spotted Mark! I had forgotten that this was allowed - indeed
looks like a possible bug. Let me see if I can produce a test case.
Jukka
2014-01-31 Mark Callow :
> On 2014/01/27 9:49, wolfviking0 wrote:
>
> Hi Jukka I found my trouble,
>
> the code was :
>
> m_program = glCrea
I've run into this very often on the bots, when switching between versions
and trying something in ssh shell while the bots are running. I think that
in the current codebase, it should be safe to build multiple if you first
make sure that .emscripten_cache is fully built and up-to-date? After that,
I think the traditional non-GPU HTML/JS solution for games has been to
create a "CSS DOM Renderer", which is a JS API that creates s with
absolute positioning on text draw calls, which utilizes the DOM to draw
text. This API is of course declarative in nature, instead of
immediate/imperative, which
vs-tool currently works with Visual Studio 2010 and Clang 3.2. It's not
possible to build Clang with VS2012 or newer due to some VS compiler
issues, which LLVM devs have pointed to have been fixed in Clang 3.4 stable
release (which though we don't yet use in Emscripten). Building Clang 3.2
with VS2
There exists these two HTML5 apis:
Clipboard API and Events: http://dev.w3.org/2006/webapi/clipops/clipops.html
and HTML5 Drag and Drop:
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html
The first one looks relevant? I haven't tried it though, but
caniuse.comsuggests it's widel
One option for blocking keyboard input you could try is to register a
keyboard event callback e.g. via the emscripten library_html5.h handlers,
and having ms_getchar() pause the main loop like you now do, and when you
do get a key press, call resume on the main loop. Alternatively, if you
don't wan
Functions wrapped with cwrap and ccall should execute independent of
whether there is a main loop running or not. Also, it is possible to
directly write to and read from memory by using the {{{ heapSetValue }}}
and {{{ heapGetValue }}} mechanisms if you are implementing a --js-library
file, and fro
The page on EGL should be up to date. I use EGL for my engine, which has
the benefit that the same code can be shared with Android. GLFW on the
other hand can initialize on desktops as well. For Emscripten purposes,
both should work just fine. Perhaps see the tests/ directory on the example
code to
I think the -L directive is specified to only add search paths for when
using -lfoo to link in libfoo.a. It would not apply to input files listed
directly. I would try using the explicit Visual Studio $(ProjectDir) and
$(SolutionDir) macros to specify relative paths, like linking in
"$(SolutionDir)
The .cpp files are never included by other files (well you could, but by
good organization practices they don't). They are the 'starting points' of
compilation units, which go on to include headers. Each .cpp file is
compiled separately as their own compilation unit, and the results are
linked toge
The wiki page referred to this issue
https://github.com/kripken/emscripten/issues/645 , which has been closed,
so it is supported. I removed the link from the wiki.
2014-02-12 7:04 GMT+02:00 Joel Croteau :
> I switched my code to EGL and it seems to work fairly well. One thing I
> did not realiz
glGetString(GL_EXTENSIONS) is supported in Emscripten GL library. Even
though WebGL itself doesn't have that function (by
http://www.khronos.org/registry/webgl/specs/latest/1.0/#6.15 ), the
Emscripten GL library layer implements it and routes it to
getSupportedExtensions(), to present the GLES2-con
This error occurs when emsripten is trying to prebuild and cache its C
standard library to be used with your project. It should only do it once,
and then keep reusing it. To exclude Visual Studio issues, can you try e.g.
running 'python tests/runner.py asm1' in the Emscripten root directory to
chec
You can use the syntax --preload-file srcpath@dstpath to choose which
directory to place the source content into. See e.g. comments in this
issue: https://github.com/kripken/emscripten/issues/486 . Also, you can
open up the created file_data.js file to examine the path names of the
files that were
That is an asm.js validation error, which means that the code is running
without asm.js ahead of time compilation. This causes potentially a large
performance hit, but should otherwise work. Does it tell the file:line
where that occurs? To debug, you need to figure out if it's
compiler-generated JS
This suggests that the buffer storage for the draw operation did not
contain enough bytes - can you double-check the size of the GL array buffer
that it's enough to store the 2048 vertices, and that you don't have
enableVertexAttribArray called for any other attribute indices that are not
in use by
Currently I'm not aware of such a feature. You could do a custom JS library
that checks the values of the particular settings from src/settings.js and
logs them, as those are not embedded to the generated executable for
runtime examination.
2014-02-13 20:03 GMT+02:00 Joel Croteau :
> Is there a
Ouch, dealing with regressions is always a bit sad :/
I would try the following:
- Check if the audio.onerror event gives an error message, I see we don't
really print that error out in the handler atm. Does the error message give
a reason?
- narrow down which Firefox version regressed. FF24 w
Hey,
Anthony Liot has been working on a pull request to add proper VAO support
in Emscripten in this pull request:
https://github.com/kripken/emscripten/pull/1817
Before that PR (and before Firefox even supported VAOs), we had an
emulation path implemented, which was not really that great or perf
51084, 51908, 0, 0).open('GET', '/DrawBatchPS.cso');
that shows the VFS structure. If you use the file_packager.py directly,
then there is a separate file_data.js that will get generated.
2014-02-18 9:07 GMT+02:00 Mark Callow :
> On 2014/02/13 19:09, Jukka Jylänki wrote
014/02/18 16:12, Jukka Jylänki wrote:
>
> Oh right - if you're using --preload-file as part of emcc/em++, then a
> separate file_data.js will not get generated, but the contents of that file
> will be embedded at the start of the normal .js file output. Try seaching
> the start
014/02/18 18:31, Jukka Jylänki wrote:
>
> No, the .data file will not contain the TOC, but the .js file.
>
> Oh! Silly me.
>
> Did you use --preload-file with emcc or with file_packager.py? If you
> used emcc --preload-file ... -o output.js, then check the start of the file
>
In Emscripten you can just skip the command lines for GL, GLEW, and GLUT -
those are supported in the core, and they will be automatically linked in
when you use them. I'm not sure about the status of GLU - it could be that
it's not supported. If you just drop the -l directives, do you get further?
Give a look here:
https://github.com/kripken/emscripten/tree/master/system/include/GL
Emscripten comes with GL/freeglut_std.h and GL/glut.h. I'm not that well
versed with the minute differences of these, but perhaps one of these
headers will do the same job for you?
2014-02-22 19:34 GMT+02:00 Sa
GLM is a template-based header-only library that should build out of the
box, there's no linking required. If it has some flags that enable SIMD,
then those should be disabled. I recently read a success story building GLM
at least, so I think that should be good to go.
2014-02-22 20:19 GMT+02:00
The code was merged last week - and in the end we actually noticed that we
had to retain the VAO emulation path as well, so no features were dropped.
It should be possible to use VAOs both with and without GL emulation,
although the emulation path is not functionally perfect.
Jukka
2014-02-24
This is a good feature request, thanks!
I've implemented new fields to EmscriptenFullscreenChangeEvent structure
that report the pixel sizes of the target element and the pixel size of the
whole screen in the event handler. See this pull request:
https://github.com/kripken/emscripten/pull/2165 .
The new fields report screen.width+screen.height and
element.innerWidth+element.innerHeight, which I suppose are in CSS pixels.
2014-02-27 5:53 GMT+02:00 Mark Callow :
> On 2014/02/26 19:22, Jukka Jylänki wrote:
>
> This is a good feature request, thanks!
>
> I've imple
Can you post the compiler output? And/or make a small complete test case we
could try out? In any case, I see that the shaders are from desktop GL
3.0+, which is the new syntax that GLES2 and WebGL do not support. When you
get it compiling, you'll need to remove the #version and convert the in/out
Hi,
it's a great time for a new emsdk update. The new version is 1.12.0 and it
is available at
https://github.com/kripken/emscripten/wiki/Emscripten-SDK
There are a lot of changes, but the single most important one is this: The
version 1.12.0 will be the last SDK version that still supports old
Hi everyone,
for some time now, the Emscripten incoming branch has switched its focus on
the new Clang-based compiler backend. To make it easily accessible for
everyone to preview, there is a new Emscripten SDK version 1.13.0 now out,
which ships with the new Clang JS backend code. The quick need-
build, i.e. it completely disables incremental builds. We'll either have a
better fix for this in for the next stable emsdk release, or keep on
shipping the 32-bit tools as well (which we hopefully don't need to do
anymore).
Jukka
2014-03-05 4:04 GMT+02:00 Mark Callow :
> On 2014
Yeah, you can ignore those messages. If you want to be sure that this is
not causing any issues, try downloading and running in Firefox Beta, Aurora
or Nightly, as I think all of those have the Mozilla Audio Data API removed
altogether, in which case the SDL backend will rely on Web Audio API for
a
I'd try handwriting a function that takes in a pointer to a structure, and
prints its contents out to console. Then you can invoke that function in
the web console just by calling its name with the pointer. That's not quite
as convenient as the object property view in the debugger, but might do the
No, Emscripten doesn't have any special setup required for using template
code from headers.
If you want to expose any piece of code to JavaScript, you'll need to
implement a C++<->JS interface for it so that you can call the functions
from handwritten JS, either via embind or manual ccall/cwrap i
Did you both compile and link with the --bind flag?
2014-03-07 12:36 GMT+02:00 Michael IV :
> I am testing embind with the following chunk of code:
>
> #include
> #include
> #include
> #include
> void glm_add(float x1 ,float y1,float x2,float y2){
> printf("Vector summation equals: %f , %f",x1
EmscriptenDemo.vcxproj -> C:\Users\Michael\documents\visual studio
> 2010\Projects\EmscriptenDemo\Emscripten\Debug\EmscriptenDemo.js
> == Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==
>
>
> So it seems I can discard those warnings?
>
>
>
> On
In terms of features, pretty much WebGL is a subset of GLES2, which is a
subset of modern desktop GL. Sticking to the lowest common denomination and
basically writing "GLES2 without client-side rendering" gives you a good
sane common ground that works across all platforms. This means not using
any
; Ok,so let me see if I get you right.I can basically use GLEW with GL 3.0 -
> GL 3.2 core profile and it will be translated ok (except of GLSL compat
> issues) to WebGL?Also,in terms of context creation,I see I can use GLFW or
> GLUT ?
>
>
> On Sat, Mar 8, 2014 at 4:56 PM, Jukka
uot;
> notification.
>
>
> On Sat, Mar 8, 2014 at 6:05 PM, Michael IV wrote:
>
>> "Client side lack..." - good ! I just tried to use GLFW3 for context
>> setup ,the emscripten compiled but nothing show up.Is it correct to assume
>> it is not yet sup
There are no GL-specific steps needed for file I/O. You can create a
virtual filesystem with the --preload-file emcc directive or running
file_packager.py separately, and then use standard C file IO to access the
VFS for loading textures and models. E.g. I use custom
dds/png/bmp/crunch/obj file loa
Yeah, this has the same issue as described in the previous mail - the
blocking modal while(running) loop is not supported, but you should use
emscripten_set_main_loop() instead.
2014-03-08 18:59 GMT+02:00 Michael IV :
> I wrote a test which just clears framebuffer color:
>
>
>
> #include
> #inc
27; (aka 'int'))
> typedef khronos_ssize_t GLsizeiptr;
> ^
> C:\Program Files
> (x86)\Emscripten\emscripten\1.12.0\system\include\GL/glext.h:50
> 73:19: note:
> previous definition is here
> typedef ptrdiff_t GLsizeiptr;
>
I believe the issue was this, and resolved.
https://github.com/kripken/emscripten/issues/2203
2014-03-10 10:38 GMT+02:00 Mark Callow :
> On 2014/03/07 7:03, Michael IV wrote:
>
> Hi All.Sorry for the noob question.I have installed Emscipten 64bit
> version on Windows 64bit.I am trying to compil
header. It's probably gets included
>> with GLFW or something like that.
>> On Mar 8, 2014 8:01 PM, "Jukka Jylänki" wrote:
>>
>>> You are mixing GLES2 ( \system\include\GLES2/gl2.h ) and desktop GL (
>>> \system\include\GL/glext.h ) headers, that'
There's the Clang+GCC -supported compiler flag -fshort-wchar you can use.
That doesn't affect how Emscripten operates in any way though, it's purely
implemented on the Clang side. Does that flag help?
2014-03-12 0:45 GMT+02:00 Mark Hahn :
> I'm compiling an app that expects wchar_t to be 16-bits
Quick observations:
1) You cannot have templates as C -> JS barrier, only non-templated
functions are possible.
2) Remember to wrap the function declarations in extern "C" { void foo(); }
to avoid C++ name mangling from occurring.
Jukka
2014-03-13 0:58 GMT+02:00 wolfviking0 :
> Hi,
>
> I am
Yeah that's true - PCF samplers are not available on WebGL, there is no
extension for those like GLES2 has the GL_EXT_shadow_samplers extension (
http://www.khronos.org/registry/gles/extensions/EXT/EXT_shadow_samplers.txt).
Note though that you can still do a traditional sampler, which works for
sh
That kind of error occurs when a function pointer is called and the pointer
does not point to a valid function of correct signature. If I understand
this correctly, it looks like the function AllocOCLBuffer ends up doing a
function pointer call to delete a std::string or a std::stringstream, but
th
Running "clang hello_world.cpp" runs the the traditional clang compiler
that targets a native execution. Like Alon mentions, you want to run
emcc/em++ hello_world.cpp instead to build a javascript file.
2014-03-17 16:30 GMT-07:00 Alon Zakai :
> emcc should generate a.out.js by default, as the ou
If you are running in Firefox with asm.js enabled (by using the fastcomp
backend, or in the old backend specifying -O1 or greater), the "too many
local variables" limit should not apply. If you still get that error in
Firefox with asm.js-enabled code, it's possible that the output did not
validate
em
as well.
2014-03-28 14:08 GMT-04:00 Alon Zakai :
> Still, shouldn't different browsers behave the same here?
>
> - Alon
>
>
> On Fri, Mar 28, 2014 at 6:51 AM, Jukka Jylänki wrote:
>
>> It's a common optimization for GL and GLES drivers to eliminate unus
It's a common optimization for GL and GLES drivers to eliminate unused
uniforms from the linked shader programs. This is correct and valid
behavior by the spec, and should be accounted for by the renderer code. If
you are writing shaders that don't need some uniforms that it defines, but
e.g. the C
If you compile with the Clang option -fshort-wchar, then wchar_t will get
treated as 16-bit instead of the default unix-world 32-bit. Whichever you
are building with, check out the functions UTF16ToString()+stringToUTF16()
and UTF32ToString()+stringToUTF32(). Here's a test that demonstrates their
u
1.13.0 migrates to using the fastcomp backend, which 1.12.0 did not yet
have, and fastcomp backend only produces asm.js code, which embind doesn't
yet support. Unfortunately you'll need to use 1.12.0 for this atm.
2014-04-07 4:15 GMT+03:00 Alon Zakai :
> What does emcc -v say?
>
> - Alon
>
>
SDL_Quit() function is effectively ignored by Emscripten and does not do
anything. If you want to fully quit the application, you can do exit(0)
like you're now doing, or if you want to just temporarily pause running the
main loop, you can call the emscripten_cancel_main_loop function. That has
the
This suggests that linking to boost and Ogre did not succeed properly. Try
double-checking that the libraries you are linking to do indeed contain the
symbols that it claims unresolved.
Another route could be to try to just pass the libraries as standard
inputs, i.e. em++ -o a.html a.o b.c libOgre
Ok, that looks like everything should be in order and it should be filled
in. I'm not quite sure what's going on here, but for peace of mind, can you
try moving lib boost_system.a to be the last item in the command line? E.g.
for GCC, if library A depends on library B, then on the cmdline you need
This configuration is not good - the emscripten-incoming branch has
diverged away enough so that the tagged snapshot clang-e1.13.0-64bit can no
longer be used to build with it. You should either use emscripten-1.13.0
with clang-e1.13.0-64bit or build clang incoming repo manually.
2014-04-08 5:53
Oh hmm, I did not know there actually was some logic implemented behind
SDL_Quit - I always though it was ignored, but apparently is not.
2014-04-08 8:48 GMT+03:00 :
> Also, I'm curious if anyone has found a way to make C++ infinite main
> loops asynchronous that work across all even driven pla
I wonder if 1.4.9 has asm.js compilation option - now with 1.12.0 optimized
builds are done with asm.js enabled. Perhaps Safari has problems executing
such code on iPhone. Does -O2 -s ASM_JS=0 produce anything sensible?
2014-04-08 9:44 GMT+03:00 Christoph Husse :
> And ofc I also ran the 1.4.9 b
Can you generate a small test case for this? That sounds like a bug.
2014-04-09 10:03 GMT+03:00 Станислав Панферов :
> Hi, please help me with one strange and annoying error. I have code like
> this in my project:
>
> std::stringstream ss;
>
> ss << "Try to create a big string, too big to blow
It does not look like you are using the latest Emscripten version. Alon
Zakai fixed that in upstream incoming in the other email thread you started
(this commit
https://github.com/kripken/emscripten/commit/a4a85b72ed016b2d652a8a4abe15f58fb15a5b7d),
but looking at your source code, it doesn't look l
Yeah, that is the preferred way to embed JavaScript code to the project
that will be called by C/C++ code. The --js-library directive should come
in the link step, which is the step that also has the "-o out.js/.html"
command line directive.
2014-04-15 15:35 GMT+03:00 Roman Kravchenko <
roman.vol
The section
$(TARGET).js: $(OBJECTS) $(STATICLIBS) $(COCOS_LIBS) $(CORE_MAKEFILE_LIST)
@mkdir -p $(@D)
$(CXX) $(CXXFLAGS) $(OBJECTS) -o $@ $(SHAREDLIBS) $(STATICLIBS)
says "here is how you build the file $(TARGET).js. It depends on the files
$(OBJECTS) $(STATICLIBS) $(COCOS_LIBS) $(CORE_MAKEFILE_
You are using old legacy desktop GL <= 2.1 form of OpenGL and not the
modern GL 3.0 core version of OpenGL. To emulate the old deprecated
functionality, pass in the link flags "-s LEGACY_GL_EMULATION=1", that
should get rid of some of the missing functions, although that emulation is
not perfect so
You are hitting a OSX-specific clang issue that one needs to specify which
OSX SDK is being targeted. This is done via a -isysroot /path/to/xcode/sdk
directive to clang. It is possible to hardcode a default path to clang
during build, which is what system clang has done. See this commit for
emscrip
If your intention is to consume .bc files for Emscripten/JavaScript output,
then you should not call clang or clang++ to produce .bc files. Instead,
call emcc or em++ to compile to .bc. That is, the command line
/dist/emscripten-fastcomp/build/bin/clang++ -emit-llvm -c test.cpp -o
test.bc -isysroo
I played around this a bit with zlib-1.2.8 library, and noticed the
following:
- invoking node.js with cygwin paths (/cygdrive/c/xxx) will fail, unless
one builds node under cygwin, or writes a shell script wrapper which
converts cygdrive paths in command line arguments to normal Windows paths.
T
You can see what the test runner is doing by setting the environment
variables EMCC_DEBUG=1 and EM_BUILD_VERBOSE=3, and then running python
tests/runner.py test_freetype. That should print out all command line
invocations that occur during the test.
Yes, the generated JS files are always platform-
The GLUT support in Emscripten is not complete, and mostly the
functionality that is commonly needed has been implemented. Browser through
this file to find which functions currently exist:
https://github.com/kripken/emscripten/blob/master/src/library_glut.js . The
function glutSolidCube does not s
Hi everyone,
it's been a while since Emscripten development has migrated over to the
Clang-based "fastcomp" backend, and now it's time for the first Emscripten
SDK release that comes with the fastcomp backend default-on. Find the
download links from the usual place at
https://github.com/kripken/em
I am not sure if we currently have anything for the .data file generation,
but for --preload-file you can use e.g.
--preload-file ../path/to/file.txt@/
--preload-file ../path/to/file.txt@/dstpath/
--preload-file ../path/to/file.txt@/dstpath/filename.txt
the first one will create a file /file.txt
It looks like the OSX builds of emsdk are targeting a too new Mac OSX
version? At least by looking in here:
http://stackoverflow.com/questions/10177038/illegal-instruction-4-shows-up-in-os-x-lion
There is no specific reason not to support older OSX, so I'll see about
adding that to next emsdk buil
Perhaps your code is calling glGetString() before having initialized a GL
context? Try adding debug code before
file:///Tint/webkit.js/Debug/webkit.js:10729
to check that the GLctx object is valid, which it should be iff a proper GL
context has been initialized.
2014-04-30 7:53 GMT+03:00 Trevor L
Oh.. yeah, web workers do not allow WebGL usage :/ This might change in the
future, I know there have been talks of enabling more web apis in workers,
but that's something long-term. There was some brainstorming about queueing
all GL commands from worker thread to main thread to hack around the
lim
1 - 100 of 662 matches
Mail list logo
