Hey, I'm planning on using Guile + Hoot. Feel free to message here if you want to talk about it. I haven't tried it before nor do I know any WebAssembly so it might be a strange one!
Cool! So far all I've done is install Guix on a VM and got guile + hoot working in a guix shell. I'll be looking more into the setup soon.
One question I have is this, for videogames do I need to write my own routines for the drawing primitives? When I used Fennel lisp, I used https://love2d.org/ which had a lot of primitives available.
You'll need to write bindings for the web APIs that you want to use for rendering. Hoot is still fairly new so there aren't any third-party libraries available for making games, yet. This is why I want to put a template repo together with some useful bindings so that people can get started quickly. I think the path of least resistance for rendering is to use HTML5 canvas. I successfully used canvas in the previous jam.
Here's an example of what binding a subset of the canvas API looks like in Scheme: https://git.dthompson.us/autumn-lisp-game-jam-2023/tree/strigoform/canvas.scm?h=...
And the JavaScript host code that makes those bindings work: https://git.dthompson.us/autumn-lisp-game-jam-2023/tree/boot.js?h=main#n73
Hoot isn't any more limited than what the WebAssembly security model allows. In Wasm, a heap object coming from the host is typed as (ref extern). External references are opaque, if that's what you mean by "black box". You cannot inspect their contents from Wasm. The reverse is also true for heap objects coming from Wasm; they cannot be inspected from the host (JS in this case). Having used Wasm for awhile now, it feels similar to using a C FFI where the library you are linking against uses pointers as handles to objects, only more secure. Like in SDL when you create a surface you get a pointer to it and most operations require passing that pointer to some other SDL function. The transformation of x.f(y) to f_(x, y) is a fairly common pattern when writing bindings because JS is object-oriented but Wasm only speaks in terms of statically typed functions.
Thank you for the explanation. The way you've written Strigoform, it looks to me that all drawing operations are being delegated to Javascript (with HTML5 canvas?) Wouldn't another codeflow be to have WASM for backend, JS for drawing the bitmap on screen and SharedArrayBuffer for the bitmap (shared between WASM and JS)? Is this possible?
edit: I'm reading the Hoot manual now, trying it out.
All the drawing operations have to be delegated as a wasm module cannot perform any i/o without support from the host system. It's not currently possible to write to a SharedArrayBuffer from wasm (should get resolved some day), but if it was then you could write a purely software renderer in Scheme and just send the final bitmap over to JS to render in a canvas. You could do this without SharedArrayBuffer right now but it requires a byte-by-byte copy from wasm to JS which isn't great. I wouldn't recommend this approach anyway because your game wouldn't be utilizing the GPU at all. HTML5 canvas uses hardware acceleration, which is why I think it is a good option for the time being.
In the future, when we can efficiently share blobs of binary data without copying, WebGL/WebGPU will be the way to go. This will open up the path for existing Guile game libraries like Chickadee to run on Hoot.
I want to try it too. I think it's acceptable in this jam to have some amount of js glue code in my project, and to use js libraries? I want to use something like pixijs and it's not very practical to export all of its API via Hoot FFI, so it's okay to write some glue layer in js with smaller API surface? Of course, game logic itself will be completely in Scheme.