In addition, the full source code of Nontetris ( http://allievi.sssup.it/jacopone/cnontetris/ ) will be published in a couple of days, with a 'guide' on porting a C++ game to Javascript with duetto.
Stefano of Leaningtech
In addition, the full source code of Nontetris ( http://allievi.sssup.it/jacopone/cnontetris/ ) will be published in a couple of days, with a 'guide' on porting a C++ game to Javascript with duetto.
Stefano of Leaningtech
The perf comparison is missing a "asm.js + V8" bar, asm.js code is usually faster then non-asm.js code, even if the JS engine isn't implementing AoT compilation as FF does.
Edit: fixed "...uncommon -> common..." above
"Since I do not expect native platforms (i.e. GLibc) to preallocate gigs of memory at application startup to make it faster when dynamic memory is actually used, I do not expect this from a compiler for the JavaScript target either."
So, it would actually make very good sense to have the thing slab allocate a big honking array upfront, and then manage it with brk/sbrk/malloc, and perhaps just add more memory as needed.
Like, if we're going to be writing C/C++ in the browser, why not do this? Why make us deal with the GC at all?
But I don't want to nitpick all day. The more options we have the better, keep up the good work :)
there are four important things required for this to work out:
- List of benefits of your solutions compared to other C++ → JS compilers (emscripten)
- Great documentation and good community support (forum, wiki, dynamic list of projects using Duetto)
- Very good debugging capabilities in the produced JS (Developers need to work with the code, an invisible layer sometimes means a lot of trouble)
- Big tech partners who will do complex projects with Duetto to iron-out the compiler and show "real work" can be done with it
rgds, Kira
Wow: and a minute after I typed this, my Windows machine gave me a blue screen, not sure if it's related but it's the first in years ;)