We need a preferences system; an abstraction which persists, to config directory or browser storage, all the usual things:
graphics options
audio options when those exist
keybindings and other input options like look sensitivity
et cetera for all-is-cubes
platform-specific or library-user-defined extensions that work in the same style
Note that it is not sufficient to just serialize the GraphicsOptions and so on, because GraphicsOptions contains several enums which have numeric parameters (such as ExposureOption::Fixed) which should be remembered in a preferences system even if they're not currently active. The GraphicsOptions schema is optimized for unambiguously telling the renderer what to do, which is not aligned with editability. I expect that non-graphics options will have similar considerations.
(Despite this consideration, all-is-cubes-desktop currently does serialize GraphicsOptions. But it also doesn't persist edits yet — just creates a config file you can edit on disk. And web has no corresponding feature.)
kpreid
commented
1 year ago
We need a preferences system; an abstraction which persists, to config directory or browser storage, all the usual things:
all-is-cubesNote that it is not sufficient to just serialize the
GraphicsOptionsand so on, becauseGraphicsOptionscontains several enums which have numeric parameters (such asExposureOption::Fixed) which should be remembered in a preferences system even if they're not currently active. TheGraphicsOptionsschema is optimized for unambiguously telling the renderer what to do, which is not aligned with editability. I expect that non-graphics options will have similar considerations.(Despite this consideration,
all-is-cubes-desktopcurrently does serializeGraphicsOptions. But it also doesn't persist edits yet — just creates a config file you can edit on disk. And web has no corresponding feature.)