4 Commits

Author SHA1 Message Date
1a64443cca refactor!: Make TextElement more usable on its own (#2679)
This is part of my ongoing effort to simplify the text rendering
pipeline.
My ultimate goal is to:
* get rid of renders
* rename formatters to renderers
* make the interface complies to both
All details are specified here:
https://github.com/flame-engine/flame/pull/2663

As a first step to break down that huge PR, this makes a small change to
TextElements to make them more useful

This PR will:
### rename render -> draw

draw becomes the "internal", underlying impl, raw method, that just
draws the element w/ any custom options

### add a new render method that takes in more options

this does not need to be extended by every impl.
this is for end users and accepts parameters like position and anchor to
be more in line with the renderer interface

This is technically a breaking change but should have no effect for
users, unless you are creating your own custom `TextElement`s. In that
case, to migrate:

* rename your `render` method to `draw`
2023-08-26 12:10:03 -04:00
2d45d2be39 chore: Remove 1.8.0 deprecations (#2538)
Removes all the deprecated methods before 1.8.0 release.
2023-05-22 19:01:55 +02:00
b5780d4212 feat: Add support for styles propagating through the text node tree (#1915)
This PR continues the work for enabling rich text support within Flame.
Here I add support for different text fragments having different TextStyles, and allow those styles to be inheritable within the text node tree.
2022-10-08 11:08:18 +00:00
bfdc3a291b feat: Structured text and text styles (#1830)
This PR introduces the notions of structured text, and text styles, to support rendering of rich text bodies.

Specifically, we recognize that sometimes in games one needs to render pieces of text that are larger than a single word or even a single paragraph. These pieces may include: books, quest descriptions, mission objectives, tutorials, in-game help system, dialogues, etc. Rendering such a piece of text is non-trivial, however. In order to tackle this problem, I break into the following parts:

Text structure, represented as a tree of Nodes. The nodes describe the logical structure of the text, for example the document may contain a header, and then several paragraphs, and a list, where the list contains some list items, some of which having possibly several paragraphs, etc. This structure is similar to how in HTML the text is marked up with HTML tags.

Text styles are struct-like classes that contain properties describing how the text is to be styled: font size, font renderer, borders, backgrounds, margins, padding, etc. This representation is also tree-like, so that for example text inside paragraphs can have different style than text within headers, and paragraphs within lists can have different margins. A text style is similar to a stylesheet in HTML.

Text elements are the result of applying the document style to a document node: they are the "prepared" and laid out pieces, ready to be rendered. Elements are a bit like mini-components, or perhaps text "particles" in a particle system.
2022-08-10 08:13:27 +00:00