VVVVVV 2.2 only supported displaying characters 00-7F with its font system. VVVVVV 2.3 added support for unicode, by supplying a font.txt with all the characters that are in the font image. But 2.3 made another change that I didn't immediately realize, even after reading the code: if font.txt is not present, then the font is not assumed to have only 00-7F, but all of unicode, as far as the image dimensions allow.
However, an inconsistency I did notice is how unknown characters would be rendered in 2.3. If a font had a font.txt, then any unknown characters would be shown as a '?'. If a font had no font.txt however, then suddenly any unknown characters would just come out as a space. I fixed this behavior with the new font system; but what was actually happening for characters to come out blank is that characters up to U+00FF, which were technically in the font image but as fully transparent, would be shown as they were in the image, and characters beyond U+00FF wouldn't be shown since they were outside of the image.
I don't really want to show blank characters for any character between 80-FF if it is technically inside the image, because pretty much every single ASCII-only font.png in existence (including the one in data.zip) contains a blank lower half, just because the font in the game had always had this specific resolution. (We didn't want to do things that might crash the game because something was different from what it expected...)
We have had some confusing occasions before with the old behavior where the fonts weren't correctly packaged or something (like when the Catalan translator was sent the first version of the translator pack, or when people customize their fonts wrong) and special characters were just blank spaces.
This situation is unwanted:
So, instead, for characters beyond 7F, I decided to consider them part of the font, as long as they are not blank. That means, if a character beyond the ASCII range has any (non-alpha-0) pixels, then it will be added, otherwise it won't be. This is just to handle legacy fonts, and the case where all fonts are missing and the one from data.zip is used; new fonts should just use .fontmeta or .txt to define their characters.
For comparison:
Legal Stuff:
By submitting this pull request, I confirm that...
[x] My changes may be used in a future commercial release of VVVVVV
[x] I will be credited in a CONTRIBUTORS file and the "GitHub Friends"
section of the credits for all of said releases, but will NOT be compensated
for these changes
Changes:
VVVVVV 2.2 only supported displaying characters 00-7F with its font system. VVVVVV 2.3 added support for unicode, by supplying a font.txt with all the characters that are in the font image. But 2.3 made another change that I didn't immediately realize, even after reading the code: if font.txt is not present, then the font is not assumed to have only 00-7F, but all of unicode, as far as the image dimensions allow.
However, an inconsistency I did notice is how unknown characters would be rendered in 2.3. If a font had a font.txt, then any unknown characters would be shown as a '?'. If a font had no font.txt however, then suddenly any unknown characters would just come out as a space. I fixed this behavior with the new font system; but what was actually happening for characters to come out blank is that characters up to U+00FF, which were technically in the font image but as fully transparent, would be shown as they were in the image, and characters beyond U+00FF wouldn't be shown since they were outside of the image.
I don't really want to show blank characters for any character between 80-FF if it is technically inside the image, because pretty much every single ASCII-only font.png in existence (including the one in data.zip) contains a blank lower half, just because the font in the game had always had this specific resolution. (We didn't want to do things that might crash the game because something was different from what it expected...)
We have had some confusing occasions before with the old behavior where the fonts weren't correctly packaged or something (like when the Catalan translator was sent the first version of the translator pack, or when people customize their fonts wrong) and special characters were just blank spaces.
This situation is unwanted:
So, instead, for characters beyond 7F, I decided to consider them part of the font, as long as they are not blank. That means, if a character beyond the ASCII range has any (non-alpha-0) pixels, then it will be added, otherwise it won't be. This is just to handle legacy fonts, and the case where all fonts are missing and the one from data.zip is used; new fonts should just use .fontmeta or .txt to define their characters.
For comparison:
Legal Stuff:
By submitting this pull request, I confirm that...
CONTRIBUTORSfile and the "GitHub Friends" section of the credits for all of said releases, but will NOT be compensated for these changes