You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently Claudius has a palette that is of a fixed sized and fixed content when the library is initialised. This is problematic for many old demo effects that rely on cycling palette colours rather than redrawing the screen contents.
In funocaml24 I worked around this by generating many palettes, one per slide in my slide deck, and concatenating them before starting Claudius, and then having a per slide "shader" in the tick function that applied a suitable offset once the slide had been drawn to the framebuffer object. It works, but it's clearly wasteful.
The challenge here is trying to do this is a "functional"ish way. Perhaps the palette has to be part of the framebuffer object rather than a global? But then also the majority of time you don't want to change the palette, so then the API is cumbersome for the common case.
The text was updated successfully, but these errors were encountered:
An alternative way would be to allow for a "mode change" ala the BBC micro, where you could change the screen size also - the palette is currently tied to the screen object, so it's not a huge leap.
The thing I disliked about all this is its stateful rather than functional, and I think one of the interesting differences about Claudius to TIC-80 or Love2D is making it deliberately functional, but then the OCaml way is to be more pragmatic, so are there good models for this already we can use?
Currently Claudius has a palette that is of a fixed sized and fixed content when the library is initialised. This is problematic for many old demo effects that rely on cycling palette colours rather than redrawing the screen contents.
In funocaml24 I worked around this by generating many palettes, one per slide in my slide deck, and concatenating them before starting Claudius, and then having a per slide "shader" in the tick function that applied a suitable offset once the slide had been drawn to the framebuffer object. It works, but it's clearly wasteful.
The challenge here is trying to do this is a "functional"ish way. Perhaps the palette has to be part of the framebuffer object rather than a global? But then also the majority of time you don't want to change the palette, so then the API is cumbersome for the common case.
The text was updated successfully, but these errors were encountered: