i'm making myself a little toolkit on top of pygame to make simple games relatively quickly. today's unnecessary and possibly overcomplicated feature: hand-rolled VWF text using bitmap fonts
typesetting pixel fonts isn't my forte but the code itself works exactly the way i envisioned
(you don't actually need to send me five dollars)
@typhlosion VWF text is not too bad
But VWF automatic word wrapping, that's a pain
@Triplefox im not even gonna try to do automatic word wrap, at least not at the moment. that, at least, i can recognize as overkill for this project at this time
i don't foresee it being tooooo much of a problem, though. since i'm not doing dynamic kerning or anything, in theory it'd just be a bunch of careful addition with some rules about where splits can happen
@typhlosion It's one where it's juuust complicated enough that you get bit by weird off-by-ones and desynchronization between when the word breaks and when the line breaks. I believe the best way right now for the basic greedy algorithm is:
1. Precompute word sizes
2. Now render one word at a time, checking for the end of line.
3. If word is wider than width of line, render one character at a time to line-wrap it.
4. If word is thinner than width of line but wider than remaining space, linebreak and continue.
@Triplefox yeah my envisioning was to do that but only precalculate for one word at a time (i.e. at the moments when you'd want to decide whether to linebreak or not anyway)
@Triplefox i dont think im gonna use this for much outside of like, dialog boxes and certain ui elements, so i dont think i need to worry too much about fanciness
@typhlosion there are a lot of additional features that can lead to precomputing. Like, I think I had one where there were specific words that the player could change with a cursor, and this made the paragraph move around jarringly when the word changes.
But yeah, rendering can get as complex as you want, especially with stuff like text. I am now making a system that is monospace linewrapped instead.