Building a Web Game in C
anguscheng.com
anguscheng.com
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
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
It really makes Game Dev fun again. Also it has tons of bindings (you don’t have to code in C)
Another big thing is it doesn’t support iOS at the moment.
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.
Alternatively, a "central" repo linking to the others would also work.
Right now, the site says that the link leads to the project, but instead, it links to you. That's giving the impression that the project's primary goal is to raise your personal profile.
Maybe start thinking about creating an organization when there are other maintainers with push- and merge-rights, but until then keeping the subprojects under your user is completely fine.
Also: your project, your rules - just do what feels right to you :)
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 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.
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)
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://marketplace.visualstudio.com/items?itemName=ms-vscod...
...IME this is a lot easier to setup than the Chrome extension (the problem in Chrome that's easy to overlook is to allow Chrome access to your source code directory, the VSCode extension doesn't require such brittle details).
The blog post I posted in a sibling comment above details how to setup VSCode so that debugging works by just pressing F5 in VSCode like it would work for natively compiled code.
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...
Nothing like a bit of humour and thinly veiled criticism to liven up a tutorial :)
It’s a lot of not that interesting code so I didn’t include it in the blog post.
And that is all, no interesting excerpt, I was able to get source code of the entire page myself :) You are writing an article/tutorial. This kind of work should be in, this was my initial feedback.
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 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.