1
0
mirror of https://github.com/TerryCavanagh/VVVVVV.git synced 2024-06-26 06:28:30 +02:00
VVVVVV/desktop_version/src/Font.h

127 lines
4.2 KiB
C
Raw Normal View History

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
/*
* == SOME TEXT PRINTING EXAMPLES ==
*
* Standard print
* font::print(0, 50, 50, "Hello world!", 255, 255, 255);
*
* Centered text
* font::print(PR_CEN, -1, 50, "Hello world!", 255, 255, 255);
* (set X to -1, unless you want to center *around* X)
*
* 2x scale
* font::print(PR_2X, 50, 50, "V", 255, 255, 255);
*
* Centered 2x scale
* font::print(PR_CEN | PR_2X, -1, 50, "V", 255, 255, 255);
*
* Right-aligned 3x scale with a border around it
* font::print(PR_RIGHT | PR_3X | PR_BOR, 320, 50, "V", 255, 255, 255);
*
* Wordwrapped centered text
* font::print_wrap(PR_CEN, -1, 50, "Hello world, this will wordwrap to the screen width", 255, 255, 255);
*
*/
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
#ifndef FONT_H
#define FONT_H
#include <SDL.h>
#include <stdint.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 <string>
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
#define PR_1X (0 << 0) /* default, 1x scale */
#define PR_2X (1 << 0) /* 2x scale */
#define PR_3X (2 << 0) /* etc */
#define PR_4X (3 << 0)
#define PR_5X (4 << 0)
#define PR_6X (5 << 0)
#define PR_7X (6 << 0)
#define PR_8X (7 << 0)
#define PR_FONT_INTERFACE (0 << 3) /* default, use interface font */
#define PR_FONT_LEVEL (1 << 3) /* use level-specific font (room names, cutscene dialogue, etc) */
#define PR_FONT_8X8 (2 << 3) /* use 8x8 font no matter what */
#define PR_FONT_IDX(idx, rtl) /* use given font index */\
(((SDL_clamp(idx, 0, 28) + 3) << 3) | (rtl ? PR_RTL_FORCE : 0))
2023-01-31 02:22:43 +01:00
#define PR_BRIGHTNESS(value) /* use this brightness 0-255 for the text (accounts for button glyphs correctly) */\
(((~SDL_clamp((int)(value), 0, 255) & 0xff) << 8))
#define PR_FULLBOR (1 << 16) /* draw a black border around the text, filling in the corners (for the map legend) */
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
#define PR_BOR (1 << 17) /* draw a black border around the text (was bprint/bigbprint) */
#define PR_LEFT (0 << 18) /* default, left-align text/place at x coordinate */
#define PR_CEN (1 << 18) /* center-align text relative to X (X is center) or to screen if X == -1 */
#define PR_RIGHT (2 << 18) /* right-align text to X (X is now the right border, not left border) */
#define PR_CJK_CEN (0 << 20) /* default, larger fonts should stick out on top and bottom compared to 8x8 font */
#define PR_CJK_LOW (1 << 20) /* larger fonts should stick out fully on the bottom (draw at Y) */
#define PR_CJK_HIGH (2 << 20) /* larger fonts should stick out fully on the top */
#define PR_RTL_FORCE (1 << 22) /* force the RTL flag, not needed if the font is set to INTERFACE or LEVEL */
#define PR_RTL_XFLIP (1 << 23) /* in RTL languages, mirror the X axis, so left is 320 and right is 0, and invert the meaning of PR_LEFT and PR_RIGHT */
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
#define PR_FONT_IDX_IS_CUSTOM (1 << 24) /* with PR_FONT_IDX, mark that the font index is of a custom font */
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
namespace font
{
// Options in font selection menu
extern uint8_t font_idx_options_n;
extern uint8_t font_idx_options[20];
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
extern uint8_t font_idx_level;
extern bool font_idx_level_is_custom;
bool find_main_font_by_name(const char* name, uint8_t* idx);
const char* get_main_font_name(uint8_t idx);
const char* get_main_font_display_name(uint8_t idx);
const char* get_level_font_display_name(void);
uint8_t get_font_idx_8x8(void);
bool level_font_is_main_idx(uint8_t idx);
void set_level_font(const char* name);
void set_level_font_interface(void);
void set_level_font_new(void);
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);
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
void unload_custom(void);
void destroy(void);
std::string string_wordwrap(uint32_t flags, const std::string& s, int maxwidth, short *lines = NULL);
std::string string_wordwrap_balanced(uint32_t flags, const std::string& s, int maxwidth);
std::string string_unwordwrap(const std::string& s);
bool glyph_dimensions(uint32_t flags, uint8_t* glyph_w, uint8_t* glyph_h);
int len(uint32_t flags, const char* text);
int height(uint32_t flags);
bool is_rtl(uint32_t flags);
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(
uint32_t flags,
int x,
int y,
const char* text,
uint8_t r, uint8_t g, uint8_t b
);
// std::string overload for only font::print (use .c_str() for the others)
void print(
uint32_t flags,
int x,
int y,
const std::string& text,
uint8_t r, uint8_t g, uint8_t b
);
int print_wrap(
uint32_t flags,
int x,
int y,
const char* text,
uint8_t r, uint8_t g, uint8_t b,
int linespacing = -1,
int maxwidth = -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
} // namespace font
#endif // FONT_H