I believe hooking up a debugger to your IDE is also possible. I haven’t tried it yet though: https://emscripten.org/docs/porting/Debugging.html?
Maybe I’ll give it a go and write about it in my next post.
https://floooh.github.io/2023/11/11/emscripten-ide.html
TL;DR: there's a new WASM DWARF debugging extension for VSCode which allows a 'traditional' debugging experience for WASM code running either in Node.js or Chrome.
Emscripten can generate DWARF debug info for a while now, and there are extensions for Chrome and VSCode which make use of this DWARF debug information and allow for a much better debugging experience.
E.g. see here:
https://developer.chrome.com/blog/wasm-debugging-2020
...and here...:
https://marketplace.visualstudio.com/items?itemName=ms-vscod...
Getting it to render was the easy part; I've since spent the majority of time getting it to feel native to the browser, implementing responsiveness (web dev term for adapting to viewport size), touch controls, GUI tweaks, working around fullscreen API gotchas (e.g., the Esc key/Back button is reserved), and any other small things that might remind you that this is not a native browser game.
I guess the WindowShouldClose() function yields control back to the browser event loop, which only works if the WASM code has been transformed into an async/await style state machine (and that's exactly what ASYNCIFY does).
I still wonder though how well this approach synchronizes with the swapchain presentation interval (which AFAIK is one advantage of using requestAnimationFrame).
Asyncify docs (different from the emterpreter-async option mentioned in the comment block): https://emscripten.org/docs/porting/asyncify.html
It really makes Game Dev fun again. Also it has tons of bindings (you don’t have to code in C)
I forget the exact reason but I think autoplay on mobile devices was the thing I couldn't figure out, and howler had some workaround.
If I did the project again I'd just copy paste the 3 lines or whatever that Howler uses for the workaround and bring dependencies back to zero.
I'm hoping to sell the game through Stripe on my own domain as well as on Steam. Time will tell whether I finish this game and whether the Web build defeats the Steam build.
I'm hoping Web wins.
I put a raylib game inside both for fun and for testing the graphics layer
If you want to refer to a collection of repositories, using a GitHub organization, even if you are the only member, prevents people from assuming you are self agrandizing.
It’s a lot of not that interesting code so I didn’t include it in the blog post.
I see so many posts like the OP here where somebody will just draw a rectangle with a texture on it and call it a game, whereas the real process to get to a playable game is a lot more complex than that, both technically and practically. You have to think about how the pieces will fit together, how it will be deployed, supporting multiple platforms, and much more.
Source code is here: https://github.com/rrampage/skitter/tree/master/pong-raylib
It is fairly straightforward to get Raylib running in the browser. I used @flohofwoe's HTML shell file ( https://github.com/floooh/sokol-samples/blob/master/webpage/... ).
Compilation is something like: emcc -o target/pong.html -Wall -Wextra -std=c99 pong-raylib/pong.c lib/libraylibweb.a -I ./include -sUSE_GLFW=3 -sSINGLE_FILE -Oz --closure 1 -sFILESYSTEM=0 --shell-file pong-raylib/shell.html
If interested, you can find the code/demo here: https://github.com/schaban/crosscore_dev (the link to the online demo is there in the README)
Nothing like a bit of humour and thinly veiled criticism to liven up a tutorial :)
