You are right about a few things, though the key is that Raylib is what's creating the polygon (after I parse the text file into a sequence) and ideally I don't handle face/mesh creation myself (at low-level). Maybe eventually.
what you mean by color index face hints
For additional context on where faces are.
I've mentioned vertex color (ideal as face colors), but I probably do want to handle a 3-digit-hex color palette with object-library-wide management.
here's what I was thinking with verts no longer numbered (instead E for external, C for corner. even-odd might work better in some cases), index numbers as hints and for color
Each arm would be its own color
#values: matrix_xres matrix_yres target_size vert_num
#IDEA, fails with heart as there is only 1 corner vertex
32
32
160.0
11
E
1
E2 C C 3E
1
2@3
4 5
C C
C
4 5
E E
The reason I'm thinking about this is that it would be better to have one way to define verts. triangle_strip can generally do more (shapes with no central point) than triangle_fan, though I think the star here is the sort-of-thing that a single triangle_strip cannot do. That, and with numbering it only allows 62 verts (0..9, a..z, A..Z), and is a bit clunky to iterate on. Numbering, especially with a strip, is also a lot more complex as you get more verts. If I got to the point of making my own editor*, I might abstract this away so the user only works with points.
Use-in-code-wise I may have already solved fan-vs-strip with a function that just compares the values of the first few points to choose draw type, though I wasn't confident in that as it'd require a lot more testing. Might be better to store that in an enum as well.
* I wasn't quite sure of using what I already made for anything more than a simple arcade-like game, so that sort of kills motivation, needing to do even more technical work just to get visible results.