It's very nice to see that this "scales down", so-to-speak. It can be really disheartening to see small programs compile into hundreds-of-kB binary images. It's great to see that Rust+WASM can be so lean!
a "add one to a number and return it" compiled this way results in a ~100 byte binary. It's about twice the size of writing it by hand, but those gains get lost as soon as you start doing real things, so it's not a big deal.
One big jump in binary size starts when you use the allocator, as then it needs to include the allocator's code.
I'd love if those to see those web games start to use KeyboardEvent.code https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve... ; which is much more portable across keymaps and layouts than "key". Unfortunately, it's hindered by slow Edge & Android adoption:
I hadn't seen KeyboardEvent.code before, but after a quick skim I can't see how you'd use it in practice. Being able to recognize physical key positions is nice and all, but how do you map those to the character printed on the key so that you can tell the user what the controls are, before the user has pressed them?
The demo in that MDN page has the help text "Use the WASD (ZQSD on AZERTY) keys to move and steer" which doesn't inspire much confidence if it implies that you need to list controls for every possible keyboard layout and rely on the user knowing what they've got.
Very good. As for the game itself, the fact that the yellow asteroids can appear right in front of the ship is frustrating (death by bad luck: the player can't do anything to avoid it).
I didn't expect people to comment on the game itself... It is indeed quite simple at the moment. Maybe your opportunity to get your feet wet with Rust by improving the game logic?
And apart from that holding space + arrow is a very effective strat, doubly so if you do it so half your circle wraps from one end to the other confusing the tracking.
I'm currently sick at home and I don't have the mental energy to do anything useful but I actually found this oddly amusing and mesmerizing ... Because you shoot so quickly and turn so fast, I found that you can just hold down the spacebar and turn around to use your stream of projectiles kinda like a whip, turning left and right to get the curvy stream to intersect with the ships. This also defeats most of the right-in-front-of-you spawns. Anyway, very neat!
I spent the weekend playing around with Rust/WebAssembly too - calling between Rust and WebAssembly is a bit more fiddly than I expected, but I can understand why they did it.
I ended up trying to write a text adventure in Rust/WebAssembly for Ludum Dare (https://ldjam.com/events/ludum-dare/40). Due to other commitments, I ran out of time for the (48-hour) "competition", but am hoping to get something working in time for the (72-hour) "jam", which ends tonight.
A binary blob, that cannot be viewed except with an offline hexeditor.
WASM sucks. Please remove support and go back to ASM.js, at least it was readable and fast. Or transpile to JS in the first place. Thanks for destroying the open web.
One question – you are moving a lot in and out of the JavaScript and Rust "worlds" in your render function. Have you measured the difference of just creating a simple data structure with the render instructions and passing that once to JavaScript instead? I would expect that to be much faster.
The interface between WASM and JS is limited to native types that WASM supports which is just integers [0] (and maybe doubles?). With that limited API you cannot pass full structures around, the best you can do is pass what are essentially pointers to memory around [1].
Regarding your suggestion, I cannot pass an object to Javascript, because from the perspective of the browser I am writing C. An alternative would be to have each function take a pointer to the object, but it is quite cumbersome and I doubt it would have any (positive) impact on performance.
Indeed. Edge is the only browser that has WebVR support for the Windows MR virtual reality headsets. Getting support into Primrose for Edge has been... more than I can manage at the current time.
[+] [-] haberman|8 years ago|reply
https://github.com/aochagavia/rocket_wasm/tree/master/html
It's very nice to see that this "scales down", so-to-speak. It can be really disheartening to see small programs compile into hundreds-of-kB binary images. It's great to see that Rust+WASM can be so lean!
[+] [-] steveklabnik|8 years ago|reply
One big jump in binary size starts when you use the allocator, as then it needs to include the allocator's code.
[+] [-] Aissen|8 years ago|reply
https://caniuse.com/#feat=keyboardevent-code
[+] [-] mrec|8 years ago|reply
The demo in that MDN page has the help text "Use the WASD (ZQSD on AZERTY) keys to move and steer" which doesn't inspire much confidence if it implies that you need to list controls for every possible keyboard layout and rely on the user knowing what they've got.
[+] [-] junke|8 years ago|reply
[+] [-] wofo|8 years ago|reply
[+] [-] gpm|8 years ago|reply
Maybe shooting needs a cost associated with it.
[+] [-] makmanalp|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] maffydub|8 years ago|reply
I spent the weekend playing around with Rust/WebAssembly too - calling between Rust and WebAssembly is a bit more fiddly than I expected, but I can understand why they did it.
I ended up trying to write a text adventure in Rust/WebAssembly for Ludum Dare (https://ldjam.com/events/ludum-dare/40). Due to other commitments, I ran out of time for the (48-hour) "competition", but am hoping to get something working in time for the (72-hour) "jam", which ends tonight.
(Brief blog on my initial experiences at https://maffydub.wordpress.com/2017/12/02/getting-started-wi... .)
[+] [-] wofo|8 years ago|reply
[+] [-] frik|8 years ago|reply
https://aochagavia.github.io/js/rocket.wasm
A binary blob, that cannot be viewed except with an offline hexeditor.
WASM sucks. Please remove support and go back to ASM.js, at least it was readable and fast. Or transpile to JS in the first place. Thanks for destroying the open web.
[+] [-] blixt|8 years ago|reply
One question – you are moving a lot in and out of the JavaScript and Rust "worlds" in your render function. Have you measured the difference of just creating a simple data structure with the render instructions and passing that once to JavaScript instead? I would expect that to be much faster.
[+] [-] Game_Ender|8 years ago|reply
[0] - https://developer.mozilla.org/en-US/docs/WebAssembly/Underst...
[1] - https://becominghuman.ai/passing-and-returning-webassembly-a...
[+] [-] wofo|8 years ago|reply
Regarding your suggestion, I cannot pass an object to Javascript, because from the perspective of the browser I am writing C. An alternative would be to have each function take a pointer to the object, but it is quite cumbersome and I doubt it would have any (positive) impact on performance.
[+] [-] zengid|8 years ago|reply
[+] [-] Tade0|8 years ago|reply
[+] [-] wofo|8 years ago|reply
[+] [-] cproctor|8 years ago|reply
[+] [-] dm319|8 years ago|reply
[+] [-] exabrial|8 years ago|reply
[+] [-] krylon|8 years ago|reply
[+] [-] mring33621|8 years ago|reply
[+] [-] King-Aaron|8 years ago|reply
[+] [-] sebringj|8 years ago|reply
[+] [-] Karrot_Kream|8 years ago|reply
[+] [-] fasquoika|8 years ago|reply
[+] [-] jerianasmith|8 years ago|reply
[+] [-] steveklabnik|8 years ago|reply
> The time needed to figure out integration between JavaScript and Rust is too long.
Yup! This is currently a very low-level target; we're actively working on stuff here. It'll get nicer over time!
[+] [-] ungzd|8 years ago|reply
[+] [-] executesorder66|8 years ago|reply
[+] [-] moron4hire|8 years ago|reply