Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
David Thompson241 days ago(+1)

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


Reply
nchatz314241 days ago

Okay, I see, you define JS functions that pass the objects around like black boxes, turning x.f(y) to f_(x, y) and then you load f_ via the FFI. Does that mean the Hoot FFI is limited in how it can deal with JS objects?

Reply
David Thompson241 days ago(+1)

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.

Reply
nchatz314240 days ago (1 edit)

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.

Reply
David Thompson240 days ago (1 edit) (+1)

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.

Reply
AboutFAQBlogContact us
Copyright © 2024 itch corp · Directory · Terms · Privacy · Cookies