emscripten newtontest

[Marc]

I started experimenting with emscripten (https://github.com/kripken/emscripten) lately. It compiled c++ code to js so you can run it in a browser. This evening, I tried getting newton to compile and run with it. I had to patch the code at a few places - primarily I defined the _LINUX_VER in the preprocessor and removed all too hardware close calls. I also had to modify a few things with the threads since js is basicly singlethreaded (except for webworkers). But all in all just minor changes.

I tried the simple example from here http://newtondynamics.com/wiki/index.php5?title=Super_simple_quick-start_with_48_lines_of_C_example and it works. Here is the result:

http://www.transmogrifier.de/emscripten/newtontest.html

It's a very simple demo. I'm looking forward to see if more complicated things work as well. Theoretically they should, but there are some things a bit different to native hardware. For example all floats become doubles as js has no 32 bit floats. Also js doesn't know 64bit ints. I'm not sure what emscripten does with them. I red that there are two options: simulate with 32 bit ints - which is "slow" - or use doubles and loose a few bits. Also the floating point control registers code in newton probably gets ignored. So maybe strange things could happen with precision making it unstable?

[Julio Jerez]

Oh wow, you mean that little program is newton running on Java script?
I would never thought that a language translator was going to be capable of translation a full app. two things:
The thread, you can run Newton single thread by defining DG_USE_THREAD_EMULATION either on a command line or in file
c:\temp\newton-dynamics\coreLibrary_300\source\core\dgThread.h

on the floating point setting that's no really necessary, I do it because some people that use newton on Win32 with D3D keep setting the x87 flags, and if in a call back some one do that the result of some comparison can be incorrect.
In linux, Mac and wind 64 the function is disable.

I do not know what this means, "too hardware close calls"

[Marc]

Oh wow, you mean that little program is newton running on Java script?

Yes, that's it

The thread, you can run Newton single thread by defining DG_USE_THREAD_EMULATION either on a command line or in file
c:\temp\newton-dynamics\coreLibrary_300\source\core\dgThread.h

Ok. I'll check that out.

I do not know what this means, "too hardware close calls"

I meant, the intrinsics stuff, asm parts and the AddAtomic() function. I just replaced all of that with returning the worst cpu settings at all - and the AddAtomic just adds the values now since js is single threaded. Maybe emscripten can translate some of these things more efficiently, I don't know. For now I disabled it to get it running with least hurdles.

[Marc]

I made a little bit more complex test: http://www.transmogrifier.de/emscripten/newtonguyandboxes/Game.html (2MB download, might take a while depending on your connection)
It contains 100 boxes and one user controllable cylinder. I used the 2D-Joints from the wiki to force them to the xy plane. So all of them have such a joint attached. I'm not sure how much this affects the performance. I'm quite happy with the results. 100 bodies seem to work smoothly if they don't concentrate in one island.

For comparison, I uploaded the same project compiled for native win32 as well: http://www.transmogrifier.de/emscripten/newtonguyandboxes/newtonguyandboxes.7z (There is something odd with the colors of this one. The js version reads pngs while native SDL can only handle bmps, which apparently have the colors ordered the other way around. Also bmps have no alpha channel. One can fix this if need by adding freeimage for the win32 version. There is also something wrong with clearing the background. I haven't done opengl for some time, so I'm probably doing something evil somewhere ...)
Of course, this one runs much faster.

[Julio Jerez]

How do you test it? I click the link and I get this message "Downloading data ..." but it states there for ever.

I run the secund demo and I see the box stack and the little green object, but I try many key and nothing happened.
the exe run at 999 frames per seconds, it would be nice to see how that compare to a Java Script version.

[Marc]

The natively compiled version sometimes has bugged keys. I don't know why.

I don't know why the js version doesn't work. It runs for me on chrome and firefox on windows.

The js version runs a lot slower than native. There is a fps cap at 60hz in js. Besides, newton gets called with a fixed timestep and the graphics is webgl which is probably cheap as it hands of the work to the gpu. The hard work is done in newton. The 100 objects work ok if they don't group together too much. It's hard to tell a factor. Maybe 10 times slower than native? ff nightly has some special optimization for asm.js. According to benchmarks, it's supposed to run only 3 times slower than native. I haven't tested that.

[Julio Jerez]

I wonder why stope here, maybe the virus scanner noes no let it run.
anyway 3 time slower than normal compile code, is not slow at all?

[Marc]

I think so too. I'm not sure how accurate that factor is, but theoretically, it sounds achievable. asm.js "abuses" js quite a bit. It emulates the heap by creating a large array at the beginning and implements malloc and free on this array. The same for the stack. That's what emscripten uses when compiling c++ to js. If you add special handling for asm.js code to a browser and you detect such things, you probably can get quite close to 3x native speed.

cube 2 got compiled with emscripten btw.: https://developer.cdn.mozilla.net/media/uploads/demos/a/z/azakai/3baf4ad7e600cbda06ec46efec5ec3b8/bananabread_1368053467_demo_package/index.html

[Marc]

I worked a bit more on this:

http://www.transmogrifier.de/emscripten/game0/Game.html

I removed several issues and changed a lot of things in my code. Maybe it works for you now?

I realized that webgl doesn't support glBegin() etc. emscripten does support it by emulating it. However, it does it rather slowly by creating and destroying vbos all the time for every draw call. I now changed my code to use the native webgl vbos and it got a lot faster.

[Marc]

I finished the game: http://www.mpe-online.org/games/deathdevildungeon

[Julio Jerez]

I get this error:
Could not create canvas -

[Marc]

You need a current version of Firefox or Chrome.

It's also on Kongregate now http://www.kongregate.com/games/intripoon/death-devil-dungeon

[Julio Jerez]

Oh I see, does that mean that it should work on a Mac and Linux.

I have not done yet by the real proof of this is if this works on my IMAC which is a G5 Mac.
have not try yet but let is see.

[Julio Jerez]

should it runs on Safari Mac?
G5 imac OSX 10.5 Safari, freeze wit the message downloading
Intel Mac pro OSX 10.8 Safari, It freezes on a preparing progress bar.


Later I will try on the Linux laptop

[Julio Jerez]

Installed Google Chrome on the Intel Mac and it runs there.
The game is awesome on the Intel MaC.

Fire fox and Google Chrome do not install on Mac G5.
I am so sad that almost 100% of all developers had abandoned the Power PC macs.
All of us that were heavilly invested Mac users with G4 an dG4 for years, made huge investment on hardware and software and now even Apple no longer suppport Power PC macs.
Now Mac are relegated to be Email readers. and I am guessing that it will be a matter of time until Email systems will also stop working on these macs.
Thank you Apple for nothing.

On the bright side, the game is really cool, I can even play at full screen on my Intel mac, no speed issues.