With no apologies to CTxCB for the title.
My mission: to feed SSCI, ScummVM, SV, and SCI Companion strange font resources.
First, I generated a font resource based on
Fixedsys Excelsior containing 1024 characters, because all three header fields in a font resource are 16-bit values. All four programs can load the result (attached), though SCI Companion's all "what matter of bassoonery is this" and clamps it to 256. SV just blindly tries to draw all 1024 characters and runs out of screen space, and the interpreters are happily unable to actually
use any character >255.
Next up is the
lowChar value. Across 500+ font files I've checked, all of them have a
lowChar of zero. This is
not the index of the first character in the font proper! None of the four actually
care about this value, except for one spot in SSCI: the character being drawn must be
>= lowChar and
< highChar. As such, if you were to set it to
0x61 'a', SSCI will stop drawing any capitals, digits, and most symbols in that font.
If
highChar is effectively
numChar, that explains why SSCI does care about that. Remember that time I made AGI draw extended ASCII characters and
it went off the rails? Giving a translation of let's say KQ5 the font(s) from the US version, the extended ASCII characters are simply skipped. But if you take a 128-character font and change its
highChar to 256 (or 226, more popular number), SSCI will happily mistake the first 100-something characters' data for offsets to the high moby's characters, follow them, and draw... it depends, I suppose. I expected more dramatic results than this but when I tried it I got a few dots where the high characters would go. ScummVM catches an access violation and pops the debugger, SV crashes like a normal Windows application, and SCI Companion resets the font to 128 8x8 blanks.
If you write down your results, it's science. If you don't, you're just fucking around.
