Graphics protocol #23

New Issue

scott · 2023-12-27T00:36:34Z

scott commented

2023-12-27 00:36:34 +00:00

What should the graphics protocol be for Ludus?

At current, in the pure-function JS version of Ludus, the output of Ludus is a JS object that has a result (a string representing the output value of the script), a console (a JS array of strings that get written to the console in a Ludus script), errors (a JS array of errors messages), and a draw field. This draw field is, to a close approximation, a series of S-expressions (JS arrays) that describe a series of graphics calls against p5.js. For the quick-and-dirty version of Ludus, and to stand up turtle graphics real fast, this makes sense.

@matt expressed some reservations about coupling Ludus to p5. That makes total sense.

But we have to speak some kind of graphics protocol.

We've landed in JS, and that seems to suggest that the browser is our environment, but I can see wanting to deal with other kinds of graphics than canvas: SVG, for example. In my work on https://alea.ludus.dev/twc/ludus-repl, I find myself wanting a local/native/server-side JS graphics scene that's not p5.

Given that, eventually, Ludus will run in Zig/WASM, it strikes me that we'll want to have multiple possible renderers for a graphics protocol. That also suggests we need a Ludus specific graphics protocol.

That connects to interesting, difficult design questions like: does this protocol embody ideas like our computational transitional objects? What belongs in Ludus vs. in a host environment?

What should the graphics protocol be for Ludus? At current, in the pure-function JS version of Ludus, the output of Ludus is a JS object that has a `result` (a string representing the output value of the script), a `console` (a JS array of strings that get written to the console in a Ludus script), `errors` (a JS array of errors messages), and a `draw` field. This `draw` field is, to a close approximation, a series of S-expressions (JS arrays) that describe a series of graphics calls against p5.js. For the quick-and-dirty version of Ludus, and to stand up turtle graphics real fast, this makes sense. @matt expressed some reservations about coupling Ludus to p5. That makes total sense. But we have to speak some kind of graphics protocol. We've landed in JS, and that seems to suggest that the browser is our environment, but I can see wanting to deal with other kinds of graphics than canvas: SVG, for example. In my work on https://alea.ludus.dev/twc/ludus-repl, I find myself wanting a local/native/server-side JS graphics scene that's not p5. Given that, eventually, Ludus will run in Zig/WASM, it strikes me that we'll want to have multiple possible renderers for a graphics protocol. That also suggests we need a Ludus specific graphics protocol. That connects to interesting, difficult design questions like: does this protocol embody ideas like our computational transitional objects? What belongs *in* Ludus vs. in a host environment?

scott added the

research

labels 2023-12-27 00:36:34 +00:00

scott self-assigned this 2023-12-27 04:18:26 +00:00

matt was assigned by scott

2023-12-27 04:18:34 +00:00

scott added this to the Computer Class milestone 2024-04-26 21:14:58 +00:00

scott referenced this issue

2024-05-18 22:29:18 +00:00

Refs & state #24

scott modified the milestone from Computer Class to 0.2.0

2024-05-29 19:08:09 +00:00