Text Sprites

[AstraLuma]

Add text sprites as an alternative to image sprites.

[jamesBrosnahan]

@astronouth7303 Is there a canvas object available to subclass sprites from? [systems.py has it coded to expect a sprite to have resource_path and image and then load the image using a call to pygame]

[pathunstrom]

We're going to provide at least two methods of displaying text, both best for labels. Adding to 0.7.0 release plan.

[AstraLuma]

@jamesBrosnahan no, a canvas is on the plan, but we haven't done it yet.

Also, we rewrote how images are handled.

[AstraLuma]

This is the primary goal of the v0.8.0 release. The plan is to build on the asset system--text is rendered to a surface, and then the surface is composited through the current render pipeline.

Several assets will be defined:

• Text -> Surface: Responsible for actually rendering the text into pixels
• Font -> Fonty thing: Loads a font (Formats??) from VFS
• SysFont -> Fonty thing: Loads a font installed to the system
• (Future) Text(please rename) -> String/Formatted blob: Loads text from the VFS (localization, large text blobs, format parsing, scripts, etc)
• (Future) View -> Surface: Takes a surface/asset and returns a cropped/subsurface/etc view of it

Several core things need to happen to enable this:

• We can no longer assume sprites will be square, and we should update the data model to match (Non-square sprites #372)
• To enable background rendering of text, we need to create chained/composite assets--assets that take other assets and do additional background processing. (Chained Assets #373)

The reasons for multiple layers of assets like this:

• Separation of concerns--the text renderer doesn't care where the font came from, just that it has one
• Composition--Open-ended descriptions leaves the system flexible for future changes/features/innovations
• I personally think it's clearer: You look up text, see it needs a font, look up fonts, etc

An open question is about mutability: Should we be leaning towards mutable or immutable assets for these composite/generated assets (like rendered text)? File-based assets are perfectly sensible as immutable.

• Immutable are much simpler to implement, but potentially harder to use
• Mutable is simpler to use, but much harder to write (each attribute update potentially triggers a re-render, needing to control when an update is complete to trigger the background work, etc)

Especially consider the above in the context of eg progressive reveal text (common in RPG dialog).