Show HN: A WebAssembly game demo
funkykarts.rocks
funkykarts.rocks
I have also been taking notes while building this here:
http://www.rossis.red/wasm.html
I'm happy to answer your questions about it.
BTW, I also ran into issues with ScriptProcessorNode when generating audio, and ended up using `createBufferSource` with a scheduled playback time. I wrote a little about it here: https://binji.github.io/2017/02/28/binjgb-on-the-web-part-2....
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 :)
My experience on the stores has been good, people who play the game seem to enjoy it. The hard part has been discovery :)
Regarding animation, this is a good resource to get started: http://robertpenner.com/easing/
Also, your page now says "Sorry your browser does not support WebAssembly" in Safari, yesterday it didn't.
Why do you need to rely on the production binary to be human readable? Should web developers be forced to open source all their work, whether they want to or not, because of technical limitations of the web implementation?
> I think I'll soon miss the days where we all had to show each other our code on the web.
All of my code is open source, you're welcome to look at it. That's not changing because WebAssembly is coming out.
Yes. If they want it to run on the Web. That's the way it currently is and that's the thing I'm saying I'll miss.
You don't have to put any of your code on the Web, but when you do I can read it. I like that.
What you're experiencing here is a lot more equivalent to someone putting up an HTML page that contains links to .exe binaries to run a 3D game. Except with WebAssembly, you get to skip the downloading .exe and executing it in a safe sandbox steps.
The .exe binary wasn't open source before, and it isn't now.
So I don't see why WebAssembly is causing feelings of dread for you.
I think that's the point. Obfuscation.
All minified code is easily de-minified if you want to know how it works (and can understand the language)
The point I was trying to make is that the days of yore OP was alluding to where when I "put any of [my] code on the Web, [...] I can read it" are long gone, thanks to the obfuscation of modern bundling technologies.
By the same logic, all compiled code (including WebAssembly) is easily reverse engineered if you want to know how it works.
Yes - that's how the web works (barring obfuscation/minificaction). And it's how wasm will work too: http://webassembly.org/docs/text-format/.
That said, WASM may make things better in the future at least when it comes true open source. It's a pretty clean output target, making things like verified builds a possible extension.
Once better debugging support lands, sites can opt in to providing fully mapped output->source code as part of the debug metadata allowing a functional view source.
I was hoping that mapping data would be an inherit trait of WebAssembly, as I too prefer how open source frontend languages are.
I'm very excited for WebAssembly, but I would hate to lose the ability to easily dissect what's running on our machines. Even with minification this is still somewhat possible.
At the very least, I hope browser vendors improve dev tools for reading wasm files in the future.
"Can you update these files?"
"Sure, can you give me the source code?"
"I gave you the source code."
"No you didn't. I can't edit these."
"Well it's all I've got."
If Google and Facebook weren't run by supremacists, and instead considered the general public as intelligent beings who are capable of understanding software, we might see more software coming out of those walled gardens. But they don't. Facebook and Google "engineers" (and software "engineers" at large) think of software as fundamentally hard, fundamentally technical, fundamentally something for the precious few with brains big enough to engage with it deeply.
It's just like books used to be, when the educated considered reading too advanced for the unwashed masses.
And so these service companies toss apps over the wall for the plebs to play with, and they keep all the cool toys for themselves.
There are some exceptions. They open source some commodity tools, but only where there is open source competition forcing them to do so.
I find it quite sad. But they'll lose when the web comes roaring back, when some IDE learns to operate within the language of the plebs, and the plebs learn to code, the wizards at Facebook and Google will find out what happens when you treat your customers like they are too stupid to operate at your level. Silicon Valley runs on supremacism. Supremacism breeds resentment. Bumpy roads ahead.
Some people at Google seem to understand this. I see them fighting for an alternate worldview. Maybe when the change happens, that minority will gain control of the company.
I mean, considering I program in React every day, I find this characterization of Facebook's engineers maybe a little insulting. They seem to be perfectly aware their tools are usable by others, and probably went out of their way to make them as usable as possible by others.
Anyways, whatever, my two cents are a lot less passionate than yours, so carry on.
They certainly didn't do it because they see a path from "Typical Facebook User" to "React User". They see typical Facebook users as consumers of services, incapable of understanding software in a deep way.
And they see them that way because they are supremacists. I don't think this assertion is overblown at all. I wish more programmers would just admit that they are supremacists, then we could get on with talking about whether that's a problem or not.
How about the fact that it is just flat-out superior? Do you really disregard the tool entirely simply because there are alternatives? React is amazing. I am guessing you don't think much of front-end development?
>They see typical Facebook users as consumers
Who is "they"? Every single person at Facebook? I think you are painting with a broad brush. People work at businesses; they don't follow the party line of said business.
>I wish more programmers would just admit they are supremacists
What is your point? That people who have written enough code that they are capable of developing software think they are more knowledgeable about software than people who haven't written enough code to be capable of developing software?
What about this makes a software engineer a supremacist vs. a mechanic, a scientist, a mechanical engineer, a ....
The point I was making that the market is demanding it (as opposed to companies pushing it on users) is entirely material to the discussion.
If you disagree, why not spend a day talking to one of those engineers? I'm one. My friends are others. We're mostly nice people, with hardly a sense of superiority at all!
> The design goals for a WebAssembly text format derive from the following use cases:
> View Source on a WebAssembly module, thus fitting into the Web (where every source can be viewed) in a natural way.
[1] http://webassembly.org/docs/text-format/
EDIT: looks like this [2] can convert between binary and textual format.
[2] https://github.com/WebAssembly/spec/tree/master/interpreter/
At the same time it makes me miss Flash.
I know it's easy to hate on flash, it was kinda buggy/slow and it was also crazily insecure. But the web really got interesting with flash, people were creating games, animations, interactive websites.
All the websites are pretty static/flat nowadays. Even if from a design point of view they might look "nicer", I liked the Flash era.
Here's an example:
Would he happy to hear more on how they compiled from their custom engine to this webasm target.
It runs and looks fantastic at 2560x1600 fullscreen too (on a laptop made in 2011).
https://www.unrealengine.com/en-US/blog/unreal-engine-4-16-r...
You may be confused with ASM.Js, which IS javascript. It is a very optimized version that uses a similar idea of a CPU instruction set (get register, add, branch on flag, push on stack, etc), but it still is interpreted. ASM.Js is very fast and also has some transpilers, but it is very different from Web Assembly.
Web Assembly has the highest potential. High potential for speed, calculations, AND RISK. The threat model for Web Assembly has not been tested as well as Javascript.
minified and/or optimized JavaScript is generally not human-readable. Try view source on some major websites.
That said, there are indeed security concerns with Web Assembly that are and will need to be addressed, as it runs way closer to the metal and has access to direct memory.
I could understand if, say, Chrome had many actively exploited security holes like things were in the Internet Explorer days but I wouldn't say this is the case now.
Functionally speaking, are you able to read minified JS?
They've done a pretty good job with compressing the assets too. Good weissman score.
I'm on Firefox/Linux. Other WASM demos work, so I'm pretty sure that's a bug. :)
Console: http://i.imgur.com/hVNCskv.png
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).
Only the bottom left of the canvas is showing the game the rest is a lite blue box.
Edit: however it displays correctly in Firefox 53.0.2 (Android) on the same phone.
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
https://stackoverflow.com/questions/12517000/no-sound-on-ios...
Uncaught (in promise) DOMException: play() can only be initiated by a user gesture.
It's triggered in the game loop where the user event has been added to a queue so it's not in the same call stack. The coins are picked up in the air etc so I have a hard time believing they are within the same call stack since it's long after the jump.