Commit graph

6 commits

Author SHA1 Message Date
Bill Currie
b230fe18ce [ecs] Split component registration from pool creation
While this does require an extra call after registering components, it
allows for multiple component sets (ie, sub-systems) to be registered
before the component pools are created. The base id for the registered
component set is returned so it can be passed to the subsystem as
needed.
2022-12-13 22:58:44 +09:00
Bill Currie
bb677a1a7c [ecs] Move href_comp into hierarchy_t
This means that the component id used for hierarchy references must be
passed to Hierarchy_New and Hierarchy_Copy, but does all an entity to
have more than one hierarchy, which is useful for canvases (hierarchies
of views) in the 3d world (the canvas root would have a 3d hierarchy
reference and a 2d (view) hierarchy reference).
2022-12-12 00:20:20 +09:00
Bill Currie
1d51c05f90 [ui] Make passage objects reusable
I had intended to do this for a while, but now that I want it for center
print strings, it was time to make the change.
2022-11-04 13:06:20 +09:00
Bill Currie
9e57d5cb77 [ui] Create entities for passage text objects
At least, I think I want to do that :)
2022-10-28 11:43:03 +09:00
Bill Currie
45e47a6df0 [ui] Update passage code to use an ECS hierarchy
It's not quite complete in that entities need to be created for the
objects, and passage text object might get additional components in the
hierarchy, but the direct use of views has been replaced by the use of a
hierarchy object with the same tree structure, and now has text objects
for paragraphs and the entire passage.
2022-10-27 19:47:10 +09:00
Bill Currie
9798400cfb [ui] Add a sub-system for parsing text passages
A passage object has a list of all the text objects in the given string,
where the objects represent either white space or "words", as well as a
view_t object representing the entire passage, with paragraphs split
into child views of the passage view, and each paragraph has a child
view for every text/space object in the paragraph.

Paragraphs are split by '\n' (not included in any object).

White space is grouped into clumps such that multiple adjacent spaces
form a single object. The standard ASCII space (0x20) and all of the
Unicode characters marked "WS;<compat> 0020" are counted as white space.
Unless a white space object is the first in the paragraph, its view is
marked for suppression by the view flow code.

Contiguous non-white space characters are grouped into single objects,
and their views are not suppressed.

All text object views (both white space and "word") have their data
pointer set to the psg_text_t object representing the text for that
view. This should be suitable for simple text-mode unattributed display.
More advanced rendering would probably want to create suitable objects
and set the view data pointers to those objects.

No assumption is made about text direction.

Passage and paragraph views need to have their primary axis sizes set
appropriately, as well as their resize flags. Their xlen and ylen are
both set to 10, and xpos,ypos is 0,0. Paragraph views need their
setgeometry pointer set to the appropriate view_flow_* function.
However, they are set up to have their secondary axis set automatically
when flowed.

Text object views are set up for automatic flowing: grav_flow, 0,0 for
xpos,ypos. However, xlen and ylen are also both 0, so need to be set by
the renderer before attempting to flow the text.
2022-09-30 19:51:14 +09:00