pixelsprout (Sep 17 2026 at 00:51): pixelsprout (Sep 17 2026 at 00:51):Had a go at creating my own Roc platform on top of a toy game engine I am building in Odin. It's pretty compelling being able to run roc run main.roc --watch and be able to make quick edits to a game and see it update so quickly.
roc_odin_engine_test.mov
Richard Feldman (Sep 17 2026 at 01:54):very cool! :smiley:
pixelsprout (Sep 17 2026 at 03:45):Spent a while on allocation. Currently, Roc calls into the host for every allocation, and free is a no-op, so the arena only reclaims when you reset it, but the live state is sitting in it. Ended up with two arenas that take turns: Roc allocates into the current one, and when it passes a watermark I copy just the state into the other and wipe the first. Because I don't retain the state, its refcount stays at 1, so the release backend mutates in place and allocates nothing at all.
Steve Howell (Sep 17 2026 at 12:56):@pixelsprout Is there something that Roc should be doing differently? (I'm asking as a Roc newbie who hasn't tried to do anything like this yet.)
Steve Howell (Sep 17 2026 at 12:56):Cool screencast by the way. :)
pixelsprout (Sep 17 2026 at 20:55):@Steve Howell Yeah it generally pretty good, I do wish roc had a way to generate language neutral bindings. Maybe if roc had a way to emit a types.json file or something that the host language could generate off.
Luke Boswell (Sep 17 2026 at 21:22):pixelsprout said:
had a way to generate language neutral bindings
You're in luck... we do :grinning_face_with_smiling_eyes:
The roc glue command takes a Roc app plugin script. The roc compiler will type check the platform you provide it as an argument, and provide a list of detailed information about every public host facing type that can cross the boundary from Roc. The script you write can then take those types and codegen the source bindings in any language you like -- we have implement C, Rust, and Zig as a starting point to help us validate and ensure we haven't coupled the API to any one language, but the goal is to encourage people to write bindings for more languages.
pixelsprout (Sep 17 2026 at 21:25):Ah nice! I had a feeling that as soon as I mentioned the above that this was actually possible. Maybe I can help in the Odin department.
Luke Boswell (Sep 17 2026 at 21:26):Here's the glue scripts you can copy from https://github.com/roc-lang/roc/tree/main/src/glue/src
Luke Boswell (Sep 17 2026 at 21:27):I would note claim they are perfect ... I've gone through a few rounds of upgrades on these but I'm sure there is still a lot more to do
Luke Boswell (Sep 17 2026 at 21:28):I am tracking a few issues I'd like to get around to fixing someday. I've been working around things mostly at this point... and haven't found anything that has totally blocked me.
pixelsprout (Sep 22 2026 at 02:29):I'm thinking of modelling the Elm architecture onto my game engine.
So roc would have these 3 functions it can call
init : Config -> Model
step : Model, Input, F32 -> Model
view : Model, Model, F32 -> Scene # prev, current, alpha
So Odin will manage things like the window, click, GPU resources etc... Then Roc will manage the Model. So in a nutshell it's kinda like Odin is driving the car and Roc is telling Odin where to go.
I can image being able to do rewind/replay logic by keeping step pure, by keeping a log of each state change.
Luke Boswell (Sep 22 2026 at 03:32):How will you clone the Model to provide prev? I would assume it is better to not do that so the refcount stays 1 and Roc can mutate the model in place.
pixelsprout (Sep 22 2026 at 04:01):That is a good point :thinking: Holding a previous Model while stepping the current one gives the current one a refcount of two, so Roc copies every list it writes. I was thinking of using the previous model to interpolate. I could let Odin keep the last two render snapshots and lerp between those instead, so Roc just knows one thing: "where is everything right now".
So could be this signature instead:
init : Config -> Model
step : Model, Input, F32 -> Model # per fixed step
view : Model -> Scene # per fixed step, after step
Progress report: I have a playable game now. Doesn't look pretty, but coding the game logic is super slick imo. init, step and view remain as pure functions as well.
Screen Recording 2026-09-24 at 4.54.49 PM.mov
Last updated: Sep 24 2026 at 15:59 UTC