in reply to Fun with terminal color
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^2: Fun with terminal color
by cavac (Prior) on Feb 10, 2024 at 13:31 UTC | |
TTY Quake uses AALib, which is from 1997. There's a a demo called "bb" to show off its features, as well as Text::AAlib perl bindings. I have no idea how many Terminals support full RGB color, but it seems more and more do these days. I was able to double the vertical resolution by printing a Unicode Upper Half Block character and setting both it's foreground and background color. The escape codes are quite bulky, though. To increase FPS, i remember the last colors used and only send color changes when needed. Nevertheless, screens with lots of color changes result in a much lower FPS that ones with a uniform background and only a few, big colored areas. To make a colored "doublepixel", this is essentially how it looks:
In reality, i internally hold an array of pixels (basically, my graphics memory), then render the whole screen into a big string, THEN output the string all at once. This avoids flickering the cursor all over the screen and increases the framerate as well.
My code is far from optimized, because i keep tinkering with it and optimization would make that much harder. If i reorganize how the data is layed out in memory, i could (potentially) rewrite the output function in C for better performance. But i'm currently not sure if one of the bottlenecks isn't simply the STDOUT output pipe to the Terminal. But potentially, with optimized code on a modern computer (mine is 12 years old), you could get 100s of frames per second. (Edit: Flattened image structure, pushed to mercurial. Still have to look into doing something with Inline::C) There's also the possibility to go pure black&white, but increase the resolution to 4 pixels per character with the clever use of a combination of Unicode block characters. This would work quite well for line graphics and pencil sketches. Another possible optimization would be to basically diff the current and previous image and only update the areas that have changed by jumping the cursor directly to that area. And example where that would be quite effective is the scroller in my demo. Frame-by-Frame, only about roughly 30% on average (probably less) of the screen lines change, and even those might have long stretches of unchanged characters. Basically, what you would do is to paint an interframe instead of a keyframe, to borrow from mpeg terminology. (Edit: Implemented the line-by-line buffering and pushed it to mercurial. It gives a somewhat higher framerate when not much is changing on screen. The "partial rows" update doesn't seem worth the hassle at the moment) Additional links:
PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
| [reply] [d/l] [select] |
Re^2: Fun with terminal color
by cavac (Prior) on Feb 11, 2024 at 14:35 UTC | |
I can now answer the question What is the size of a single frame though?: When the whole screen updates, i have to push (depending on the image) roughly somewhere between 400kB and 600kB to the Terminal.
PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
| [reply] |