3 ms·
Cool! 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 crea
by blixt 9y ago
Cool!
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.
- wofo 9y agoI haven't measured anything :P 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.
- kayoone 9y agoso you can only pass simple types and nothing like a framebuffer array ? great work btw!
- wofo 9y agoSince WASM in its current state is meant as a compilation target for C, it is usually possible to do things "the C way". For instance, you can allocate a buffer on the Javascript side and pass a pointer to the Rust side, which then can write to it. You can also allocate it on the Rust side and return it. This is for instance what you do when you want to return a string.
- blixt 9y agoI was thinking you can create a byte buffer of fixed size instructions that you can pass from Rust to JavaScript. With for example DataView you can fairly easily inspect that data in JavaScript. Or to keep things even simpler, if every class of draw instructions is always performed in order (so not drawEnemy, drawText, then another drawEnemy) you could just have separate arrays of arguments for every draw type. Anyway for your game specifically I doubt this is even close to an issue, but I'm curious just how performance scales when you jump in and out of JS a lot in WASM.
- wofo 9y agoNever heard of DataView before, thanks! This is the first time I do something "low level" in Javascript, so there is probably a lot that could be improved. BTW, here is an example passing arrays between Javascript and Rust: https://www.hellorust.com/demos/canvas/index.html https://www.hellorust.com/demos/canvas/index.html
- Game_Ender 9y agoThe 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]. [0] - https://developer.mozilla.org/en-US/docs/WebAssembly/Understanding_the_text_format#Signatures_and_parameters https://developer.mozilla.org/en-US/docs/WebAssembly/Underst... [1] - https://becominghuman.ai/passing-and-returning-webassembly-array-parameters-a0f572c65d97 https://becominghuman.ai/passing-and-returning-webassembly-a...
- wofo 9y agoDoubles are supported as well through the `f64` type I think. Interestingly, I am passing booleans in my code as well... and it seems to work.
- landonxjames 9y agoI wonder if its converting them to 0's and 1's and sending that to the javascript?
- wofo 9y agoJust checked what is going on and that is indeed the case. Rust booleans compile now to the i32 type (though there is no guarantee that will stay like that in the future).
- onion2k 9y agoYou can do something very similar in plain JS using a sharedArrayBuffer and a webworker. A sharedArrayBuffer is a typed array in an area of shared memory that the worker and the main script can both access. It works really well if it fits your use case. I wrote a 'javascript snow' thing that uses it - https://github.com/onion2k/snowfall https://github.com/onion2k/snowfall