Re: problems making a ccall to a varargs routine (v1.37.20)

Thanks for creating an issue. I may try to pick at a solution in my so-called free time, in which case we can continue this on GH/5563. Perhaps a varargs-styled syntax extension like this would be natural: Module.ccall("cvals", "null", ["number", "..."], [100.0, 1.01, 2.02, 3.03, -1.0])

Re: Dynamic Download and Load of Wasm

Thanks, that allowed me to build. I noticed that by adding -s MAIN_MODULE=1 my wasm file size increased from 6.5 MB to 14.6 MB. Is this kind of increase expected or am I doing something incorrect? For reference my build settings look like the following: emcc -s DISABLE_EXCEPTION_CATCHING=0

Re: Dynamic Download and Load of Wasm

Yes, linkable modules are larger by default because we disable dead code elimination (since something might be used from something it is linked to). See MAIN_MODULE mode 2, that can help (see docs in settings.js). On Thu, Sep 7, 2017 at 10:33 AM, wrote: > Thanks, that

Re: Dynamic Download and Load of Wasm

Hmm, even with -s MAIN_MODULE=2 internal symbols are still being exposed. I see a large number of internal symbols in the .js file exposed in the following manner: var _internal_function_name = Module["_internal_function_name"] = asm["_internal_function_name"]; Most likely as a result the

Re: Dynamic Download and Load of Wasm

Yeah, sorry, I must have missed that comment in the documentation. Is dead code elimination also disabled for side modules and if so is SIDE_MODULE=2 expected to work? Thanks, David On Thursday, September 7, 2017 at 11:06:27 AM UTC-7, Alon Zakai wrote: > > Yes, linkable modules are larger by

SDL port - how to use SDL_SetWindowFullscreen properly?

So I have a button in my game that is supposed to make the game go full screen. My engine uses requestAnimationFrame via emscripten_set_main_loop, and inside it calls SDL_PollEvent() to get events for mouse presses and everything else. So when I detect a mouse press on my button, I call

Re: Dynamic Download and Load of Wasm

Hmm, I encountered an error: "memory growth is not supported with shared modules yet". Unfortunately I don't really have the option to disable memory growth. (since the modules memory usage is dependent on user input) Is there any workaround for this error? If not is adding memory growth for

Re: problems making a ccall to a varargs routine (v1.37.20)

Marked down https://github.com/kripken/emscripten/issues/5563 to remember this for later. If you want to try to implement it yourself, or a workaround, check out this snippet: https://github.com/juj/emscripten/blob/multithreading/src/library_html5.js#L209, which calls a vararg function from JS

Re: Dynamic Download and Load of Wasm

Hmm, in WebAssembly, I believe that message should not be relevant anymore, and memory growth should be supported with dynamic linking. Or perhaps there was some reason that I can't remember now. You can try finding where that message comes out, and comment it out, it might apply only to asm.js