3 ms·

We will publish extensive tutorials soon, for now you can find some examples on http://leaningtech.com/duetto/examples/ http://leaningtech.com/duetto/examples/

We will publish extensive tutorials soon, for now you can find some examples on http://leaningtech.com/duetto/examples/ http://leaningtech.com/duetto/examples/ In addition, the full source code of Nontetris ( http://allievi.sssup.it/jacopone/cnontetris/ 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

kirab 13y ago
Hi Stefano, 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
flohofwoe 13y ago
FYI: http://leaningtech.com/duetto/examples/ http://leaningtech.com/duetto/examples/ is broken on OSX in Chrome and FF for me, it looks like a mobile page is served which makes the code examples unreadable. It looks good in Chrome on Windows7, but also broken in FF on Windows7. Haven't test other platforms. 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 ;)
flohofwoe 13y ago
For games I think you need to show that duetto is just as fast as emscripten when running. emscripten-generated code is very light on the garbage collector (inside emscripten generated code no garbage is produced at all, only in some wrapper code which needs to talk to JS libs), and having the "heap" in a plain typed array usually also gives a performance advantage, since as in C++ you have exact control of the memory layout of your data structures. Not having to construct and destroy JS objects all the time, and keeping all data in typed arrays is essential for performance I think. This is even true without diving into asm.js.
- apignotti 13y ago
  We have written a detailed post a few months ago comparing duetto to emscripten. We also explain why we think it's not a good idea to use a pre-allocated typed array heap: http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-asm.js/ http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...
  - flohofwoe 13y ago
    Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games. And as for the (big) size of the pre-allocated memory: either your game needs that much memory at a time or it doesn't, if the user doesn't have that much free you're f*cked either way. 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
    - angersock 13y ago
      From the link: "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?
    - apignotti 13y ago
      I see your point. Still, I believe the browser environment is different from a console since it is not supposed to monopolize system resources while being used. Managing memory in smaller short lived chunks is more fair for the system as a whole.
icefox 13y ago
You should include a link to the examples in the copy

kirab 13y ago

Hi Stefano, 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

flohofwoe 13y ago

FYI: http://leaningtech.com/duetto/examples/ http://leaningtech.com/duetto/examples/ is broken on OSX in Chrome and FF for me, it looks like a mobile page is served which makes the code examples unreadable. It looks good in Chrome on Windows7, but also broken in FF on Windows7. Haven't test other platforms. 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 ;)

flohofwoe 13y ago

For games I think you need to show that duetto is just as fast as emscripten when running. emscripten-generated code is very light on the garbage collector (inside emscripten generated code no garbage is produced at all, only in some wrapper code which needs to talk to JS libs), and having the "heap" in a plain typed array usually also gives a performance advantage, since as in C++ you have exact control of the memory layout of your data structures. Not having to construct and destroy JS objects all the time, and keeping all data in typed arrays is essential for performance I think. This is even true without diving into asm.js.

apignotti 13y ago
We have written a detailed post a few months ago comparing duetto to emscripten. We also explain why we think it's not a good idea to use a pre-allocated typed array heap: http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-asm.js/ http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...
- flohofwoe 13y ago
  Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games. And as for the (big) size of the pre-allocated memory: either your game needs that much memory at a time or it doesn't, if the user doesn't have that much free you're f*cked either way. 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
  - angersock 13y ago
    From the link: "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?
  - apignotti 13y ago
    I see your point. Still, I believe the browser environment is different from a console since it is not supposed to monopolize system resources while being used. Managing memory in smaller short lived chunks is more fair for the system as a whole.

icefox 13y ago

You should include a link to the examples in the copy