| > Embedded-graphics includes bitmap fonts that have a very limited set of characters to save space (ASCII, ISO 8859 or JIS X0201). This makes it impossible to draw most of Ratatui's widgets, which heavily use box-drawing glyphs, Braille, and other special characters You have a bitmap display, you can just draw lines and stuff without needing to rely on font-based hacks. |
| |
| ▲ | Johanx64 a minute ago | parent | next [-] | | The same isn't true for modern embedded devices, they don't have tile rendering hardware.
If you connect a i2c/SPI screen (SSD1306, ST7735), you write all the pixels on the screen (or pixels to some subregion of the screen), these screens do have a backing memory in them. So in order to draw a line, you will - objectively - have to copy/move more bytes if you approximate line with a character symbol. This isn't a big deal, but crazy efficient it is not. All the efficiency when drawing on those screens mostly relies on how well you chain together DMA transfers to portions of the screen you want stuff to be drawn to, so that SPI transfers aren't blocking the CPU (that's assuming you don't have memory for a second full-screen buffer). | |
| ▲ | orbital-decay 2 hours ago | parent | prev | next [-] | | It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead. | | |
| ▲ | weinzierl 2 hours ago | parent [-] | | At the end of the day it's always pixels - alway has been [1] - and the efficiency of storing and blitting a small number of fixed size rectangles is hard to beat if you can get away with it. [1] Except for the early oscilloscope style vector displays maybe. | | |
| ▲ | gmueckl an hour ago | parent | next [-] | | No, this is technically not fully correct. Early text based display output systems were relying on special character generator hardware to generate the display signals producing the text on screen. Those systems did not have any means of generating arbitrary pixel patterns. | | |
| ▲ | weinzierl an hour ago | parent [-] | | Do you have an example? All the 8-bitters I know drew the characters from memory, which was a character ROM per default but could be changed either with a screw driver or by bank switching some RAM in-place. EDIT: If you mean they were not copied in a frame buffer first, you are right. I should not have written 'blitting'. | | |
| ▲ | awkwardleon an hour ago | parent | next [-] | | Maybe too old to be applicable here, but the TRS-80 Models I and III (and probably more models) had no way to address pixels. You had to use semigraphic characters to emulate larger blocks at sub-character resolutions. https://bumbershootsoft.wordpress.com/2022/01/28/touring-the... | |
| ▲ | adiabatichottub 20 minutes ago | parent | prev | next [-] | | I recommend reading the TV Typewriter Cookbook. https://archive.org/details/tvtcb_doc | |
| ▲ | direwolf20 an hour ago | parent | prev | next [-] | | With character RAM you can still only have up to 256 unique 8x8 blocks on screen. | |
| ▲ | LoganDark an hour ago | parent | prev [-] | | The character ROM was not read and processed by the CPU. The CPU set some bytes in video RAM, which served as indexes into the character ROM by the video output hardware. I believe on some systems there were some tricks that allowed some bitmap display by redefining glyphs. One example off the top of my head is The 8-Bit Guy's Planet X2, which can use text mode but with glyphs redefined to use for icons, units, terrain, UI, etc. |
|
| |
| ▲ | orbital-decay an hour ago | parent | prev [-] | | Character-based hardware only stores the characters and the grid instead of the full bitmap for the frame, which is very efficient memory-wise. Tile-based hardware (e.g. most console graphics chips in the 8/16 bit era) also had scrolling and layers, and was extremely memory-efficient as well. With bitmap displays you already store full frames. | | |
| ▲ | weinzierl an hour ago | parent [-] | | Sure. Maybe I should not have written 'blitting' when the rectangles are not copied from one memory location to another but end up directly on the screen. My original point that putting a fixed number of small and fixed rectangles on a screen is more efficient than line drawing still stands though. |
|
|
| |
| ▲ | zokier 2 hours ago | parent | prev [-] | | Are you claiming that scrapping together boxes and whatnot with line drawing characters is more efficient than just drawing the lines directly? | | |
| ▲ | LoganDark an hour ago | parent [-] | | I think they're claiming that having character-based pipelines and algorithms can be more efficient than doing everything on the level of pixels... I can't help but feel there's a middle-ground somewhere, though. |
|
|
