Is playcanvas using emscriptem or is it written directly in js? nice project by the way. Also what does the worker do? does it have access to the canvas context or it just does some calculations and communicate with the main thread via serialized data.
Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain.
I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context.
I also don't see threading in here. Makes sense for a demo, but if this were to be used performantly you'd have to throw it all in a webworker so it doesn't block the main thread. This is one point of contention with wasm because it's not straightforward to render to a canvas/webgl on the main thread from a worker thread. OffscreenCanvas is one workaround but not supported by FF or safari.
Interesting. With a little hackery, it should be fairly easy to get this working with PlayCanvas. I'm not sure why it needs to use a new element type though (canvas3D).
Nice! How do you like the JavaScript canvas api? I found it hard to be productive with but I plan on taking another stab soon. I’ve had more luck with svg animations and pixi.js but I want to learn enough of the canvas api to solidify my opinion of it.
As the other commenter said, you are right that you can't work with canvas in the worker, but you can work directly with the array of image data which you'd often need to anyway for much processing.
I saw a library a while ago that was trying to re-implement the canvas primitives using only typed arrays so it was worker safe but I'm not sure what happened to it.
This is a great article, but if you're really going to make a canvas game then you're much better off using a game engine. I recommend MelonJS[1] or Impact[2] if you don't mind the cost. I also have a side project that compares JavaScript game engines in much the same way TodoMVC compares MV* frameworks: http://city41.github.com/breakouts
Hi, I wrote the majority of that part of the project (canvas stuff) & that section of the article – the simple answer is that I have a lot of experience working with the canvas API directly, but little to no experience using any of the popular JS game engines out there (I played around with Phaser years ago, but not very much). I don't think it would've saved me any time to be honest.
How similar/different is the OffscreenCanvas proposed spec from the CanvasProxy proposed spec? I thought there were going to be synchronization nightmares to CanvasProxy and that is why browser vendors avoided implementing it.
OffscreenCanvas appears to be a special canvas object that you can transfer to a web worker, draw to it there off of the DOM thread, and then "commit" the updates to the associated DOM Canvas.
Is the DOM canvas neutered after calling transferControlToOffscreen? Meaning, can you get a context and draw to the canvas concurrent with the Web Worker, or is the DOM Canvas inaccessible after control is transferred?
If it is the latter, then is this OffscreenCanvas just a WebGL-exclusive version of CanvasProxy? What are the characteristics of WebGL versus 2D-canvas API that make it conducive to Web Workerage? Not that I'm complaining, I just don't understand what's the difference.
I'm curious about how bad the synchronization issues are with OffscreenCanvas in this first implementation.
In any case, this may have incredible implications for mobile web game development if the experiment pans out, not to mention desktop games! Super exciting, I've been dreaming to be unshackled from the DOM thread for years. Thanks AGAIN, Mozilla!!
Hi s-macke. I've read the source code of your emulator before, good job.
I'm aware of the problem with big integers. I'll look into this more closely, thanks for your help.
Regarding workers: I need some restructuring to get this working. I'll also need to figure out the fastest way to exchange the canvas buffer between the worker and the browser.
I'm guessing that means you rolled your own canvas API code, rather than using a library like PixiJS. Is that something you'd consider open-sourcing, or is it so tightly integrated with game-specific logic that it wouldn't make sense?
I'm currently working on an web ide that use the Canvas instead of the DOM. The Canvas is very nice to work with, it's high level and hardware accelerated.
To be honest, right now, it's a pretty bare bones wrapper around the actual canvas API. Maybe there's more to come? What can it do that you can't currently do with one or two lines of normal JS?
reply