Wow, you did a great job there Floh I guess !
I definitively agree with your approach/ideas, having the granularity at
the rigid asset bundle level or at the single file level would not be
good enough on huge game use cases.
About the "block-filesystem" I was thinking about something inspired
100% agree with Floh there.
It was difficult for me too to accept that "blocking" the main thread is
not possible. This is particularly true when porting existing C++
programs, most of them being designed around that idea. You have to
learn the "asynchronous" way of doing things, sometime call
Hi,
No, there is not yet a book on Emscripten as far as I know. That's
something I think doing at some point in time, but this take quite some
time to do, and Emscripten/Wasm is a fast moving target as you said :)
Le 16/05/2019 à 20:13, Marc Fawzi a écrit :
Hi guys,
Is there such a book ou
I do have /emscripten_request_animation_frame/ in emscripten/html5.h
I am using sdk-1.38.30-64bit
Le 27/05/2019 à 21:18, J Decker a écrit :
This GUI library I'm porting has a status of whether it wants to draw
continuously, or wants to just notify the system to do a single draw
after a change
It look like things have changed a bit recently.
Actually, you can know the unique identifier of the last precompiled SDK
available in the file "emscripten-releases-tags.txt" file (after issuing
"emsdk update-tags" commands)
On my side the contents is:
{
"latest": "1.38.33",
"releases":
Note that I am not sure if we have to use
sdk-releases-upstream--64bit
or
sdk-releases-fastcomp--64bit
I don't get exactly what is the difference between the two
Le 05/06/2019 à 23:09, Patrik Weiskircher a écrit :
Ah, that'll already solve my problem. Doesn't have to be pretty, just
want
;ll be
switching to it by default soon, and will have a larger announcement.
Basically we want to stabilize the migration to the new CI first.
- Alon
On Wed, Jun 5, 2019 at 2:11 PM Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.com>> wrote:
Note that I am not sure if we have to u
to look ?
Le 05/06/2019 à 23:34, Gabriel Cuvillier a écrit :
Ok, good to know about the upcoming LLVM backend !
I did a few tests of that new backend with the Doom 3 port. Except for
EMTEPRETER which is not supported (oops, too bad. I can no more yield
to the browser during the
Hi,
I had a similar issue, and it is probably a bug:
With the SDL2 port to Emscripten, most
SDL_GL_SetAttribute(SDL_GL_CONTEXT_FLAGS*) calls after
SDL_GL_CONTEXT_PROFILE_MASK and MAJOR/MINOR will make things fail...
So you need to remove SDL_GL_CONTEXT_FLAGS call, and probably the
SDL_GL_FR
@Floh: no, Asyncify is not used to simulate 'infinite game loop' (I am
using emscripten_set_main_loop for this), except for one or two very
specific cases (there is some 'modal' dialog boxes in D3 UI, and this is
implemented as a 'sub-infinite loop' in the 'main infinite loop', so I
use Asyncif
and (0) would probably do the same thing -
browsers limit timeout precision, so a few ms either way is going to
end up happening at the same time.
- Alon
On Mon, Jul 22, 2019 at 10:35 PM Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.com>> wrote:
@Floh: no, Asyncify is not used to
Hello,
How did you compiled the lib*.a files that are linked with your project
(for example: libSCMStatic.a or libcrypto.a) ? Maybe it is possible they
were compiled with a slightly different version of the standard library
(and version of emscripten). If you can, try to recompile everything
Regarding the Emscripten "Ports", why not having something like NaCL
"Web Ports" system ?
https://chromium.googlesource.com/webports
For example, the list of ports for Pepper 47 version:
https://chromium.googlesource.com/webports/+/pepper_47/docs/port_list.md
This is a 3rd party repository (
100% agree with Floh there. Changing such a thing is an open door to
a very obscure, hard to find, and unwanted potential "project breaker",
for a very minor added value...
Having to live with some minor technical debt due to badly named things
is acceptable I suppose.
Le 17/10/2019 à 1
reasonable.
Badly named variables are a perpetual mental hassle, and triggering a
clear error message means the change won't be obscure.
Cheers!
Beuc
On 17/10/2019 17:02, Gabriel Cuvillier wrote:
100% agree with Floh there. Changing such a thing is an open door
to a very obscure, ha
Thoughts that's OK, even if there's an inconvenience for existing users.
At least, we know in advance that something might break, so that's fine :)
Maybe instead of "throwing", just reporting an error in the web console
would be sufficient though. If "STRICT=1" is set (which should be
probabl
Great!
A question regarding this in the documentation, which confuses me a bit:
/You can disable wasm object files with -s WASM_OBJECT_FILES=0, which
will make the wasm backend behave more like fastcomp. //
//Neither fastcomp nor the wasm backend without wasm object files will
run the LLVM opt
ically set --llvm-lto 1? I'm not sure what
clang normally does, but we should do the same probably...
- Alon
On Tue, Oct 22, 2019 at 2:40 AM Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.com>> wrote:
Great!
A question regarding this in the documentation, wh
ectation of most users (and
build systems) would be that you only have to pass things at
compile time. It would be nice to push the upstream backend more
in that direction rather than going back.
On Fri, Oct 25, 2019 at 5:31 AM Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.
, though it look like -flto is doing
the same (USE_WASM_OBJECT_FILES may only be used at link time to trigger
LTO on system libs)
Le 25/10/2019 à 22:49, Gabriel Cuvillier a écrit :
Well, to me, having such hint in the settings.js file (= compile time
flag or link time flag) would certainly
Hello, I have some question related to TOTAL_MEMORY and PTHREAD_POOL_SIZE:
Is it possible to define (or override) these value at Wasm instantiation
time, instead of at compilation/link time.
The reason for TOTAL_MEMORY is the following: when compiling with
threading support (USE_PTHREADS=1) w
Another technical question for today:
There is a couple of Emscripten settings for which it is not clear if
they have an impact/use on Wasm backend:
- DOUBLE_MODE
- PRECISE_F32
I suppose both of them are only useful for Asm.js, but this is not 100%
clear to me. So I just wanted to know :)
g difference on 32-bit
systems). So that might make it harder to set dynamically.
On Tue, Dec 3, 2019 at 2:50 AM Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.com>> wrote:
Hello, I have some question related to TOTAL_MEMORY and
PTHREAD_POOL_SIZE:
Is it possible to defin
Hello,
On CMake-based projects where I want to keep separate the web app code
(= several vanilla JS files) from the various emscripten modules that
are used (= several emscripten-generated JS/wasm), I conveniently use
Closure as provided by Emscripten directly from my CMakefile to
bundle/opti
oogle-closure-compiler
executable will use it if available)
su 15. jouluk. 2019 klo 17.37 Gabriel Cuvillier
(gabriel.cuvill...@gmail.com) kirjoitti:
Hello,
On CMake-based projects where I want to keep separate the web app code (=
several vanilla JS files) from the various emscripten modules that a
My two cents on this, from the point of view of a daily Emscripten user
on various projects :
If this change does not impact end-users of Emscripten, that just want
to do C++ development targeting WebAssembly, then this is perfectly
fine. This change would just be an EMSDK "implementation de
ou propose to you Git LFS, instead? That sounds
reasonable.
On Wed, 18 Dec 2019 at 09:27, Gabriel Cuvillier
mailto:gabriel.cuvill...@gmail.com>> wrote:
My two cents on this, from the point of view of a daily Emscripten
user on various projects :
If this change does not imp
Le 19/12/2019 à 08:54, Jukka Jylänki a écrit :
It will require asking users to install git-lfs separately
This.
Indeed, that's a good argument against git-lfs: one user-visible
additional requirement.
--
You received this message because you are subscribed to the Google Groups
"emscrip
Hi,
Of course the current code can't work, as the typed_memory_view points
to some memory space that will be deleted at end of the fonction (as the
dst vector will be deleted since it is in the stack, regardless of the
std::move(ret) which does not move the vector but the emscripten::val).
Th
Hi,
Try to remove --llvm-lto 3, as it might increase binary size
significantly when combined with -O2 or -O3 (and I am not sure it is
very usefull without using -DWASM_OBJECT_FILES=0)
Le 28/02/2020 à 08:12, Rohit Saini a écrit :
Hi All,
Previously we were using 1.38.28 emscripten version. R
Glad to!
By the way, I don't find that LTO brings any performance improvements
compared to a non-LTO builds (on latests Emscripten backend). Maybe +1%
at most (more probably benchmark noise to me), but sometime more than
10% worse, and at the expense of a *significant *link time increase and
Yes, I guess you are right. It is is probably very code-dependent, and
for raw C code LTO have a lot more sense than for complex C++ code with
crazy template magic.
Le 28/02/2020 à 12:16, Floh a écrit :
When I last tested I generally saw quite noticeable improvements for
inlined code (which L
Well, to me LTO _used to_ be better. But for some reason, since the
switch to upstream LLVM backend, it is no more very interesting.
I have been surprised by this, and decided to disable LTO on all my
projects since the switch. But maybe there's a bug lurking somewhere:
LTO is simply not corr
33 matches
Mail list logo
