I wrote about this in my audio article [1]. Ideally, browsers will implement support for a configurable `sampleRate` in the `AudioContext` constructor.
There is a tracking issue [2] for Chrome but I wasn't able to find one for Firefox.
Thanks for the heads up, that is curious. I don't have access to a linux machine at the moment, but will investigate later. There should be some output from binaryen in the JavaScript console, does it report success?
Back when Dart first came out (I think 0.1), I built a gravity simulator in it. It was a shameless rip-off of http://www.nowykurier.com/toys/gravity/gravity.html, but it was just for me to get a little familiar with it.
It was pretty dang great writing that project, and I'm beyond surprised that Dart didn't have more success in replacing JS.
I unfortunately lost the source code at some point :(
(this was before I got organized, got a GitHub, etc).
The game is popular on the Chrome Web Store, and ~30% of those users are on Windows. Chrome Apps will stop working on Windows later this year, and Steam seems like a good place for them to transition. A full blown web version is another possibility.
Thanks for sharing! Your article is what I was looking for and didn't find when I was working on the audio :) That is an interesting approach which I will definitely try.
Really cool project. Just tried on my Moto E 2nd gen with Chrome and it was smooth as butter. Are you storing images as svg inside the wasm blob? Seems like you're not batching draw calls? Was the Dart app not fast enough?
The 2D elements (menu buttons, background trees, etc...) enter the game's editor as SVG, where they get converted to an intermediate vector format that is optimized to be loaded and rendered fast. That intermediate format is what's inside the wasm blob.
Regarding draw calls, I could definitely batch more than I do. But the game is rarely draw-call-bound so I haven't had a reason to optimize that part of the graphics pipeline.
Dart is still used in the game's editor, which has been stable for a couple of years now. For the production engine, C++ just makes too much sense. It is what made this WebAssembly demo possible :)
Yes, it is a custom format. The paths are "triangulated" on the CPU once and the resulting triangles are uploaded to the GPU for subsequent draw calls.
Thanks for sharing, I'll have to digest all of it. How has your experience on the app stores been? Have you seen the conversions you were expecting? How do you plan to continue the freemium model in its web form?
I plan to keep the web version as a demo for now. It contains the first 4 levels of the game, and after you beat the 4th level it will ask if you'd like to continue to the various stores (App Store if you're on iOS, Play if you're on Android, else Steam).
My experience on the stores has been good, people who play the game seem to enjoy it. The hard part has been discovery :)
Your game is amazing! I'm particularly intrigued by the 3D-ness of the sprites and how smooth all of the animation is. Can you suggest any resources for learning more about the process of making similar content (without giving away your secret sauce, of course)?
Thanks! The characters are regular 3D models. The 2D elements are where the game differs from a lot of other games. If you use vector graphics the size of your assets will decrease dramatically, and your game will be resolution independent.
That is a difficult question to answer as there are many factors involved, not just the choice of language. JavaScript can be really fast, but WebAssembly may provide more predictable performance and faster loading times. The project website is a good resource to learn about the differences: http://webassembly.org
There is a tracking issue [2] for Chrome but I wasn't able to find one for Firefox.
[1] : http://www.rossis.red/wasm.html#audio [2] : https://crbug.com/432248