WebAssembly / website

WebAssembly website
https://webassembly.org
Apache License 2.0
272 stars 179 forks source link

AngryBots demo #86

Closed saambarati closed 5 years ago

saambarati commented 7 years ago

Can we add the AngryBots demo back to the demo page to live alongside the Tanks demo? Maybe we can add even more demos if there are some available?

lukewagner commented 7 years ago

AngryBots uses synchronous new Instance and to transition it to async WebAssembly.instantiate requires a full rebuild of AngryBots with new Unity+Emscripten. (Seth, Alon and I all independently tried a bit to hack the existing JS glue code in-place, but the synchronicity of new Instance is non-trivial to work around.) The problem is that the AngryBots tutorial project is very old and apparently no longer works on new Unity.

Happy to get other codebases up, though. FWIW, we're still working on getting UE4 (used by this demo) in a more polished state to post.

saambarati commented 7 years ago

@lukewagner Ok thanks. Is there any way I can get full access to the code base? I'm having some trouble getting that demo to move on past the compilation step inside WebKit.

Also, is the only reason we don't want the AngryBots demo because it doesn't use the async API?

Also, in general, who is working on porting various things to Wasm? Is there anyone I can stay in touch with to make sure such things work great in WebKit?

lukewagner commented 7 years ago

@saambarati Normally everyone just uses the default stuff in Emscripten. Unity might be doing something custom here; probably best to work directly with the Unity folks directly on this (I'll followup to put you in touch).

Also, is the only reason we don't want the AngryBots demo because it doesn't use the async API?

Additionally, the AngryBots demo throws a RangeError on V8 now b/c V8 limits the size of modules on which you can synchronously new Instance()/new Module().

kripken commented 7 years ago

@saambarati: if you haven't already, it might be useful to test on smaller demos too, issues might be easier to debug there. Like BananaBread (I can help there too as I ported that one) or the Oryol samples.

s3ththompson commented 7 years ago

In addition to AngryBots using sync APIs, the real problem is that we can no longer rebuild it from the source (since Luke mentioned it doesn't work in new Unity builds anymore). Given improvements that will likely land in both Emscripten and the Unity WebGL exporter in the near future, we want to have a demo that can pick up toolchain improvements.

@saambarati I will cc you on any future convos about porting stuff. As Luke mentioned, it would be great to get in touch with Unity and @juj.

juj commented 7 years ago

Other demos you can try are:

https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/tmp/2017-02-21-SunTemple/SunTemple.html https://s3.amazonaws.com/mozilla-games/tmp/2017-02-21-StylizedRendering/StylizedRendering.html https://s3.amazonaws.com/mozilla-games/tmp/2017-02-21-PlatformerGame/PlatformerGame.html

These are Unreal Engine 4 WebAssembly + WebGL 2 demos, which can fall back to WebGL 1 if needed.

saambarati commented 7 years ago

Thanks for the responses everyone.

@kripken As of a fix today I'll be landing sometime tomorrow, we're able to run the BananaBread demo.

@lukewagner @s3ththompson Thanks for clarifying. I'm ok with keeping the synchronous API out of the demos. I also agree it's best to not use AngryBots.

@juj I can't run any of the UE4 demos in WebKit. It appears to be stalling out after compiling the WASM blob. I'm not too sure why. Any help would be appreciated. Is it possible to get access to the source for some of these demos so I can hack on the JS code locally? I'll spend some time with the demos tomorrow to try and diagnose why it's happening. (If you're interested in trying this out yourself in WebKit, it's best to wait for tomorrow night's nightly build. I'll be landing a WASM fix in WebKit sometime tomorrow. This is the fix that'll allow us to run the BananaBread demo).

juj commented 7 years ago

@saambarati : there is an update to https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html demo that went live today, and it now has a number of features you can try to help diagnose the issue where it hangs. Check out the page console for any potential diagnostic messages.

Also, you can run via these special URLs to disable some features to see if those might affect:

You can pair multiple params, e.g. to disable all of the above, visit https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html?noidbread&fakegl&noaudio

To run locally:

  1. download https://s3.amazonaws.com/mozilla-games/ZenGarden/2017-03-14-ZenGarden.zip
  2. download https://raw.githubusercontent.com/juj/emrun/master/emrun.py and place it to where you unzipped Zen Garden.
  3. Run ./emrun.py --no_browser --port 8080 . in Terminal.
  4. Visit http://localhost:8080/ in browser.
saambarati commented 7 years ago

@juj Thanks for all the information. If you download the latest webkit nightly, you can see that we're getting a syntax error that looks like we're reading undecoded content. Do you know what this could be?

It's in the file: blob:https://s3.amazonaws.com/6787db21-ca13-4dd0-bf60-ada7617148df The error is: SyntaxError: Invalid character '\u0031'

(You can download a nightly here: https://webkit.org/nightly/)

juj commented 7 years ago

Thanks for the link to Nightly @saambarati , that made it easy enough for me to test it out. Got the Zen Garden demo running on the WebKit Nightly build, great job guys!

I do also see the Invalid Character bug. Pushed a new build of the Zen Garden demo live to amazonaws and also available to run offline at https://s3.amazonaws.com/mozilla-games/ZenGarden/2017-03-15-ZenGarden.zip to explore better error reporting around that issue.

It looks like some kind of bug with gzip decompression? If I disable gzip compression of assets, the page runs fine. I.e.

  1. download https://s3.amazonaws.com/mozilla-games/ZenGarden/2017-03-15-ZenGarden.zip and unzip.
  2. Unzip all foo.bar.gz files to foo.bar (i.e. UE4Game-HTML5-Shipping.wasm.gz to UE4Game-HTML5-Shipping.wasm and so on)
  3. Edit EpicZenGarden.html and at the top of the page, change const serveCompressedAssets = true; to const serveCompressedAssets = false;. That causes the .html page to load up the non-gz variants of each file (search for Module.locateFile in the .html page to see the logic behind that)
  4. Run ./emrun.py --no_browser --port 8080 .
  5. Visit http://localhost:8080/ in browser.

Not sure why the gzip compression does not work though. Perhaps that could be an already known tracked issue in WebKit tracker somewhere?

JanOschii commented 7 years ago

@juj Don't know if your the right person to talk to. But If I open the Zen Garden Demo in Chrome 60 you get this message. Would be nice to have this running. As it is one of the best demos out there.

image

juj commented 7 years ago

@JanOschii : does that occur with https://mzl.la/webassemblydemo ? Tried that out now, and it is working ok for me on current Chrome Canary channel.

If you are running with a local copy of Zen Garden, make sure you are using something like the emrun tool to spin up a web server that is gzip aware. Running with emrun --no_browser . in the directory where Zen Garden lives and navigating your browser to the URL emrun is showing should work for compressed assets.

tjgalama commented 6 years ago

This demo takes web-assembly to a next level: https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/win2k.cfg&mem=192&graphic=1&w=1024&h=768

binji commented 5 years ago

This is a pretty old bug, seems like we can close. Reopen if there are further issues.