Comment by weinzierl
1 day ago
Sure, but that's beside the point.
Text based graphics with fancy or custom fonts is just crazy efficient. That is exactly how we got the amazing graphics of The Last Ninja or Turrican on machines with less than 64KiB useable RAM.
Same for more modern embedded devices. If you constrain yourself to text you increase both runtime performance and your developer productivity.
It was crazy efficient on character or tile-based hardware. It makes no difference on bitmap displays, or rather adds some overhead.
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.
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.
10 replies →
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.
4 replies →
Are you claiming that scrapping together boxes and whatnot with line drawing characters is more efficient than just drawing the lines directly?
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.
For simple SPI displays it's the transfer bandwidth that dominates, so for best performance you wanna minimize the number of pixels you need to send. So for eaxmple: if you wanna draw a 100 pixel long horizontal line, if you ever send more than 100 pixels of data you're not gonna hit the speed of light. And if you wanna draw an angled line you're gonna have to do something like bresenham and pixel by pixel because drawing NxN blocks for a 45 degree line would be insane.
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 character symbols.
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).
SSD1306 is a bit in the middle. It's technically a 128x64 monochrome bitmapped display, but it's organized as eight 128x8 "rows", with each byte representing a single 1x8 group of pixels. That organization really favors being treated as either four or eight lines of text - trying to use it as a generic bitmap display gets awkward, because it's only addressable at the level of those 1x8 groups.
ST7735 is more of a standard (color) bitmap display.
SSD1306 is just 1KByte for a second buffer, so even a rather low-end MCU likely can spare that. And you'd absolutely just draw normal lines if you use a display like that.
It's very easy to use it as a generic bitmap display, there's nothing awkward about packing 8pixels into 1 byte, and you can set the addressing mode (horizontal/vertial) to whatever you want, etc.