optimised rendering for large areas
derhuerst opened this issue · comments
Using breseham for drawing every shape is extremely convenient, but the visual noise is significant. It might be better to render continuous, large surfaces with a background color, e.g. using chalk.
the borders of the area would look different however, so this would require some further investigation.
Nice idea which actually was kinda implemented at some point with mixed results (especially the feature-borders as you guessed) - had all water surfaces filled with background colors once with no need for chalk though, as the Canvas and BrailleBuffer already got background color support in them :)
So it would be a matter for the Canvas/Renderer - maybe first step to try around/see how it would look, would be to add the logic to respect the features' background-color style property, which currently is only pulled in for the global background color.
[edit: typo]
Also, an approach to improve the visual quality might be to reduce shapes like large roads to a single line.
Drawing lines are problematic as it is difficult to connect them with the limited set of plain-text symbols. Using braille patterns is a smart solution, but there are also block characters (including those from the OEM PC charset) which would effectively better to render surfaces (outside lines and text labels)
Finally an option to set the prefered encoding and terminal emulation would be fine for compatiblity (the default telnet client in Windows does not support this Xterm emulation, but supports VT220, restricted to 8-bit charsets, and "ANSI.SYS" emulation for its native console.
For Windows 10 the anternative is to install the optional Ubuntu Bash feature supported by Microsoft. Still it does not render any one of the Braille patterns, probably because of font exclusions (not suitable for monospace rendering) so we also see "?" in square boxes instead of Braille patterns: here also using the symbols in the PC OEM subset would work.
These terminal settings could go to a "c" config key. Also adding the "?" key to show the help screen and some of the current terminal settings (including the terminal size in rows/columns) would be helpful to avoid the irritating text scrolls (use the clear screen terminal command, and make sure you won't use display anything on the last column of the last row).
As well, some labels will cause problems when they are not restricted to basic European alphabets (Latin/Greek/Cyrillic) or some half-width Japanese Kanas/Hangul Jamos, as they are not always rendered with a monospaced fonts (or not rendered at all in some terminals): this includes various Arabic characters. Sinograms and Hangul clusters could work but would be using two columns
Just an FYI, I've experimented with using ASCII 220 and 223 half-block characters for raster images here, and have had success on Windows:
Yes but windows terminal supports any characters that are in the following suitable monospaced fonts:
- Terminal (8-bit OEM encoding): supports [▀]2580, [▄]2584, [█]2588, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC
- Courrier New (Unicode), supports [▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC
- Consolas (Unicode), supports the same subset as Courier New
- Lucida Console (Unicode), supports the same subset as Courier New
- MS Gothic (Unicode),
- NSimsun (Unicode),
- SimSun-ExtB (Unicode),
- Noto Emoji (Unicode),
- Noto Moto (Unicode),
- and legacy raster fonts for DOS terminals, encoded in legacy 8-bit OEM codepages (multiple versions are installed with distinct resolutions for CGA, EGA, VGA: 6x8, 8x8,16x8, 5x12, 7x12, 8x12, 16x12, 12x16, 10x18).
In summary, we can still improve bitmap emulation with additional symbols [▌]258C, [▐]2590 with vertical subdivisions of the character cell, or [■] 25A0, [▬]25AC for additional horizontal subdivisions of the character cell, or [░]2591, [▒]2592, [▓]2593 for better approximation of pixel patterns.
What is needed is a function that evaluates the rate of error for each candidate character when it is used to approximate a rectangular colorful bitmap, and selecting two representative colors (not the same pairs for dot pattern characters and for block characters), and then having a simple sort to select the best (character,color pairs, error) member to get the actual (character,color pair) to use.
To create such evaluation function, the best is to have a basic monochromatic bitmap data representative of the character, at everage terminal font sizes (ignoring cleartype): typically for 12pt font sizes.
Then that function can be extended to include as well several other box drawing characters also supported in these fonts.
An optional extension would evaluate all candidate characters of the OEM character set (including Latin and Greek letters, digits, punctuation), unless they are disabled to represent something else such as actual text labels for the map.
We may then return two versions of text-rendered bitmaps: one for 8-bit legacy OEM codepage, another for the Unicode codepage. This would result in two terminal emulations:
-
ANSI.SYS/OEM for old Windows versions (Win95/98) that don't have any Unicode API and whose terminal output is restricted to display only characters in the current 8-bit codepage,
-
ANSI.SYS/Unicode for modern Windows with native Unicode API not needing the unicode emulation layer (WinXP, Vista, WinNT, Win2000, WinServer, Win7, Win8/8.1 and Win10), where the terminal displays any characters (even those outside the current display codepage selected by "CHCP") but its display memory is an array of 16-bit WCHAR instead of an array of 8-bit CHAR.
To see what it can give on a Windows terminal, just copy paste this line in the terminal:
[▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [░]2591, [▒]2592, [▓]2593, [■] 25A0, [▬]25AC
This will convince you that it is possible to offer a better rendering of bitmap images than just using the first 3 characters of this list, and still better than using Braille dot patterns, not supported except if your windows terminal uses one of the two supported Unicode codepages (as set by "CHCP 65000" for the legacy UTF-7 encoding, or "CHCP 65001" for modern UTF-8 encoding)
Note that the Windows terminal used by the "Ubuntu Bash" extension on Windows 10 is set by default to use codepage 650001 (UTF-8), and its default font selected is "Consolas" (you can change this font but cannot change the 65001 codepage used and you cannot start a windows command to run CHCP because all programs in "/mnt/c/Windows/System32" are restricted and not readable/executable under this Linux environment). And in the list of monospaced fonts I have given above and that are recognized as suitable for the Windows terminal, none of them have Braille dot pattern symbols (which are currently only found in fonts that include other characters with variable width, notably for alphabets, but also various other symbols with distinct metrics).
To use Braille patterns in a Windows console, you need to install a separate font (Unicode encoded) containing only them, or containing other alphabetic letters in monospace style (you could include the same subset of characters as the small subset supported by the Terminal Truetype font).
A solution for this is to install a "font server" driver that would allow creating a custom synthetic font, taking its source glyphs from one or more fonts and adjusting their metrics), in order to emulate a real monospace font (without having to create and install any new font, or stealing their glyph data to create a new standard font). Such font server drivers are supported by the Windows API and used notably to support wellknown Adobe softwares, or to support fonts in other formats (such as legacy fonts for Linux text terminals, or the legacy *.FON bitmap fonts for DOS text terminals), or font server drivers that support the new SVG fonts, or legacy X11 fonts, or the many existing PostScript fonts, or legacy PCL fonts used by old HP printers that did not have support for TrueType or PostScript.
Thank you for all your wonderful high quality input @verdy-p !
Based on it, i just started to work on a mapping logic for the currently 2x4 sized, bit operation based BrailleBuffer. It will map all possible characters to the most-pixel-overlaying ▀ ▄ █ ▌▐ ▓ ■ ▬ equivalent and will allow an easy implementation without touching too many other parts of the current logic. Let's see how that goes and how we can continue from there ;)
The next logical step would indeed be the automatic terminal type detection and giving the user the choice to switch during runtime.
Thanks again!
This looks already so much better than i expected 😮 mapper works, just finishing up -> push ;)
preview:
so vivid!
Looks great! More characters available with full Unicode: ◢, ◣ , ◤ , ◥.
made the algorithm smooth and working well, merged to master! currently used charset is for now:
[▀]2580, [▄]2584, [█]2588, [▌]258C, [▐]2590, [■] 25A0
Updated the telnet cluster as well, try out the current implementation by connecting and pressing c - cheers!
It would be better to out "clear screen" (or moveto row1/col1) before
refreshing the map over the existing page, instead of scrolling text. This
is very irritating to see this scroll !
this actually is already implemented - see Renderer.coffee