mpo/VVVVVV
1
0
Fork 0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-11-05 02:39:41 +01:00
Code Issues Releases Wiki Activity
VVVVVV/desktop_version/src/Font.cpp

1482 lines
37 KiB
C++
Raw Normal View History

Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "Font.h"
#include <tinyxml2.h>
#include "Alloc.h"
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
#include "Constants.h"
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
#include "CustomLevels.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "FileSystemUtils.h"
Implement bidi reordering at display time I'm now using SheenBidi to reorder RTL and bidirectional text properly at text rendering time! For Arabic this is still missing reshaping, but everything's looking really promising now! The code changes are really non-invasive. The changes to Font.cpp are absolutely minimal: 1305+ if (bidi_should_transform(text)) 1306+ { 1307+ text = bidi_transform(text); 1308+ } There's now a FontBidi.cpp, which implements these two functions, notably bidi_transform(), which takes a UTF-8 encoded string and returns another UTF-8 encoded string that has bidi reorderings and reshapings applied. In that function, SheenBidi gives us information about where in the input string runs start and end, and on a basic level, all we need to do there is to concatenate the parts together in the order that we're given them, and to reverse the RTL runs (recognizable by odd levels). As this is a proof-of-concept, bidi_should_transform() still always returns true, applying the bidi algorithm to all languages and all strings. I'm thinking of enabling bidi only when the language/font metadata enables RTL (which could be for the interface or for a custom level), or outside of that, at least when RTL characters are detected (such as Arabic or Hebrew Unicode blocks).
2024-01-02 03:57:26 +01:00
#include "FontBidi.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "Graphics.h"
Place GraphicsResources functions in header file These are functions used in other files that are not on the GraphicsResources class but are implemented inside the GraphicsResources.cpp file. For some reason they were never put in the GraphicsResources.h file until now, even though it's a perfectly good header file to put them in.
2024-01-10 01:03:05 +01:00
#include "GraphicsResources.h"
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
#include "GraphicsUtil.h"
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
#include "Localization.h"
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
#include "UTF8.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "UtilityClass.h"
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
#include "Vlogging.h"
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
#include "XMLUtils.h"
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
extern "C"
{
#include <c-hashmap/map.h>
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
namespace font
{
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
#define GLYPH_EXISTS 0x1
#define GLYPH_COLOR 0x2
struct GlyphInfo
{
uint16_t image_idx;
uint8_t advance;
uint8_t flags;
};
/* Codepoints go up to U+10FFFF, so we have 0x110 (272) pages
* of 0x1000 (4096) glyphs, allocated as needed */
#define FONT_N_PAGES 0x110
#define FONT_PAGE_SIZE 0x1000
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
enum FontType
{
FontType_FONT,
FontType_BUTTONS
};
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
struct Font
{
char name[64];
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
char display_name[SCREEN_WIDTH_CHARS + 1];
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
FontType type;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
uint8_t glyph_w;
uint8_t glyph_h;
SDL_Texture* image;
GlyphInfo* glyph_page[FONT_N_PAGES];
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
char fallback_key[64];
uint8_t fallback_idx;
bool fallback_idx_valid;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
};
struct FontContainer
{
uint8_t count;
Font* fonts;
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
hashmap* map_name_idx;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
};
struct PrintFlags
{
uint8_t scale;
Font* font_sel;
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a) There used to be two ways of fading in/out text in VVVVVV: - Local code that modifies the R, G and B values of the text - Keeping the RGB values the same and using the alpha channel The latter approach is only used once, for [Press ENTER to return to editor]. The former approach causes problems with colored (button) glyphs: there's no way for the print function to tell from the RGB values whether a color is "full Viridian-cyan" or "Viridian-cyan faded out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the print function that the color brightness is reduced to match the brightness of colored glyphs to the brightness of the rest of the text. However, there were already plans to make the single use of alpha consistent with the rest of the game and the style, so PR_ALPHA(value) could be removed, as well as the bit signifying whether the brightness or alpha value is used. For the editor text, I simply copied the "Press {button} to teleport" behavior of hiding the text completely if it becomes darker than 100/255. Another simplification is to make the print function handle not just the brightness of the color glyphs while local code handled the brightness of the normal text color, but to make the print function handle both. That way, the callsite can simply pass in the full colors and the brightness flag, and the flag name can be made a lot simpler as well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
uint8_t brightness;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
bool border;
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
bool full_border;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
bool align_cen;
bool align_right;
bool cjk_low;
bool cjk_high;
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
bool rtl;
Add PR_RTL_XFLIP print flag This lets you mirror the X axis specifically in RTL languages, so the left border is 320 and the right border is 0, and invert the meaning of PR_LEFT (0) and PR_RIGHT. Most of the time this is not necessary, it's just for stuff where a label is followed by a different print, like "Font: " followed by the font name, time trial time displays, etc
2024-01-03 22:21:37 +01:00
bool rtl_xflip;
Clean up Font.h, move structs into Font.cpp None of the structs in the new font system ended up being "publicly" accessible, they were all treated as implementation details for Font.cpp to use, so these structs are now fully defined in Font.cpp only.
2023-01-18 23:13:35 +01:00
};
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
static FontContainer fonts_main = {};
static FontContainer fonts_custom = {};
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
static uint8_t font_idx_8x8 = 0;
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
uint8_t font_idx_options_n = 0;
uint8_t font_idx_options[20];
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
static bool font_level_is_interface = false;
Properly fix setfont/setrtl in between text boxes There used to be a problem with the setfont and setrtl script commands. Namely, if you used them in between text boxes naïvely, without any careful thought, then the fading out text box would suddenly gain the font of the new one. A kludge solution to this was implemented by simply blocking the script until the existing text box faded out before switching the font or RTL, and shipped for 2.4.0. However, a better solution is to simply bake the font flags in to the text box, so that way, if the level font switches, then the text box keeps its font. This is only for custom levels, because in the main game, the font in a text box needs to be able to change depending on language. But it seems like custom level translations weren't much on the roadmap, and so even the existing hack didn't support changing the font based on translation (even though translation of custom level cutscenes is supported). So baking the font flags into the text box here doesn't make things any worse. It also makes things better, arguably, by allowing multiple text boxes to exist on screen at once with different fonts. Maybe in the future we'll need a flag that specifies that the font should change depending on language if a translation in said language exists for the text box, or something like that. For people that want to override the fonts of every existing text box on screen, you can specify "all" as the second parameter of setfont or setrtl to do so.
2024-01-22 07:09:35 +01:00
bool font_idx_level_is_custom = false;
uint8_t font_idx_level = 0;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
static void codepoint_split(
const uint32_t codepoint,
short* page,
short* glyph
)
{
// Splits a code point (0x10FFFF) into page (0x10F) and glyph (0xFFF)
if (codepoint > 0x10FFFF)
{
codepoint_split(0xFFFD, page, glyph);
return;
}
*page = codepoint >> 12;
*glyph = codepoint % FONT_PAGE_SIZE;
}
static GlyphInfo* get_glyphinfo(
const Font* f,
const uint32_t codepoint
)
{
short page, glyph;
codepoint_split(codepoint, &page, &glyph);
if (f->glyph_page[page] == NULL)
{
return NULL;
}
return &f->glyph_page[page][glyph];
}
static void add_glyphinfo(
Font* f,
const uint32_t codepoint,
const int image_idx
)
{
if (image_idx < 0 || image_idx > 65535)
{
return;
}
short page, glyph;
codepoint_split(codepoint, &page, &glyph);
if (f->glyph_page[page] == NULL)
{
f->glyph_page[page] = (GlyphInfo*) SDL_calloc(FONT_PAGE_SIZE, sizeof(GlyphInfo));
if (f->glyph_page[page] == NULL)
{
return;
}
}
f->glyph_page[page][glyph].image_idx = image_idx;
f->glyph_page[page][glyph].advance = f->glyph_w;
f->glyph_page[page][glyph].flags = GLYPH_EXISTS;
}
static bool glyph_is_valid(const GlyphInfo* glyph)
{
return glyph->flags & GLYPH_EXISTS;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
static Font* fallback_for(const Font* f)
{
if (!f->fallback_idx_valid)
{
return NULL;
}
return &fonts_main.fonts[f->fallback_idx];
}
static GlyphInfo* find_glyphinfo(const Font* f, const uint32_t codepoint, const Font** f_glyph)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
/* Get the GlyphInfo for a specific codepoint, or <?> or ? if it doesn't exist.
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
* f_glyph may be either set to f (the main specified font) or its fallback font, if it exists.
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
* As a last resort, may return NULL. */
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
*f_glyph = f;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
GlyphInfo* glyph = get_glyphinfo(f, codepoint);
if (glyph != NULL && glyph_is_valid(glyph))
{
return glyph;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
Font* f_fallback = fallback_for(f);
if (f_fallback != NULL && (glyph = get_glyphinfo(f_fallback, codepoint)) != NULL && glyph_is_valid(glyph))
{
*f_glyph = f_fallback;
return glyph;
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
glyph = get_glyphinfo(f, 0xFFFD);
if (glyph != NULL && glyph_is_valid(glyph))
{
return glyph;
}
glyph = get_glyphinfo(f, '?');
if (glyph != NULL && glyph_is_valid(glyph))
{
return glyph;
}
return NULL;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
static int get_advance_ff(const Font* f, const Font* f_glyph, const GlyphInfo* glyph)
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
/* Internal function - get the correct advance after we have
* determined whether the glyph is from the fallback font or not. */
if (glyph == NULL)
Start using level-specific font where needed, make CJK tweaks Level text such as room names, text box content, and the contents of the script editor need to be displayed in the level-specific font, and tweaked to look right. This involves displaying less lines in the script editor, making text boxes bigger, displaying some text higher and some text lower. This is still unfinished, but it's the real start of a migration to font::print functions!
2023-01-12 05:27:52 +01:00
{
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
return f->glyph_w;
Start using level-specific font where needed, make CJK tweaks Level text such as room names, text box content, and the contents of the script editor need to be displayed in the level-specific font, and tweaked to look right. This involves displaying less lines in the script editor, making text boxes bigger, displaying some text higher and some text lower. This is still unfinished, but it's the real start of a migration to font::print functions!
2023-01-12 05:27:52 +01:00
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
/* If the glyph is a fallback glyph, center it relative to the main font
* instead of trusting the fallback's width */
if (f_glyph != f)
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
return f->glyph_w;
}
return glyph->advance;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
int get_advance(const Font* f, const uint32_t codepoint)
{
// Get the width of a single character in a font
if (f == NULL)
{
return 8;
}
const Font* f_glyph;
GlyphInfo* glyph = find_glyphinfo(f, codepoint, &f_glyph);
return get_advance_ff(f, f_glyph, glyph);
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
static bool decode_xml_range(tinyxml2::XMLElement* elem, unsigned* start, unsigned* end)
{
// We do support hexadecimal start/end like "0x10FFFF"
if (elem->QueryUnsignedAttribute("start", start) != tinyxml2::XML_SUCCESS
|| elem->QueryUnsignedAttribute("end", end) != tinyxml2::XML_SUCCESS
|| *end < *start || *start > 0x10FFFF
)
{
return false;
}
*end = SDL_min(*end, 0x10FFFF);
return true;
}
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
static uint8_t load_font(FontContainer* container, const char* name)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
if (container->count >= 254)
{
return 0;
}
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
Font* new_fonts = (Font*) SDL_realloc(container->fonts, sizeof(Font)*(container->count+1));
if (new_fonts == NULL)
{
return 0;
}
container->fonts = new_fonts;
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
uint8_t f_idx = container->count++;
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
Font* f = &container->fonts[f_idx];
vlog_info("Loading font \"%s\"...", name);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
char name_png[256];
char name_txt[256];
char name_xml[256];
SDL_snprintf(name_png, sizeof(name_png), "graphics/%s.png", name);
SDL_snprintf(name_txt, sizeof(name_txt), "graphics/%s.txt", name);
SDL_snprintf(name_xml, sizeof(name_xml), "graphics/%s.fontmeta", name);
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
SDL_strlcpy(f->name, name, sizeof(f->name));
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
SDL_strlcpy(f->display_name, name, sizeof(f->display_name));
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
f->type = FontType_FONT;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
f->glyph_w = 8;
f->glyph_h = 8;
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
f->fallback_key[0] = '\0';
f->fallback_idx_valid = false;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
bool white_teeth = false;
tinyxml2::XMLDocument doc;
tinyxml2::XMLHandle hDoc(&doc);
tinyxml2::XMLElement* pElem;
bool xml_loaded = false;
if (FILESYSTEM_areAssetsInSameRealDir(name_png, name_xml)
&& FILESYSTEM_loadAssetTiXml2Document(name_xml, doc)
)
{
xml_loaded = true;
hDoc = hDoc.FirstChildElement("font_metadata");
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
if ((pElem = hDoc.FirstChildElement("display_name").ToElement()) != NULL)
{
SDL_strlcpy(f->display_name, pElem->GetText(), sizeof(f->display_name));
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
if ((pElem = hDoc.FirstChildElement("type").ToElement()) != NULL)
{
if (SDL_strcmp(pElem->GetText(), "buttons") == 0)
{
f->type = FontType_BUTTONS;
}
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
if ((pElem = hDoc.FirstChildElement("width").ToElement()) != NULL)
{
f->glyph_w = help.Int(pElem->GetText());
}
if ((pElem = hDoc.FirstChildElement("height").ToElement()) != NULL)
{
f->glyph_h = help.Int(pElem->GetText());
}
if ((pElem = hDoc.FirstChildElement("white_teeth").ToElement()) != NULL)
{
// If 1, we don't need to whiten the entire font (like in old versions)
white_teeth = help.Int(pElem->GetText());
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
if ((pElem = hDoc.FirstChildElement("fallback").ToElement()) != NULL)
{
SDL_strlcpy(f->fallback_key, pElem->GetText(), sizeof(f->fallback_key));
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
f->image = LoadImage(name_png, white_teeth ? TEX_COLOR : TEX_WHITE);
SDL_zeroa(f->glyph_page);
if (f->image == NULL)
{
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
return f_idx;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
/* We may have a 2.3-style font.txt with all the characters.
* font.txt takes priority over <chars> in the XML.
* If neither exist, it's just ASCII. */
bool charset_loaded = false;
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
bool special_loaded = false;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
unsigned char* charmap = NULL;
Fix loading font .txt files that contain null bytes An example is Maximally Misleading Miserable Misadventure, which has a font.txt which includes all ASCII characters starting with a 0x00 byte. This would accidentally null-terminate the string too early. Instead, we now use the total length of the file again, and keep getting the next UTF-8 codepoint until the file ends. We still need to null-terminate it - it protects against incomplete sequences getting the UTF-8 decoder to read out of bounds.
2023-03-16 21:45:25 +01:00
size_t length;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
if (FILESYSTEM_areAssetsInSameRealDir(name_png, name_txt))
{
Fix loading font .txt files that contain null bytes An example is Maximally Misleading Miserable Misadventure, which has a font.txt which includes all ASCII characters starting with a 0x00 byte. This would accidentally null-terminate the string too early. Instead, we now use the total length of the file again, and keep getting the next UTF-8 codepoint until the file ends. We still need to null-terminate it - it protects against incomplete sequences getting the UTF-8 decoder to read out of bounds.
2023-03-16 21:45:25 +01:00
/* The .txt can contain null bytes, but it's still null-terminated - it protects
* against incomplete sequences getting the UTF-8 decoder to read out of bounds. */
Always add null terminator when loading files This removes the `addnull` argument from `FILESYSTEM_loadFileToMemory` and `FILESYSTEM_loadAssetToMemory`, and makes it so a null terminator is always appended no matter what. This simplifies things and removes the need for callers to make the decision about null termination and what its implications are. Then you get cases where null termination might not happen when it should be, such as the one df577c59ef16df8893e0628559de1b304e84b951 (#947) fixed. When FIQ added the `addnull` argument in 5862af4445bfd9c056de7ef9694f8cb31f9d469a (#117), I'm guessing he did it because he wanted to be cautious about adding the null terminator to every file, so he only did it for XML files, which was the only case needed at the time. But really, there's no downsides to always appending a null terminator. In fact, it's already always done whenever the STDIN buffer is loaded.
2023-03-18 23:12:24 +01:00
FILESYSTEM_loadAssetToMemory(name_txt, &charmap, &length);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
if (charmap != NULL)
{
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
// We have a .txt! It's an obsolete system, but it takes priority if the file exists.
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
const char* current = (char*) charmap;
Fix loading font .txt files that contain null bytes An example is Maximally Misleading Miserable Misadventure, which has a font.txt which includes all ASCII characters starting with a 0x00 byte. This would accidentally null-terminate the string too early. Instead, we now use the total length of the file again, and keep getting the next UTF-8 codepoint until the file ends. We still need to null-terminate it - it protects against incomplete sequences getting the UTF-8 decoder to read out of bounds.
2023-03-16 21:45:25 +01:00
const char* end = (char*) charmap + length;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
int pos = 0;
Fix loading font .txt files that contain null bytes An example is Maximally Misleading Miserable Misadventure, which has a font.txt which includes all ASCII characters starting with a 0x00 byte. This would accidentally null-terminate the string too early. Instead, we now use the total length of the file again, and keep getting the next UTF-8 codepoint until the file ends. We still need to null-terminate it - it protects against incomplete sequences getting the UTF-8 decoder to read out of bounds.
2023-03-16 21:45:25 +01:00
while (current < end)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Fix loading font .txt files that contain null bytes An example is Maximally Misleading Miserable Misadventure, which has a font.txt which includes all ASCII characters starting with a 0x00 byte. This would accidentally null-terminate the string too early. Instead, we now use the total length of the file again, and keep getting the next UTF-8 codepoint until the file ends. We still need to null-terminate it - it protects against incomplete sequences getting the UTF-8 decoder to read out of bounds.
2023-03-16 21:45:25 +01:00
uint32_t codepoint = UTF8_next(&current);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
add_glyphinfo(f, codepoint, pos);
++pos;
}
VVV_free(charmap);
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
charset_loaded = true;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
if (xml_loaded && !charset_loaded && (pElem = hDoc.FirstChildElement("chars").ToElement()) != NULL)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
// <chars> in the XML is the preferred system.
int pos = 0;
tinyxml2::XMLElement* subElem;
FOR_EACH_XML_SUB_ELEMENT(pElem, subElem)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
EXPECT_ELEM(subElem, "range");
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
unsigned start, end;
if (!decode_xml_range(subElem, &start, &end))
{
continue;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
for (uint32_t codepoint = start; codepoint <= end; codepoint++)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
add_glyphinfo(f, codepoint, pos);
++pos;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
}
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
charset_loaded = true;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
if (!charset_loaded)
{
/* If we don't have font.txt and no <chars> tag either,
Load plain font.png beyond U+007F 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. 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.
2023-12-07 18:02:43 +01:00
* this font is 2.2-and-below-style plain ASCII.
* Or well... 2.3 interpreted these as
* "all unicode from 0 to however much is in the image"... */
SDL_Surface* temp_surface = LoadImageSurface(name_png);
if (temp_surface != NULL)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Load plain font.png beyond U+007F 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. 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.
2023-12-07 18:02:43 +01:00
const uint32_t chars_per_line = temp_surface->w / f->glyph_w;
const uint32_t max_codepoint = (temp_surface->h / f->glyph_h) * chars_per_line;
Fix loading plain font.png Unicode indexing out of bounds This code was introduced by Dav999 in abf12632bbc1e310753591289927180e940f9ae2 (PR #1077), but it contains a memory error. I spotted this with Valgrind. The problem comes from the fact that `max_codepoint` is calculated from the width and height of the surface (which will have the same width and height as the source `font.png` from the filesystem). Let's work through an example using a typical 128 by 128 `font.png` and an 8 by 8 glyph. `chars_per_line` is calculated by dividing the width of the image (`temp_surface->w`, or 128) by `f->glyph_w` (8), yielding 16. `max_codepoint` is calculated by first calculating the height of the image divided by the height of the glyph - which here just happens to be the same as `chars_per_line` (16) since we have a square `font.png` - and then multiplying the result by `chars_per_line`. 16 times 16 is 256. Now it is important to recognize here that this is the _amount_ of glyphs in `font.png`. It is _not_ the last codepoint in the image. To see why, consider the fact that codepoint 0 is contained in the image. If we have codepoint 0, then we can't have codepoint 256, because that would imply that we have 257 codepoints, but clearly, we don't. If we try to read codepoint 256, then after working through the calculations to read the glyphs, we would be trying to read from pixel columns 0 through 7 and pixel rows 128 through 135... in a 128 by 128 image... which is clearly incorrect. Therefore, it's incorrect to write the upper bound of the for-loop iterating over every codepoint as `codepoint <= max_codepoint` instead of `codepoint < max_codepoint`.
2023-12-29 20:37:01 +01:00
for (uint32_t codepoint = 0x00; codepoint < max_codepoint; codepoint++)
Load plain font.png beyond U+007F 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. 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.
2023-12-07 18:02:43 +01:00
{
if (codepoint > 0x7F)
{
/* Only include characters with actual pixels...
* If the font.png is too big (normally it is) we _want_ question marks. */
const int glyph_x = (codepoint % chars_per_line) * f->glyph_w;
const int glyph_y = (codepoint / chars_per_line) * f->glyph_h;
bool found_pixel = false;
for (int pixel_y = 0; pixel_y < f->glyph_h; pixel_y++)
{
for (int pixel_x = 0; pixel_x < f->glyph_w; pixel_x++)
{
if (ReadPixel(temp_surface, glyph_x+pixel_x, glyph_y+pixel_y).a > 0)
{
found_pixel = true;
goto no_more_pixels;
}
}
}
no_more_pixels:
if (!found_pixel)
{
// Do not add it
continue;
}
}
add_glyphinfo(f, codepoint, codepoint);
}
VVV_freefunc(SDL_FreeSurface, temp_surface);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
Improve ordering of font charset loading Even though it would be a bizarre combination, declaring no character set (neither via <chars> nor via font.txt) meant that <special> couldn't be used because the ASCII fallback charset would be loaded after special ranges were processed. Now, all the methods of loading the charset are attempted sequentially, and only afterwards, the special ranges are loaded.
2023-02-02 23:22:24 +01:00
if (xml_loaded && (pElem = hDoc.FirstChildElement("special").ToElement()) != NULL)
{
tinyxml2::XMLElement* subElem;
FOR_EACH_XML_SUB_ELEMENT(pElem, subElem)
{
EXPECT_ELEM(subElem, "range");
unsigned start, end;
if (!decode_xml_range(subElem, &start, &end))
{
continue;
}
int advance = subElem->IntAttribute("advance", -1);
int color = subElem->IntAttribute("color", -1);
for (uint32_t codepoint = start; codepoint <= end; codepoint++)
{
GlyphInfo* glyph = get_glyphinfo(f, codepoint);
if (glyph == NULL)
{
continue;
}
if (advance >= 0 && advance < 256)
{
glyph->advance = advance;
}
if (color == 0)
{
glyph->flags &= ~GLYPH_COLOR;
}
else if (color == 1)
{
glyph->flags |= GLYPH_COLOR;
}
}
}
special_loaded = true;
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
if (!special_loaded && f->glyph_w == 8 && f->glyph_h == 8)
{
/* If we don't have <special>, and the font is 8x8,
* 0x00-0x1F will be less wide because that's how it has always been. */
for (uint32_t codepoint = 0x00; codepoint < 0x20; codepoint++)
{
GlyphInfo* glyph = get_glyphinfo(f, codepoint);
if (glyph != NULL)
{
glyph->advance = 6;
}
}
}
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
return f_idx;
}
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
static bool find_font_by_name(FontContainer* container, const char* name, uint8_t* idx)
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
// Returns true if font found (and idx is set), false if not found
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
if (container->map_name_idx == NULL)
{
// No fonts yet...
return false;
}
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
uintptr_t i;
Remove key casts from hashmap function calls We don't need the (char*) or (void*) casts anymore. You may need to `git submodule update --init`.
2023-03-05 21:42:21 +01:00
if (hashmap_get(container->map_name_idx, name, SDL_strlen(name), &i))
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
*idx = i;
return true;
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
}
return false;
}
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
bool find_main_font_by_name(const char* name, uint8_t* idx)
{
return find_font_by_name(&fonts_main, name, idx);
}
uint8_t get_font_idx_8x8(void)
{
return font_idx_8x8;
}
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
bool level_font_is_main_idx(const uint8_t idx)
{
return !font_idx_level_is_custom && font_idx_level == idx;
}
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
void set_level_font(const char* name)
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
/* Apply the choice for a certain level-specific font.
* This function is for custom levels. */
font_level_is_interface = false;
Start using level-specific font where needed, make CJK tweaks Level text such as room names, text box content, and the contents of the script editor need to be displayed in the level-specific font, and tweaked to look right. This involves displaying less lines in the script editor, making text boxes bigger, displaying some text higher and some text lower. This is still unfinished, but it's the real start of a migration to font::print functions!
2023-01-12 05:27:52 +01:00
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
if (find_font_by_name(&fonts_custom, name, &font_idx_level))
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
font_idx_level_is_custom = true;
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
}
else
{
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
font_idx_level_is_custom = false;
if (!find_font_by_name(&fonts_main, name, &font_idx_level))
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
Allow levels to select a font via XML, show correct font in levels list There still needs to be a menu for selecting a font, but it can now be loaded and saved correctly in the XML!
2023-01-20 03:56:17 +01:00
if (SDL_strcmp(name, "font") != 0)
{
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
set_level_font("font");
Allow levels to select a font via XML, show correct font in levels list There still needs to be a menu for selecting a font, but it can now be loaded and saved correctly in the XML!
2023-01-20 03:56:17 +01:00
}
else
{
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
font_idx_level = font_idx_8x8;
Allow levels to select a font via XML, show correct font in levels list There still needs to be a menu for selecting a font, but it can now be loaded and saved correctly in the XML!
2023-01-20 03:56:17 +01:00
}
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
}
}
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
cl.rtl = SDL_strcmp(name, "font_ar") == 0; // FIXME: make different menu options for choosing LTR/RTL of the same font
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
}
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
void set_level_font_interface(void)
{
/* Set the level font equal to the interface font.
* This function is for the main game. */
font_level_is_interface = true;
}
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
void set_level_font_new(void)
{
/* Set the level font to the default font for new levels.
* This function is for starting the editor. */
font_level_is_interface = false;
font_idx_level_is_custom = false;
if (loc::new_level_font == "")
{
/* Just take the language's font
* (Japanese VVVVVV can make Japanese levels by default, etc) */
font_idx_level = loc::get_langmeta()->font_idx;
}
else
{
/* If the user has changed the font (wants to make levels
* for a different userbase) then remember that choice. */
if (!find_main_font_by_name(loc::new_level_font.c_str(), &font_idx_level))
{
font_idx_level = font_idx_8x8;
}
}
cl.level_font_name = get_main_font_name(font_idx_level);
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
cl.rtl = cl.level_font_name == "font_ar"; // FIXME: make different menu options for choosing LTR/RTL of the same font
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
}
Fix possible dangling pointers in FontContainer.map_name_idx The hashmap would get populated with the name of each font, as each font was being added. Unfortunately, adding a font would also realloc the storage for fonts, in which the names are also stored... Possibly invalidating the pointers to the names. This is now fixed by populating the hashmap after all the fonts are added.
2023-03-04 01:29:19 +01:00
static void fill_map_name_idx(FontContainer* container)
{
/* Initialize the name->idx hashmap for the fonts in this container.
* This should only be done once, after all the fonts are added. */
container->map_name_idx = hashmap_create();
for (uint8_t i = 0; i < container->count; i++)
{
Font* f = &container->fonts[i];
hashmap_set(container->map_name_idx, f->name, SDL_strlen(f->name), i);
}
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
static void set_fallbacks(FontContainer* container)
{
/* Initialize the value of fallback_idx for all fonts in this container.
* Only main fonts can be fallback fonts. */
for (uint8_t i = 0; i < container->count; i++)
{
Font* f = &container->fonts[i];
if (find_main_font_by_name(f->fallback_key, &f->fallback_idx))
{
f->fallback_idx_valid = true;
}
}
}
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
static void load_font_filename(bool is_custom, const char* filename)
{
// Load font.png, and everything that matches *.fontmeta (but not font.fontmeta)
size_t expected_ext_start;
bool is_fontpng = SDL_strcmp(filename, "font.png") == 0;
if (is_fontpng)
{
expected_ext_start = SDL_strlen(filename)-4;
}
else
{
expected_ext_start = SDL_strlen(filename)-9;
}
if (is_fontpng || (endsWith(filename, ".fontmeta") && SDL_strcmp(filename, "font.fontmeta") != 0))
{
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
char font_name[64];
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
SDL_strlcpy(font_name, filename, sizeof(font_name));
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
font_name[SDL_min(63, expected_ext_start)] = '\0';
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
uint8_t f_idx = load_font(is_custom ? &fonts_custom : &fonts_main, font_name);
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
if (is_fontpng && !is_custom)
{
font_idx_8x8 = f_idx;
}
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
void load_main(void)
{
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
// Load all global fonts
EnumHandle handle = {};
const char* item;
while ((item = FILESYSTEM_enumerate("graphics", &handle)) != NULL)
{
load_font_filename(false, item);
}
FILESYSTEM_freeEnumerate(&handle);
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
font_idx_level = font_idx_8x8;
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
Fix possible dangling pointers in FontContainer.map_name_idx The hashmap would get populated with the name of each font, as each font was being added. Unfortunately, adding a font would also realloc the storage for fonts, in which the names are also stored... Possibly invalidating the pointers to the names. This is now fixed by populating the hashmap after all the fonts are added.
2023-03-04 01:29:19 +01:00
fill_map_name_idx(&fonts_main);
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
set_fallbacks(&fonts_main);
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
// Initialize the font menu options, 8x8 font first
font_idx_options[0] = font_idx_8x8;
font_idx_options_n = 1;
for (uint8_t i = 0; i < fonts_main.count; i++)
{
if (i == font_idx_8x8)
{
continue;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
if (fonts_main.fonts[i].type != FontType_FONT)
{
continue;
}
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
font_idx_options[font_idx_options_n++] = i;
if (font_idx_options_n >= sizeof(font_idx_options))
{
break;
}
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Allow levels to select a font via XML, show correct font in levels list There still needs to be a menu for selecting a font, but it can now be loaded and saved correctly in the XML!
2023-01-20 03:56:17 +01:00
void load_custom(const char* name)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Add font containers for global and custom fonts All global fonts and all custom fonts in a level are now loaded, and added to their respective "vectors". The selected font is still always as the global font.png, and the custom level font also isn't selected yet, but it's now easier to implement that. Also, I added FILESYSTEM_enumerateAssets, which #902 already has but I needed it now. I also rewrote it to not use std::vector<std::string>. That was my idea, it's also how FILESYSTEM_getLanguageCodes worked, so for symmetry, that function is getting changed as well.
2023-01-11 02:57:31 +01:00
// Load all custom (level-specific assets) fonts
unload_custom();
EnumHandle handle = {};
const char* item;
while ((item = FILESYSTEM_enumerateAssets("graphics", &handle)) != NULL)
{
load_font_filename(true, item);
}
FILESYSTEM_freeEnumerate(&handle);
Fix possible dangling pointers in FontContainer.map_name_idx The hashmap would get populated with the name of each font, as each font was being added. Unfortunately, adding a font would also realloc the storage for fonts, in which the names are also stored... Possibly invalidating the pointers to the names. This is now fixed by populating the hashmap after all the fonts are added.
2023-03-04 01:29:19 +01:00
fill_map_name_idx(&fonts_custom);
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
set_fallbacks(&fonts_custom);
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
set_level_font(name);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
void unload_font(Font* f)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
VVV_freefunc(SDL_DestroyTexture, f->image);
for (int i = 0; i < FONT_N_PAGES; i++)
{
VVV_free(f->glyph_page[i]);
}
}
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
void unload_font_container(FontContainer* container)
{
Add name->idx hashmap in FontContainer This makes find_font_by_name() not O(n). It's not really a big deal, because there won't be many fonts, but it'd make a function in the next commit (finding the given fallback font for each font by name) O(n^2). It's easy enough to add the hashmap.
2023-02-20 23:53:48 +01:00
VVV_freefunc(hashmap_free, container->map_name_idx);
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
for (uint8_t i = 0; i < container->count; i++)
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
{
unload_font(&container->fonts[i]);
}
VVV_free(container->fonts);
container->fonts = NULL;
container->count = 0;
}
void unload_custom(void)
{
// Unload all custom fonts
unload_font_container(&fonts_custom);
}
void destroy(void)
{
// Unload all fonts (main and custom) for exiting
unload_custom();
unload_font_container(&fonts_main);
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
static Font* container_get(FontContainer* container, uint8_t idx)
{
/* Get a certain font from the given container (with bounds checking).
* Does its best to return at least something,
* but if there are no fonts whatsoever, can return NULL. */
if (idx < container->count)
{
return &container->fonts[idx];
}
if (font_idx_8x8 < fonts_main.count)
{
return &fonts_main.fonts[font_idx_8x8];
}
if (fonts_main.count > 0)
{
return &fonts_main.fonts[0];
}
if (fonts_custom.count > 0)
{
return &fonts_custom.fonts[0];
}
return NULL;
}
Properly fix setfont/setrtl in between text boxes There used to be a problem with the setfont and setrtl script commands. Namely, if you used them in between text boxes naïvely, without any careful thought, then the fading out text box would suddenly gain the font of the new one. A kludge solution to this was implemented by simply blocking the script until the existing text box faded out before switching the font or RTL, and shipped for 2.4.0. However, a better solution is to simply bake the font flags in to the text box, so that way, if the level font switches, then the text box keeps its font. This is only for custom levels, because in the main game, the font in a text box needs to be able to change depending on language. But it seems like custom level translations weren't much on the roadmap, and so even the existing hack didn't support changing the font based on translation (even though translation of custom level cutscenes is supported). So baking the font flags into the text box here doesn't make things any worse. It also makes things better, arguably, by allowing multiple text boxes to exist on screen at once with different fonts. Maybe in the future we'll need a flag that specifies that the font should change depending on language if a translation in said language exists for the text box, or something like that. For people that want to override the fonts of every existing text box on screen, you can specify "all" as the second parameter of setfont or setrtl to do so.
2024-01-22 07:09:35 +01:00
static Font* fontsel_to_font(int sel, bool* rtl, bool custom)
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
{
/* Take font selection integer (0-31) and turn it into the correct Font
* 0: PR_FONT_INTERFACE - use interface font
* 1: PR_FONT_LEVEL - use level font
* 2: PR_FONT_8X8 - use 8x8 font no matter what
Properly fix setfont/setrtl in between text boxes There used to be a problem with the setfont and setrtl script commands. Namely, if you used them in between text boxes naïvely, without any careful thought, then the fading out text box would suddenly gain the font of the new one. A kludge solution to this was implemented by simply blocking the script until the existing text box faded out before switching the font or RTL, and shipped for 2.4.0. However, a better solution is to simply bake the font flags in to the text box, so that way, if the level font switches, then the text box keeps its font. This is only for custom levels, because in the main game, the font in a text box needs to be able to change depending on language. But it seems like custom level translations weren't much on the roadmap, and so even the existing hack didn't support changing the font based on translation (even though translation of custom level cutscenes is supported). So baking the font flags into the text box here doesn't make things any worse. It also makes things better, arguably, by allowing multiple text boxes to exist on screen at once with different fonts. Maybe in the future we'll need a flag that specifies that the font should change depending on language if a translation in said language exists for the text box, or something like that. For people that want to override the fonts of every existing text box on screen, you can specify "all" as the second parameter of setfont or setrtl to do so.
2024-01-22 07:09:35 +01:00
* 3-31: - use font index 0-28 (depending on custom, from
* PR_FONT_IDX_IS_CUSTOM)
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
*
* rtl will be set depending on whether we're requesting the interface
* font (take it from the lang attributes) or level font (take it from
* the level attributes), or false otherwise. */
*rtl = false;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
if (sel < 0)
{
// Shouldn't happen but better safe than sorry...
return NULL;
}
switch (sel)
{
case 1:
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
if (!font_level_is_interface)
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
{
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
*rtl = cl.rtl;
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
if (font_idx_level_is_custom)
{
return container_get(&fonts_custom, font_idx_level);
}
else
{
return container_get(&fonts_main, font_idx_level);
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
}
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
SDL_FALLTHROUGH;
case 0:
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
*rtl = loc::get_langmeta()->rtl;
Make main game content use interface font instead of 8x8 font If a custom level doesn't specify a font, it should be the 8x8 font. But the main game can't specify a font, it's just the interface font because that's for the language that the game is in.
2023-01-21 03:27:55 +01:00
return container_get(&fonts_main, loc::get_langmeta()->font_idx);
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
case 2:
return container_get(&fonts_main, font_idx_8x8);
}
Properly fix setfont/setrtl in between text boxes There used to be a problem with the setfont and setrtl script commands. Namely, if you used them in between text boxes naïvely, without any careful thought, then the fading out text box would suddenly gain the font of the new one. A kludge solution to this was implemented by simply blocking the script until the existing text box faded out before switching the font or RTL, and shipped for 2.4.0. However, a better solution is to simply bake the font flags in to the text box, so that way, if the level font switches, then the text box keeps its font. This is only for custom levels, because in the main game, the font in a text box needs to be able to change depending on language. But it seems like custom level translations weren't much on the roadmap, and so even the existing hack didn't support changing the font based on translation (even though translation of custom level cutscenes is supported). So baking the font flags into the text box here doesn't make things any worse. It also makes things better, arguably, by allowing multiple text boxes to exist on screen at once with different fonts. Maybe in the future we'll need a flag that specifies that the font should change depending on language if a translation in said language exists for the text box, or something like that. For people that want to override the fonts of every existing text box on screen, you can specify "all" as the second parameter of setfont or setrtl to do so.
2024-01-22 07:09:35 +01:00
if (custom)
{
return container_get(&fonts_custom, sel-3);
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
return container_get(&fonts_main, sel-3);
}
#define FLAG_PART(start, count) ((flags >> start) % (1 << count))
static PrintFlags decode_print_flags(uint32_t flags)
{
PrintFlags pf;
pf.scale = FLAG_PART(0, 3) + 1;
Properly fix setfont/setrtl in between text boxes There used to be a problem with the setfont and setrtl script commands. Namely, if you used them in between text boxes naïvely, without any careful thought, then the fading out text box would suddenly gain the font of the new one. A kludge solution to this was implemented by simply blocking the script until the existing text box faded out before switching the font or RTL, and shipped for 2.4.0. However, a better solution is to simply bake the font flags in to the text box, so that way, if the level font switches, then the text box keeps its font. This is only for custom levels, because in the main game, the font in a text box needs to be able to change depending on language. But it seems like custom level translations weren't much on the roadmap, and so even the existing hack didn't support changing the font based on translation (even though translation of custom level cutscenes is supported). So baking the font flags into the text box here doesn't make things any worse. It also makes things better, arguably, by allowing multiple text boxes to exist on screen at once with different fonts. Maybe in the future we'll need a flag that specifies that the font should change depending on language if a translation in said language exists for the text box, or something like that. For people that want to override the fonts of every existing text box on screen, you can specify "all" as the second parameter of setfont or setrtl to do so.
2024-01-22 07:09:35 +01:00
pf.font_sel = fontsel_to_font(
FLAG_PART(3, 5), &pf.rtl, flags & PR_FONT_IDX_IS_CUSTOM
);
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
if (flags & PR_RTL_FORCE)
{
pf.rtl = true;
}
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a) There used to be two ways of fading in/out text in VVVVVV: - Local code that modifies the R, G and B values of the text - Keeping the RGB values the same and using the alpha channel The latter approach is only used once, for [Press ENTER to return to editor]. The former approach causes problems with colored (button) glyphs: there's no way for the print function to tell from the RGB values whether a color is "full Viridian-cyan" or "Viridian-cyan faded out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the print function that the color brightness is reduced to match the brightness of colored glyphs to the brightness of the rest of the text. However, there were already plans to make the single use of alpha consistent with the rest of the game and the style, so PR_ALPHA(value) could be removed, as well as the bit signifying whether the brightness or alpha value is used. For the editor text, I simply copied the "Press {button} to teleport" behavior of hiding the text completely if it becomes darker than 100/255. Another simplification is to make the print function handle not just the brightness of the color glyphs while local code handled the brightness of the normal text color, but to make the print function handle both. That way, the callsite can simply pass in the full colors and the brightness flag, and the flag name can be made a lot simpler as well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
pf.brightness = ~FLAG_PART(8, 8) & 0xff;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
pf.border = flags & PR_BOR;
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
pf.full_border = flags & PR_FULLBOR;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
pf.align_cen = flags & PR_CEN;
pf.align_right = flags & PR_RIGHT;
pf.cjk_low = flags & PR_CJK_LOW;
pf.cjk_high = flags & PR_CJK_HIGH;
Add PR_RTL_XFLIP print flag This lets you mirror the X axis specifically in RTL languages, so the left border is 320 and the right border is 0, and invert the meaning of PR_LEFT (0) and PR_RIGHT. Most of the time this is not necessary, it's just for stuff where a label is followed by a different print, like "Font: " followed by the font name, time trial time displays, etc
2024-01-03 22:21:37 +01:00
pf.rtl_xflip = flags & PR_RTL_XFLIP;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
if (pf.full_border)
Add translingual map legend code + border8
2023-10-09 03:22:26 +02:00
{
pf.border = false;
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
return pf;
}
#undef FLAG_PART
Add some more preparation for multi-font support and proper unloading find_font_by_name() just finds the index of a given font name. This index is supposed to be stored and reused, because the font (for a language/level) won't be changed very often. So this function would only run when getting the language metadata, when loading a level, etc.
2023-01-11 04:53:44 +01:00
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
static bool next_wrap(
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
Font* f,
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
size_t* start,
size_t* len,
const char* str,
const int maxwidth
) {
Harden next_wrap against getting stuck on a single character If, somehow, a single character is wider than the limit, next_wrap would get you stuck in an infinite loop by refusing to update the start index and giving a line length of 0. Now, it just gives you a line with that single character. I also made some small readability improvements: I renamed next_wrap_s to next_wrap_buf, and added comments at the top of both functions explaining what they do.
2023-01-23 01:56:44 +01:00
/* Get information about the current line in wordwrapped text,
* given this line starts at str[*start].
* *start is updated to the start of the next line. */
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
size_t idx = 0;
size_t lenfromlastspace = 0;
size_t lastspace = 0;
int linewidth = 0;
*len = 0;
if (str[idx] == '\0')
{
return false;
}
while (true)
{
Fix UTF-8 handling in next_wrap Finally this FIXME can be removed!
2023-02-23 04:52:56 +01:00
uint8_t codepoint_nbytes;
uint32_t codepoint = UTF8_peek_next(&str[idx], &codepoint_nbytes);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
Fix UTF-8 handling in next_wrap Finally this FIXME can be removed!
2023-02-23 04:52:56 +01:00
switch (codepoint)
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
case ' ':
if (loc::get_langmeta()->autowordwrap)
{
lenfromlastspace = idx;
lastspace = *start;
}
break;
case '\n':
case '|':
*start += 1;
SDL_FALLTHROUGH;
case '\0':
return true;
}
Fix UTF-8 handling in next_wrap Finally this FIXME can be removed!
2023-02-23 04:52:56 +01:00
linewidth += get_advance(f, codepoint);
Move line width addition in next_wrap to be after switch block There is no overlap in side effects between this line and the switch statement after it, but it did result in adding the width of a final null terminator or newline to the width of the current line, which is a waste because those widths both 1) require trying to find non-existent characters in the font and 2) will not be used. I found this out because I added a debug print in find_glyphinfo(), and something was requesting lots of codepoint 0 from the font.
2023-02-20 04:58:16 +01:00
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
if (linewidth > maxwidth)
{
if (lenfromlastspace != 0)
{
*len = lenfromlastspace;
*start = lastspace + 1;
}
Harden next_wrap against getting stuck on a single character If, somehow, a single character is wider than the limit, next_wrap would get you stuck in an infinite loop by refusing to update the start index and giving a line length of 0. Now, it just gives you a line with that single character. I also made some small readability improvements: I renamed next_wrap_s to next_wrap_buf, and added comments at the top of both functions explaining what they do.
2023-01-23 01:56:44 +01:00
if (idx == 0)
{
// Oops, we're stuck at a single character
*len = 1;
*start += 1;
}
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
return true;
}
Fix UTF-8 handling in next_wrap Finally this FIXME can be removed!
2023-02-23 04:52:56 +01:00
idx += codepoint_nbytes;
*start += codepoint_nbytes;
*len += codepoint_nbytes;
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
}
Harden next_wrap against getting stuck on a single character If, somehow, a single character is wider than the limit, next_wrap would get you stuck in an infinite loop by refusing to update the start index and giving a line length of 0. Now, it just gives you a line with that single character. I also made some small readability improvements: I renamed next_wrap_s to next_wrap_buf, and added comments at the top of both functions explaining what they do.
2023-01-23 01:56:44 +01:00
static bool next_wrap_buf(
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
Font* f,
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
char buffer[],
const size_t buffer_size,
size_t* start,
const char* str,
const int maxwidth
) {
Harden next_wrap against getting stuck on a single character If, somehow, a single character is wider than the limit, next_wrap would get you stuck in an infinite loop by refusing to update the start index and giving a line length of 0. Now, it just gives you a line with that single character. I also made some small readability improvements: I renamed next_wrap_s to next_wrap_buf, and added comments at the top of both functions explaining what they do.
2023-01-23 01:56:44 +01:00
/* Get each line of wordwrapped text, writing one line at a time to a buffer.
* Call as follows:
*
* char buf[256];
* size_t start = 0;
* while (next_wrap_buf(font, buf, sizeof(buf), &start, "String to wordwrap", 320))
* {
* // buf contains a line of text
* }
*/
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
size_t len = 0;
const size_t prev_start = *start;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
const bool retval = next_wrap(f, start, &len, &str[*start], maxwidth);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
if (retval)
{
/* Like next_split_s(), don't use SDL_strlcpy() here. */
const size_t length = SDL_min(buffer_size - 1, len);
SDL_memcpy(buffer, &str[prev_start], length);
buffer[length] = '\0';
}
return retval;
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
std::string string_wordwrap(const uint32_t flags, const std::string& s, int maxwidth, short *lines /*= NULL*/)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
/* Return a string wordwrapped to a maximum limit by adding newlines.
* CJK will need to have autowordwrap disabled and have manually inserted newlines. */
if (lines != NULL)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
*lines = 1;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
PrintFlags pf = decode_print_flags(flags);
if (pf.font_sel == NULL)
{
return s;
}
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
const char* orig = s.c_str();
std::string result;
size_t start = 0;
bool first = true;
while (true)
{
size_t len = 0;
const char* part = &orig[start];
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
const bool retval = next_wrap(pf.font_sel, &start, &len, part, maxwidth);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
if (!retval)
{
return result;
}
if (first)
{
first = false;
}
else
{
result.push_back('\n');
if (lines != NULL)
{
(*lines)++;
}
}
result.append(part, len);
}
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
std::string string_wordwrap_balanced(const uint32_t flags, const std::string& s, int maxwidth)
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
/* Return a string wordwrapped to a limit of maxwidth by adding newlines.
* Try to fill the lines as far as possible, and return result where lines are most filled.
* Goal is to have all lines in textboxes be about as long and to avoid wrapping just one word to a new line.
* CJK will need to have autowordwrap disabled and have manually inserted newlines. */
if (!loc::get_langmeta()->autowordwrap)
{
return s;
}
short lines;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
string_wordwrap(flags, s, maxwidth, &lines);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
int bestwidth = maxwidth;
if (lines > 1)
{
for (int curlimit = maxwidth; curlimit > 1; curlimit -= 8)
{
short try_lines;
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
string_wordwrap(flags, s, curlimit, &try_lines);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
if (try_lines > lines)
{
bestwidth = curlimit + 8;
break;
}
}
}
Make wordwrapping functions take font arguments They need to know how wide the text is going to be in a particular font, so font::string_wordwrap and font::string_wordwrap_balanced now take a flags argument like all the printing and dimensions-getting functions. next_wrap and next_wrap_s take a Font* now, they're internal to Font.cpp so they can take a Font and avoid double flag-parsing. But if any non-Font.cpp code needs next_wrap/next_wrap_s in the future, I'd just make a public wrapper that takes a uint32_t flags and passes the Font* to the internal functions.
2023-01-21 02:31:44 +01:00
return string_wordwrap(flags, s, bestwidth);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
std::string string_unwordwrap(const std::string& s)
{
/* Takes a string wordwrapped by newlines, and turns it into a single line, undoing the wrapping.
* Also trims any leading/trailing whitespace and collapses multiple spaces into one (to undo manual centering)
* Only applied to English, so langmeta.autowordwrap isn't used here (it'd break looking up strings) */
std::string result;
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
result.reserve(s.length());
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
bool latest_was_space = true; // last character was a space (or the beginning, don't want leading whitespace)
int consecutive_newlines = 0; // number of newlines currently encountered in a row (multiple newlines should stay!)
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
const char* str = s.c_str();
uint32_t ch;
while ((ch = UTF8_next(&str)))
{
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
if (ch == '\n')
{
if (consecutive_newlines == 0)
{
ch = ' ';
}
else if (consecutive_newlines == 1)
{
Fix segfault: unwordwrap string w/ 2 start `\n`s This fixes a segmentation fault caused by an out-of-bounds indexing caused by an attempt to unwordwrap a string that starts with two newlines. The problem here is that in the branch of the function string_unwordwrap() where `consecutive_newlines == 1`, the function does not check that the string `result` isn't empty before attempting to index `result.size()-1`. If `result` is empty, then `result.size()` is 0, and `result.size()-1` becomes -1, and indexing a string at position -1 is always undefined behavior. Funnily enough, a similar indexing happens just a few lines down, but this time, there is a check to make sure that the string isn't empty first. I'm unsure of how Dav999 forgot that check a few lines earlier. This situation can happen in practice, with custom level localizations. I made a level with a filename of testloc.vvvvvv and created a file at lang/fr/levels/testloc/custom_cutscenes.xml with the following content: <?xml version="1.0" encoding="UTF-8"?> <cutscenes> <cutscene id="test" explanation=""> <dialogue speaker="cyan" english="This is text..." translation="blarg"/> </cutscene> </cutscenes> Then I switched to French, created a script named `test`, and created a text box that started with two newlines (so in total, the text box must be at least 3 lines in length). Running the script triggers the segfault when the text box is created. (Well, technically, on my machine, it triggers an assertion fail in libstdc++ and aborts, but that's basically the same thing.) To fix this while still preserving the exact amount of newlines, if `result` is empty, we add a newline instead of attempting to index the string.
2024-01-19 05:47:09 +01:00
if (!result.empty())
{
// The last character was already a newline, so change it back from the space we thought it should have become.
result[result.size()-1] = '\n';
}
else
{
// The string starts with two or more newlines, in this case we didn't add the first one at all.
result.append("\n\n");
}
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
consecutive_newlines++;
}
else
{
consecutive_newlines = 0;
}
if (ch != ' ' || !latest_was_space)
{
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
result.append(UTF8_encode(ch).bytes);
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
latest_was_space = (ch == ' ' || ch == '\n');
}
// We could have one trailing space
if (!result.empty() && result[result.size()-1] == ' ')
{
result.erase(result.end()-1);
}
return result;
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
static int print_char(
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
const Font* f,
const uint32_t codepoint,
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
int x,
int y,
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
const int scale,
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
uint8_t r,
uint8_t g,
uint8_t b,
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a) There used to be two ways of fading in/out text in VVVVVV: - Local code that modifies the R, G and B values of the text - Keeping the RGB values the same and using the alpha channel The latter approach is only used once, for [Press ENTER to return to editor]. The former approach causes problems with colored (button) glyphs: there's no way for the print function to tell from the RGB values whether a color is "full Viridian-cyan" or "Viridian-cyan faded out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the print function that the color brightness is reduced to match the brightness of colored glyphs to the brightness of the rest of the text. However, there were already plans to make the single use of alpha consistent with the rest of the game and the style, so PR_ALPHA(value) could be removed, as well as the bit signifying whether the brightness or alpha value is used. For the editor text, I simply copied the "Press {button} to teleport" behavior of hiding the text completely if it becomes darker than 100/255. Another simplification is to make the print function handle not just the brightness of the color glyphs while local code handled the brightness of the normal text color, but to make the print function handle both. That way, the callsite can simply pass in the full colors and the brightness flag, and the flag name can be made a lot simpler as well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
const uint8_t brightness
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
)
{
/* Draws the glyph for a codepoint at x,y.
* Returns the amount of pixels to advance the cursor. */
Hide unicode directional control characters They shouldn't be looked up in the font and displayed under any circumstances.
2024-01-03 18:55:42 +01:00
if (is_directional_character(codepoint) || is_joiner(codepoint))
{
// Some characters should be completely invisible
return 0;
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
const Font* f_glyph;
GlyphInfo* glyph = find_glyphinfo(f, codepoint, &f_glyph);
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
if (glyph == NULL)
{
return f->glyph_w * scale;
}
Draw outlines for colored characters correctly If we try to draw a colored character, and the color is fully black, it means we're drawing the outline.
2023-01-05 04:55:13 +01:00
if (glyph->flags & GLYPH_COLOR && (r | g | b) != 0)
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
{
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a) There used to be two ways of fading in/out text in VVVVVV: - Local code that modifies the R, G and B values of the text - Keeping the RGB values the same and using the alpha channel The latter approach is only used once, for [Press ENTER to return to editor]. The former approach causes problems with colored (button) glyphs: there's no way for the print function to tell from the RGB values whether a color is "full Viridian-cyan" or "Viridian-cyan faded out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the print function that the color brightness is reduced to match the brightness of colored glyphs to the brightness of the rest of the text. However, there were already plans to make the single use of alpha consistent with the rest of the game and the style, so PR_ALPHA(value) could be removed, as well as the bit signifying whether the brightness or alpha value is used. For the editor text, I simply copied the "Press {button} to teleport" behavior of hiding the text completely if it becomes darker than 100/255. Another simplification is to make the print function handle not just the brightness of the color glyphs while local code handled the brightness of the normal text color, but to make the print function handle both. That way, the callsite can simply pass in the full colors and the brightness flag, and the flag name can be made a lot simpler as well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
r = g = b = brightness;
}
else if (brightness < 255)
{
float bri_factor = brightness / (float) 255;
r *= bri_factor;
g *= bri_factor;
b *= bri_factor;
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
}
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
// If the glyph is a fallback glyph, center it
if (f_glyph != f)
{
x += (f->glyph_w - f_glyph->glyph_w) / 2;
y += (f->glyph_h - f_glyph->glyph_h) / 2;
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
Add support for button glyph fallback fonts In a button glyph font (like buttons_8x8.fontmeta) you can now specify <type>buttons</type> to indicate that it's a button glyphs font. In a normal font, you can specify <fallback>buttons_8x8</fallback>. This will make it such that if a character is not found in the main font, it will instead be looked for in buttons_8x8. If not found there either, the main font's U+FFFD or '?' will be used as before.
2023-02-20 04:35:19 +01:00
graphics.draw_grid_tile(
f_glyph->image,
glyph->image_idx,
x,
y,
f_glyph->glyph_w,
f_glyph->glyph_h,
r, g, b,
scale,
scale * (graphics.flipmode ? -1 : 1)
);
return get_advance_ff(f, f_glyph, glyph) * scale;
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
}
Add language-specific font configuration meta.xml can now have a <font> tag, which gives the name of the font that the language needs. This will directly control the interface font when the language is active, and will soon also control the font used for each option on the language screen.
2023-01-15 01:31:02 +01:00
const char* get_main_font_name(uint8_t idx)
{
Font* f = container_get(&fonts_main, idx);
if (f == NULL)
{
return "";
}
return f->name;
}
Add menu for selecting the level font By default, when you open the level editor to start a new level, the level font will now match your VVVVVV language; so if you're, say, Japanese, then you can make Japanese levels from the get-go. If you want to make levels for a different target audience, you can change the font via a new menu (map settings > change description > change font). The game will remember this choice and it will become the new initial level font.
2023-01-21 19:06:30 +01:00
const char* get_main_font_display_name(uint8_t idx)
{
Font* f = container_get(&fonts_main, idx);
if (f == NULL)
{
return "";
}
if (idx == font_idx_8x8)
{
// Deciding the name for the 8x8 font was harder than I'd like to admit.
if (loc::lang == "en" || loc::get_langmeta()->font_idx != font_idx_8x8)
{
// If you use English, or a CJK language: "english/..."
SDL_strlcpy(
f->display_name,
"english/…",
sizeof(f->display_name)
);
}
else
{
// If you use another, e.g. German: "english/deutsch/..."
SDL_snprintf(
f->display_name, sizeof(f->display_name),
"english/%s/…",
loc::get_langmeta()->nativename.c_str()
);
}
}
return f->display_name;
}
const char* get_level_font_display_name(void)
{
if (font_idx_level_is_custom)
{
Font* f = container_get(&fonts_custom, font_idx_level);
if (f == NULL)
{
return "";
}
return f->display_name;
}
return get_main_font_display_name(font_idx_level);
}
Completely remove Graphics::bprint Only three deprecated functions remain: - Graphics::Print - Graphics::PrintWrap - Graphics::bigprint I also fixed multiline transparent textboxes having their outlines overlap the text itself, and fixed textboxclass::padtowidth assuming glyph widths of 8 (it made the hints at the start of intermission 1 run offscreen for example)
2023-01-17 22:18:39 +01:00
bool glyph_dimensions(uint32_t flags, uint8_t* glyph_w, uint8_t* glyph_h)
{
/* Gets the dimensions (glyph_w and glyph_h) of a certain font.
* Returns true if the font is valid (glyph_w and/or glyph_h were written to if not NULL), false if not. */
PrintFlags pf = decode_print_flags(flags);
if (pf.font_sel == NULL)
{
return false;
}
if (glyph_w != NULL)
{
*glyph_w = pf.font_sel->glyph_w;
}
if (glyph_h != NULL)
{
*glyph_h = pf.font_sel->glyph_h;
}
return true;
}
Change font::len text argument from std::string to const char* See the previous two commits, a lot of the time we don't need std::string objects to be passed to these functions because we already have C strings. Commit 1/3: font::print_wrap Commit 2/3: font::print -> Commit 3/3: font::len
2023-03-05 00:32:58 +01:00
int len(const uint32_t flags, const char* text)
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
PrintFlags pf = decode_print_flags(flags);
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
if (bidi_should_transform(pf.rtl, text))
Add Arabic ligature support Montassar prepared a list of all the ligatures that needed to be supported, which was a simple A+B->C table, so that one was not too difficult either!
2024-01-03 17:34:53 +01:00
{
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
text = bidi_transform(pf.rtl, text);
Add Arabic ligature support Montassar prepared a list of all the ligatures that needed to be supported, which was a simple A+B->C table, so that one was not too difficult either!
2024-01-03 17:34:53 +01:00
}
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
int text_len = 0;
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
uint32_t codepoint;
while ((codepoint = UTF8_next(&text)))
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
{
Ignore directional control chars in font::len() They're invisible in font::print(), but they were still considered characters with widths in the width function. This change made the levels screen look better in RTL too - I was wondering why the level options were too far left.
2024-01-06 01:56:45 +01:00
if (!is_directional_character(codepoint) && !is_joiner(codepoint))
{
text_len += get_advance(pf.font_sel, codepoint);
}
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
Handle more flags in print and len functions The font::len function now handles the printing scale, so it can immediately return the scaled length instead of having the caller calculate it. The print function now handles CJK low/high flags and vertically centers CJK text by default (instead of letting it stick out on the bottom).
2023-01-08 01:22:15 +01:00
return text_len * pf.scale;
Move wordwrapping functions and len to Font.cpp/font:: namespace The following functions were moved directly: - next_wrap - next_wrap_s - string_wordwrap - string_wordwrap_balanced - string_unwordwrap These ones will probably still need get a flags argument, except for string_unwordwrap (since they need to know what font we're talking about. The implementation of graphics.len has also been moved to Font.cpp, but graphics.len still exists for now and is deprecated.
2023-01-06 19:17:50 +01:00
}
Start using level-specific font where needed, make CJK tweaks Level text such as room names, text box content, and the contents of the script editor need to be displayed in the level-specific font, and tweaked to look right. This involves displaying less lines in the script editor, making text boxes bigger, displaying some text higher and some text lower. This is still unfinished, but it's the real start of a migration to font::print functions!
2023-01-12 05:27:52 +01:00
int height(const uint32_t flags)
{
PrintFlags pf = decode_print_flags(flags);
if (pf.font_sel == NULL)
{
return 8;
}
return pf.font_sel->glyph_h * pf.scale;
}
Add font::is_rtl(uint32_t flags) This will return if the given flags indicate RTL properties (such as textboxes being right-aligned).
2024-01-03 20:23:57 +01:00
bool is_rtl(const uint32_t flags)
{
PrintFlags pf = decode_print_flags(flags);
return pf.rtl;
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
void print(
const uint32_t flags,
int x,
int y,
Overload font::print text argument for both std::string and const char* Turns out I was overplaying my hand a little when changing font::print from std::string to const char*, so instead, I'll overload the function: it can take either a const char* (the main function) or a std::string (a wrapper). This means any C string that's printed everywhere else (which is common, especially because loc::gettext gives them) no longer needs to be converted to a std::string object each call. Commit 1/3: font::print_wrap -> Commit 2/3: font::print Commit 3/3: font::len
2023-03-05 00:21:52 +01:00
const char* text,
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
const uint8_t r,
const uint8_t g,
const uint8_t b
)
{
PrintFlags pf = decode_print_flags(flags);
Start using level-specific font where needed, make CJK tweaks Level text such as room names, text box content, and the contents of the script editor need to be displayed in the level-specific font, and tweaked to look right. This involves displaying less lines in the script editor, making text boxes bigger, displaying some text higher and some text lower. This is still unfinished, but it's the real start of a migration to font::print functions!
2023-01-12 05:27:52 +01:00
if (pf.font_sel == NULL)
{
return;
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
Add PR_RTL_XFLIP print flag This lets you mirror the X axis specifically in RTL languages, so the left border is 320 and the right border is 0, and invert the meaning of PR_LEFT (0) and PR_RIGHT. Most of the time this is not necessary, it's just for stuff where a label is followed by a different print, like "Font: " followed by the font name, time trial time displays, etc
2024-01-03 22:21:37 +01:00
if (pf.rtl && pf.rtl_xflip && (!pf.align_cen || x != -1))
{
x = SCREEN_WIDTH_PIXELS - x;
pf.align_right = !pf.align_right;
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
if (pf.align_cen || pf.align_right)
{
Handle more flags in print and len functions The font::len function now handles the printing scale, so it can immediately return the scaled length instead of having the caller calculate it. The print function now handles CJK low/high flags and vertically centers CJK text by default (instead of letting it stick out on the bottom).
2023-01-08 01:22:15 +01:00
const int textlen = len(flags, text);
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
if (pf.align_cen)
{
if (x == -1)
{
x = SCREEN_WIDTH_PIXELS / 2;
}
Inverse centered text screen border for RTL If text is set to be centered, but is so long that it starts running offscreen on both sides, the print function instead makes the text start no further left than the left border of the screen (x=0). This is because text running offscreen at the end only is more readable and looks less sloppy than running offscreen at both sides. For RTL, the opposite applies, so it now also works oppositely for RTL prints, where centered strings will only run offscreen on the left side of the screen.
2024-01-08 04:59:08 +01:00
x -= textlen/2;
if (!pf.rtl)
{
x = SDL_max(x, 0);
}
else
{
x = SDL_min(x, SCREEN_WIDTH_PIXELS - textlen);
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
}
else
{
x -= textlen;
}
}
if (pf.border && !graphics.notextoutline)
{
static const int offsets[4][2] = {{0,-1}, {-1,0}, {1,0}, {0,1}};
for (int offset = 0; offset < 4; offset++)
{
print(
Add PR_RTL_XFLIP print flag This lets you mirror the X axis specifically in RTL languages, so the left border is 320 and the right border is 0, and invert the meaning of PR_LEFT (0) and PR_RIGHT. Most of the time this is not necessary, it's just for stuff where a label is followed by a different print, like "Font: " followed by the font name, time trial time displays, etc
2024-01-03 22:21:37 +01:00
flags & ~PR_BOR & ~PR_CEN & ~PR_RIGHT & ~PR_RTL_XFLIP,
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
x + offsets[offset][0]*pf.scale,
y + offsets[offset][1]*pf.scale,
text,
0, 0, 0
);
}
}
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
if (pf.full_border)
Add translingual map legend code + border8
2023-10-09 03:22:26 +02:00
{
static const int offsets[8][2] = { {0,-1}, {-1,0}, {1,0}, {0,1}, {-1,-1}, {1,1}, {-1,1}, {1,-1} };
for (int offset = 0; offset < 8; offset++)
{
print(
Add PR_RTL_XFLIP print flag This lets you mirror the X axis specifically in RTL languages, so the left border is 320 and the right border is 0, and invert the meaning of PR_LEFT (0) and PR_RIGHT. Most of the time this is not necessary, it's just for stuff where a label is followed by a different print, like "Font: " followed by the font name, time trial time displays, etc
2024-01-03 22:21:37 +01:00
flags & ~PR_FULLBOR & ~PR_CEN & ~PR_RIGHT & ~PR_RTL_XFLIP,
Add translingual map legend code + border8
2023-10-09 03:22:26 +02:00
x + offsets[offset][0] * pf.scale,
y + offsets[offset][1] * pf.scale,
text,
0, 0, 0
);
}
}
Migrate more prints to font::, determine font for most textboxes Some textboxes need to be in the level font (like room names, cutscene dialogue, etc - even in the main game), and some need to be in the interface font (like when you collect a shiny trinket or crewmate). So most of these textboxes now have graphics.textboxprintflags(font_flag) as appropriate. RoomnameTranslator.cpp is now also migrated to the new print system - in room name translator mode, the room name is now displayed in the 8x8 font if it's untranslated and the level font if it is.
2023-01-13 05:11:39 +01:00
int h_diff_8 = (pf.font_sel->glyph_h-8)*pf.scale;
Handle more flags in print and len functions The font::len function now handles the printing scale, so it can immediately return the scaled length instead of having the caller calculate it. The print function now handles CJK low/high flags and vertically centers CJK text by default (instead of letting it stick out on the bottom).
2023-01-08 01:22:15 +01:00
if (h_diff_8 < 0)
{
/* If the font is less high than 8,
* just center it (lower on screen) */
y -= h_diff_8/2;
}
else if (pf.cjk_high)
{
y -= h_diff_8;
}
else if (!pf.cjk_low)
{
y -= h_diff_8/2;
}
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
if (bidi_should_transform(pf.rtl, text))
Implement bidi reordering at display time I'm now using SheenBidi to reorder RTL and bidirectional text properly at text rendering time! For Arabic this is still missing reshaping, but everything's looking really promising now! The code changes are really non-invasive. The changes to Font.cpp are absolutely minimal: 1305+ if (bidi_should_transform(text)) 1306+ { 1307+ text = bidi_transform(text); 1308+ } There's now a FontBidi.cpp, which implements these two functions, notably bidi_transform(), which takes a UTF-8 encoded string and returns another UTF-8 encoded string that has bidi reorderings and reshapings applied. In that function, SheenBidi gives us information about where in the input string runs start and end, and on a basic level, all we need to do there is to concatenate the parts together in the order that we're given them, and to reverse the RTL runs (recognizable by odd levels). As this is a proof-of-concept, bidi_should_transform() still always returns true, applying the bidi algorithm to all languages and all strings. I'm thinking of enabling bidi only when the language/font metadata enables RTL (which could be for the interface or for a custom level), or outside of that, at least when RTL characters are detected (such as Arabic or Hebrew Unicode blocks).
2024-01-02 03:57:26 +01:00
{
Add RTL level property and print flag Again, the RTL property controls whether textboxes will be right-aligned, and that kind of stuff. It can't be font-bound, since Space Station supports Hebrew characters and we want to be able to support, say, a Hebrew translation or Hebrew levels in the future without having to make a dedicated (or duplicated) font for it. Therefore it's a property of both the language pack as well as custom levels - like custom levels already had a <font> tag, they now also have an <rtl> tag that sets this property. Right now, we'll have to hardcode it so the menu option for the Arabic font sets the <rtl> property to 1, and all the other options set it to 0. But it's future-proof in that we can later decide to split the option for Space Station into an LTR option and an RTL option (so both "english/..." and "עברית" would select Space Station, but one sets the RTL property to 0 and the other sets it to 1).
2024-01-03 20:09:23 +01:00
text = bidi_transform(pf.rtl, text);
Implement bidi reordering at display time I'm now using SheenBidi to reorder RTL and bidirectional text properly at text rendering time! For Arabic this is still missing reshaping, but everything's looking really promising now! The code changes are really non-invasive. The changes to Font.cpp are absolutely minimal: 1305+ if (bidi_should_transform(text)) 1306+ { 1307+ text = bidi_transform(text); 1308+ } There's now a FontBidi.cpp, which implements these two functions, notably bidi_transform(), which takes a UTF-8 encoded string and returns another UTF-8 encoded string that has bidi reorderings and reshapings applied. In that function, SheenBidi gives us information about where in the input string runs start and end, and on a basic level, all we need to do there is to concatenate the parts together in the order that we're given them, and to reverse the RTL runs (recognizable by odd levels). As this is a proof-of-concept, bidi_should_transform() still always returns true, applying the bidi algorithm to all languages and all strings. I'm thinking of enabling bidi only when the language/font metadata enables RTL (which could be for the interface or for a custom level), or outside of that, at least when RTL characters are detected (such as Arabic or Hebrew Unicode blocks).
2024-01-02 03:57:26 +01:00
}
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
int position = 0;
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
uint32_t codepoint;
Overload font::print text argument for both std::string and const char* Turns out I was overplaying my hand a little when changing font::print from std::string to const char*, so instead, I'll overload the function: it can take either a const char* (the main function) or a std::string (a wrapper). This means any C string that's printed everywhere else (which is common, especially because loc::gettext gives them) no longer needs to be converted to a std::string object each call. Commit 1/3: font::print_wrap -> Commit 2/3: font::print Commit 3/3: font::len
2023-03-05 00:21:52 +01:00
while ((codepoint = UTF8_next(&text)))
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
{
position += font::print_char(
Handle more flags in print and len functions The font::len function now handles the printing scale, so it can immediately return the scaled length instead of having the caller calculate it. The print function now handles CJK low/high flags and vertically centers CJK text by default (instead of letting it stick out on the bottom).
2023-01-08 01:22:15 +01:00
pf.font_sel,
Replace utfcpp by UTF8.h in Font.cpp I'm also planning to change the argument types of font::len, font::print and font::print_wrap from const std::string&s to const char*s, but I'll do that separately.
2023-02-23 04:15:27 +01:00
codepoint,
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
x + position,
y,
pf.scale,
r,
g,
b,
Replace PR_COLORGLYPH_BRI(a) and PR_ALPHA(a) with PR_BRIGHTNESS(a) There used to be two ways of fading in/out text in VVVVVV: - Local code that modifies the R, G and B values of the text - Keeping the RGB values the same and using the alpha channel The latter approach is only used once, for [Press ENTER to return to editor]. The former approach causes problems with colored (button) glyphs: there's no way for the print function to tell from the RGB values whether a color is "full Viridian-cyan" or "Viridian-cyan faded out 50%", so I added the flag PR_COLORGLYPH_BRI(value) to tell the print function that the color brightness is reduced to match the brightness of colored glyphs to the brightness of the rest of the text. However, there were already plans to make the single use of alpha consistent with the rest of the game and the style, so PR_ALPHA(value) could be removed, as well as the bit signifying whether the brightness or alpha value is used. For the editor text, I simply copied the "Press {button} to teleport" behavior of hiding the text completely if it becomes darker than 100/255. Another simplification is to make the print function handle not just the brightness of the color glyphs while local code handled the brightness of the normal text color, but to make the print function handle both. That way, the callsite can simply pass in the full colors and the brightness flag, and the flag name can be made a lot simpler as well: PR_BRIGHTNESS(value).
2023-01-31 02:22:43 +01:00
pf.brightness
Implement first font::print function, fix most fading of colored glyphs There has always been a mess of different print functions that all had slightly different specifics and called each other: Print(x, y, text, r, g, b, cen) nothing special here, just does what the arguments say PrintAlpha(x, y, text, r, g, b, a, cen) just Print but with an alpha argument PrintWrap(x, y, text, r, g, b, cen, linespacing, maxwidth) added for wordwrapping, heavily used now bprint(x, y, text, r, g, b, cen) prints an outline, then just PrintAlpha bprintalpha(x, y, text, r, g, b, a, cen) just bprint but with an alpha argument bigprint(x, y, text, r, g, b, cen, sc) nothing special here, just does what the arguments say bigbprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigprint bigrprint(x, y, text, r, g, b, cen, sc) right-aligns text, unless cen is given in which case it just centers text like other functions already do? bigbrprint(x, y, text, r, g, b, cen, sc) prints an outline, then just bigrprint We need even more specifics with the new font system: we need to be able to specify whether CJK characters should be vertically centered or stick out on the top/bottom, and we sometimes need to pass in brightness variables for colored glyphs. And text printing functions now fit better in Font.cpp anyway. So there's now a big overhaul of print functions: all these functions will be replaced by font::print and font::print_wrap (the former of which now exists). These take flags as their first argument, which can be 0 for a basic left-aligned print, PR_CEN for centered text (set X to -1!!!) PR_BOR for a border (instead of functions like bprint and bigbprint), PR_2X, PR_3X etc for scaling, and these can be combined with |. Some text, for example [Press ESC to return to editor], fades in/out using the alpha value, which is passed to the print function. In some other places (like Press ENTER to teleport, textboxes, trophy text...) text can fade in or out by direct changes to the RGB values. This means regular color-adjusted white text can change color, but colored button glyphs can't, since there's no way to know in the print system what the maximum RGB values of a specific textbox are supposed to be, so the only thing it can do is draw the button glyphs at full brightness, which looks bad. Therefore, you can now also pass in the brightness value via the flags, with PR_COLORGLYPH_BRI(255).
2023-01-06 04:43:21 +01:00
);
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
}
Overload font::print text argument for both std::string and const char* Turns out I was overplaying my hand a little when changing font::print from std::string to const char*, so instead, I'll overload the function: it can take either a const char* (the main function) or a std::string (a wrapper). This means any C string that's printed everywhere else (which is common, especially because loc::gettext gives them) no longer needs to be converted to a std::string object each call. Commit 1/3: font::print_wrap -> Commit 2/3: font::print Commit 3/3: font::len
2023-03-05 00:21:52 +01:00
void print(
const uint32_t flags,
int x,
int y,
const std::string& text,
const uint8_t r,
const uint8_t g,
const uint8_t b
)
{
// Just a std::string overload for now because it's more .c_str() to add than I'm comfortable with...
print(flags, x, y, text.c_str(), r, g, b);
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
int print_wrap(
Complete font::print_wrap flag handling Also added some borders to more of the text in room name translator mode, fixed a positioning issue if the interface font is not 8x8, and migrated the trophy texts to font::print_wrap (including PR_COLORGLYPH_BRI that still needed to be done)
2023-01-14 05:16:00 +01:00
uint32_t flags,
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
const int x,
int y,
Change font::print_wrap text argument from std::string to const char* We no longer need to pass a std::string object to the print and len functions - in fact, we often only have a C string that we want to print or get the visual width of (that C string most often comes from loc::gettext), and it's a bit wasteful to wrap it in a new std::string object on every print/len call. This does mean adding a few more .c_str()s, but there's not many places where a std::string is being passed to these functions, and we already use .c_str() sometimes. -> Commit 1/3: font::print_wrap Commit 2/3: font::print Commit 3/3: font::len
2023-03-04 23:29:12 +01:00
const char* text,
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
const uint8_t r,
const uint8_t g,
const uint8_t b,
int linespacing /*= -1*/,
int maxwidth /*= -1*/
)
{
Complete font::print_wrap flag handling Also added some borders to more of the text in room name translator mode, fixed a positioning issue if the interface font is not 8x8, and migrated the trophy texts to font::print_wrap (including PR_COLORGLYPH_BRI that still needed to be done)
2023-01-14 05:16:00 +01:00
PrintFlags pf = decode_print_flags(flags);
if (pf.font_sel == NULL)
{
return y;
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
if (linespacing == -1)
{
linespacing = 10;
}
Complete font::print_wrap flag handling Also added some borders to more of the text in room name translator mode, fixed a positioning issue if the interface font is not 8x8, and migrated the trophy texts to font::print_wrap (including PR_COLORGLYPH_BRI that still needed to be done)
2023-01-14 05:16:00 +01:00
linespacing = SDL_max(linespacing, pf.font_sel->glyph_h * pf.scale);
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
if (maxwidth == -1)
{
maxwidth = 304;
}
Complete font::print_wrap flag handling Also added some borders to more of the text in room name translator mode, fixed a positioning issue if the interface font is not 8x8, and migrated the trophy texts to font::print_wrap (including PR_COLORGLYPH_BRI that still needed to be done)
2023-01-14 05:16:00 +01:00
if (pf.border && !graphics.notextoutline && (r|g|b) != 0)
{
print_wrap(flags, x, y, text, 0, 0, 0, linespacing, maxwidth);
flags &= ~PR_BOR;
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
if (pf.full_border && (r | g | b) != 0)
Add translingual map legend code + border8
2023-10-09 03:22:26 +02:00
{
print_wrap(flags, x, y, text, 0, 0, 0, linespacing, maxwidth);
PR_BOR8 -> PR_FULLBOR, border8 -> full_border
2023-11-16 01:11:32 +01:00
flags &= ~PR_FULLBOR;
Add translingual map legend code + border8
2023-10-09 03:22:26 +02:00
}
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
// This could fit 64 non-BMP characters onscreen, should be plenty
char buffer[256];
size_t start = 0;
if (graphics.flipmode)
{
// Correct for the height of the resulting print.
size_t len = 0;
Change font::print_wrap text argument from std::string to const char* We no longer need to pass a std::string object to the print and len functions - in fact, we often only have a C string that we want to print or get the visual width of (that C string most often comes from loc::gettext), and it's a bit wasteful to wrap it in a new std::string object on every print/len call. This does mean adding a few more .c_str()s, but there's not many places where a std::string is being passed to these functions, and we already use .c_str() sometimes. -> Commit 1/3: font::print_wrap Commit 2/3: font::print Commit 3/3: font::len
2023-03-04 23:29:12 +01:00
while (next_wrap(pf.font_sel, &start, &len, &text[start], maxwidth))
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
{
y += linespacing;
}
y -= linespacing;
start = 0;
}
Change font::print_wrap text argument from std::string to const char* We no longer need to pass a std::string object to the print and len functions - in fact, we often only have a C string that we want to print or get the visual width of (that C string most often comes from loc::gettext), and it's a bit wasteful to wrap it in a new std::string object on every print/len call. This does mean adding a few more .c_str()s, but there's not many places where a std::string is being passed to these functions, and we already use .c_str() sometimes. -> Commit 1/3: font::print_wrap Commit 2/3: font::print Commit 3/3: font::len
2023-03-04 23:29:12 +01:00
while (next_wrap_buf(pf.font_sel, buffer, sizeof(buffer), &start, text, maxwidth))
Add initial version of font::print_wrap graphics.PrintWrap is now also deprecated. An advantage of the new version (with flags) is that it'll be possible to do things like put a border around wrapped text, wrap text at larger scales, etc, but these things don't work perfectly yet. This commit also has some other fixes, like the default advance of 6 pixels for characters 0x00-0x1F in 8x8 fonts.
2023-01-06 16:21:42 +01:00
{
print(flags, x, y, buffer, r, g, b);
if (graphics.flipmode)
{
y -= linespacing;
}
else
{
y += linespacing;
}
}
return y + linespacing;
}
Start rewrite of font system This is still a work in progress, but the existing font system has been removed and replaced by a new one, in Font.cpp. Design goals of the new font system include supporting colored button glyphs, different fonts for different languages, and larger fonts than 8x8 for Chinese, Japanese and Korean, while being able to support their 30000+ characters without hiccups, slowdowns or high memory usage. And to have more flexibility with fonts in general. Plus, Graphics.cpp was long enough as-is, so it's good to have a dedicated file for font storage. The old font system worked with a std::vector<SDL_Surface*> to store 8x8 surfaces for each character, and a std::map<int,int> to store mappings between codepoints and vector indexes. The new system has a per-font collection of pages for every block of 0x1000 (4096) codepoints, that may be allocated as needed. A glyph on a page contains the index of the glyph in the image (giving its coordinates), the advance (how much the cursor should advance, so the width of that glyph) and some flags which would be at least whether the glyph exists and whether it is colored. Most of the *new* features aren't implemented yet; it's currently hardcoded to the regular 8x8 font.png, but it should be functionally equivalent to the previous behavior. The only thing that doesn't really work yet is level-specific font.png, but that'll be supported again soon enough. This commit also adds fontmeta (xml) support. Since the fonts folder is mounted at graphics/, there are two main options for recognizing non-font.png fonts: the font files have to be prefixed with font (or font_) or some special file extension is involved to signal what files are fonts. I always had a font.xml in mind (so font_cn.xml, font_ja.xml, etc) but if there's ever gonna be a need for further xml files inside the graphics folder, we have a problem. So I named them .fontmeta instead. A .fontmeta file looks somewhat like this: <?xml version="1.0" encoding="UTF-8"?> <font_metadata> <width>12</width> <height>12</height> <white_teeth>1</white_teeth> <chars> <range start="0x20" end="0x7E"/> <range start="0x80" end="0x80"/> <range start="0xA0" end="0xDF"/> <range start="0x250" end="0x2A8"/> <range start="0x2AD" end="0x2AD"/> <range start="0x2C7" end="0x2C7"/> <range start="0x2C9" end="0x2CB"/> ... </chars> <special> <range start="0x00" end="0x1F" advance="6"/> <range start="0x61" end="0x66" color="1"/> <range start="0x63" end="0x63" color="0"/> </special> </font_metadata> The <chars> tag can be used to specify characters instead of in a .txt. The original idea was to just always use the existing .txt system for specifying the font charset, and only use the XML for the other stuff that the .txt doesn't cover. However, it's probably better to keep it simple if possible - having to only have a .png and a .fontmeta seems simpler than having the data spread out over three files. And a major advantage: Chinese fonts can have about 30000 characters! It's more efficient to be able to have a tag saying "now there's 20902 characters starting at U+4E00" than to include them all in a text file and having to UTF-8 decode every single one of them. If a font.txt exists, it takes priority over the <chars> tag, and in that case, there's no reason to include the <chars> tag in the XML. But font.txt has to be in the same directory as font.png, otherwise it is rejected. Same for font.fontmeta. If neither font.txt nor <chars> exist, then the font is seen as a 2.2-and-below-style ASCII font. In <special>: advance is the number of pixels the cursor advances after drawing the character (so the width of the character, without affecting the grid in the source image), color is whether the character should have its original colors retained when printed (for button glyphs). As for <white_teeth>: The renderer PR has replaced draw-time whitening of sprites/etc (using BlitSurfaceColoured) by load-time whitening of entire images (using LoadImage with TEX_WHITE as an argument). This means we have a problem: fonts have always had their glyphs whitened at printing time, and since I'm adding support for colored button glyphs, I changed it so glyphs would sometimes not be whitened. But if we can't whiten at print time, then we'd need to whiten at load time, and if we whiten the entire font, any colored glyphs will get destroyed too. If you whiten the image selectively, well, we need more code to target specific squares in the image, and it's kind of a waste when you need to whiten 30000 12x12 Chinese characters when you're only going to need a handful, but you don't know which ones. The solution: Whitening fonts is useless if all the non-colored glyphs are already white, so we don't need to do it anyway! However, any existing fonts that have non-white glyphs (and I know of at least one level like that) will still need to be whitened. So there is now a font property <white_teeth> that can be specified in the fontmeta, which indicates that the font is already pre-whitened. If not specified, traditional whitening behavior will be used, and the font cannot use colored glyphs.
2023-01-02 05:14:53 +01:00
} // namespace font
Reference in a new issue Copy permalink