Open OnlineCop opened 2 years ago
When looking over the font system, sfonts
appears to be only digits 0..9 while kfonts
appears to be ASCII [0x20..0x79] plus a handful of codepoints.
misc.png
.eFont
enum to determine which to draw.sfonts[0]
is white text with a blue shadowsfonts[1..4]
are recolored to be red/yellow/green/grey text with the same blue shadow.0
..9
(only digits).eFontColor
enum to determine which to draw.kfonts[0..4]
are solid-color (white, red, yellow, green, grey) 8x8 glyphs with a black shadow.kfonts[5]
are multi-colored gold 8x8 glyphs with a blue shadow.kfonts[6]
are solid-color white 8x12 glyphs with a black shadow.kfonts[0..4]
have modified some of the characters:
<
became a "left arrow" glyph>
became a "right arrow" glyph@
became a "down arrow" or "down chevron" glyph^
became an "x" (like the math symbol for multiply) glyphkfonts[5]
(gold) and kfonts[6]
(tall white) appear to keep the original font values.As far as the structure of the struct goes, we'd need to track which glyphs it contains, and most likely a copy of a Raster*
object so we can remove the dependency of the sfonts
/kfonts
globals.
Functions like KDraw::print_font()
(prints all glyphs from kfonts
) and KDraw::print_num()
(prints digits only from sfonts
) may need to be able to handle when an index is outside the range of the font's glyphs. In those cases, I don't think they should abort the game. They should remove the invalid character (shortening the word) or substitute another glyph in its place to indicate that it can't be rendered.
That would mean that, assuming 'X' here is an unknown or out-of-range value, "abXcXd" could be rendered as:
On the other hand, all the text shown in the game comes from within the game, so if we've put in some un-displayable code points I'd rather we knew as soon as possible rather than risk them going undetected.
It might become necessary to switch to using real fonts, so the gettext()
-translated strings can actually render properly in all of the target languages.
When someone localizes our _(...)
wrapped text with PO files, I fear that the characters not explicitly added to the glyphs lookup will cause issues.
We should have a class/struct for fonts and either blend or remove one/both of the
eFont
/eFontColor
enums. If we have astd::map
orstd::vector
of fonts, the enum values could still be used to indicate which font we're after.The struct should include the font dimensions (height, width) since these are monospaced fonts, and possibly color (or at least an index value within
pal[]
if we're wanting to recolor them).KDraw::print_font()
typically multiplies the font width by some offset, and I'd like to replace those Magic Number multiplications (* 8
) with* font.width()
or something similar.This should also make it easier to extend the fonts in the future, in support of localization in case the current
fonts.png
doesn't contain all the necessary characters.