Cached prints

[jhauberg]

When starting this project, I was of the conviction that tile-based rendering was just a artificial limitation that should not be needed. If you could render glyphs anywhere, then you'd have more freedom and could just implement the tiling yourself.

However, i've come to realize that this approach, while perfectly fine until it runs too hot, lacks options for a program to control and optimize the rendering.

Essentially, what it lacks is a way for a program to imply that a print command will happen over and over, without change in parameters. This could be beneficial in terms of sorting and processing.

Most ASCII renderers solve this by implementing a tiling system. This essentially means that they have a grid of cells for X layers, where glyphs can be put into. In such a system, the rendering time should be stable and constant because it always has the same amount of glyphs to render- the concept of "dirty" cells is also commonly implemented so that only changes trigger re-drawing. It's essentially a big cache.

In Termlike, there's theoretically no limit (though, realistically it is at UINT16/32_MAX) to how many glyphs can be rendered, and so glyphs cannot be "cached"; essentially dirtying everything up, every frame.

I still think this approach is the right choice for Termlike, but an additional system for "cached" prints would be a useful addition. I'm not sure yet how to go about it, but something like term_put and term_putstr seems appropriate.

The ideal benefits would be that the string of glyphs would not need to be decoded, measured, transformed and sorted every frame.

Realistically, I think only the decoding (and maybe measuring) part can be avoided. The spritebatch will still need to transform each glyph.

I'm also considering other options: something like "compiling" a string of glyphs into a format that is decoded and measured ahead of time, so that you only need to do those things once.

In any case, any such additions should hook into the current rendering system (push command -> sort -> render) rather than becoming some monstrous thing running in parallel. Preferably it is all going through the same pipeline, but just skipping some steps where able.