undefined | Better HN

0 pointsqayxc5y ago0 comments

That's only true for TrueType Fonts in graphical mode.

In text-mode, characters are "drawn" by simply writing their ASCII code point into VRAM and writing another byte (two 4-bit values really) in an additional "attribute" buffer to set the foreground and background colour.

Programmers can swap out the default character set to provide their own typeface and graphical characters for use as window borders, shadows, etc.

(S)VGA text-mode is as cheap as it gets in terms of computational complexity.

0 comments

5 comments · 2 top-level

ezoe5y ago· 3 in thread

Come on. We had long past the ASCII only era.

naikrovek5y ago

For people downvoting this guy, he's saying we're long past the ASCII era, and he is NOT saying we're long past the TEXT era.

It's the America-centric ASCII stuff that we're past, not plain text itself.

UTF-8 forever!

FlyMoreRockets5y ago

ASCII is eternal

dividedbyzero5y ago

Tell that to the French, Germans, Russians, Chinese, Japanese, Koreans, Spanish, Norwegians, etc. pp.

JdeBP5y ago

This sort of thing hasn't been done with the display adapter in a text mode for a decade or so, now, even on PC-compatible hardware. Even terminal emulators of this sort on Linux and the BSDs use the display adapter in graphics mode, drawing glyphs from loadable (bitmap) fonts. The sorts of systems that mysterydip was talking about might not even have hardware that provides an old-style MDA/CGA/EGA/VGA text mode, moreover.

This in addition to the fact that, as others have pointed out, the old-style text mode really doesn't lend itself well to Unicode, to the new (sic!) terminal colour systems of the 1990s, nor to proper boldface+underline+italics. (The latter is one of the reasons that commercial DOS programs from 1-2-3 to Quattro Pro were switching display adapters into graphics mode and rendering their TUIs by drawing graphics, with BGI in the case of Borland, back in the late 1980s and turn of the 1990s.)

With post-VGA blitting capabilities one can of course do things like pre-load glyph bitmaps into off-screen video RAM and blit them into the display, potentially a lot faster than having the main processor write the glyphs directly; but it is still not as simple as writing 16-bit character+attribute pairs, to do what modern users generally regard as the basics of TUIs in these modern Unicode, 24-bit colour, full ECMA-48 attribute support times.

j / k navigate · click thread line to collapse