Open AlanJAS opened 10 years ago
That is something that I would really love. The issue here is that the code is based on a modern terminal emulator in which this function is absolutely unnecessary. We would have basically to completely rethink the way we are drawing the screen, and that's something that will require much work.
I think we can do it easily at the shell side,
when slow mode
enabled, every commands will pipe to a delay program.
eg:
#include <stdio.h>
#include <unistd.h>
int
main()
{
setbuf(stdout, NULL);
for (char c = 0; c != EOF; c = getchar()) {
usleep(10000);
putchar(c);
}
return 0;
}
bash -i | ./slowmode
on @iyzsong's code works great! I change 10000 to 3000 to mimick 300 baud (e.g. 30 10-byte chars pr second), but this could be parameterized. Try starting vi
or top
!
btw - to compile:
gcc slowmode.cpp -o slowmode
Perhaps this should be added to the build and then used as a kind of login shell.
@Swordfish90 I linked two related issues (see above) which you can close as duplicates of this one.
I would totally love this feature by the way. The slow scrolling of simulated BAUD settings makes the retro feeling even more amazing, especially if you play old text adventures or telnet into BBSes.
Here's some videos showing Cathode, which implements baud simulation:
The slow rendering gives a really calm, cool effect.
Wondering if the state of the project has changed in a way that would make this feature possible? I guess you're running some terminal emulation library under the hood which just feeds you with a total buffer of all text to render on screen at the current time. And you then just generate a bitmap of those characters and display it all at once? That's my guess anyway.
But perhaps the rendering routine in cool-retro-term could be modified to add an artificial delay which prints 1 character, waits, prints 1 character, waits, prints 1 character, waits, etc. So instead of generating 1 instant bitmap of all text on screen, you would instead generate multiple textures for several in-between steps, and fade between them over time. Generating so many textures would probably hurt performance, but perhaps in-place updates can be done to replace a single "screen" texture all the time. Or just blitting back and forth between two textures (active and next texture).
Although I don't know how that would interact with things like rapidly scrolling data (i.e. a huge tree
output). The underlying terminal emulator would feed it all to you very rapidly, but perhaps it doesn't update/feed you the next page of data until you're ready and query it for more text. In that case, it should still be possible to implement delayed rendering using this technique. So when the current page has been "delay-rendered", request the next page of updates from the terminal library.
Of course, the best solution would be if the terminal library itself has an "ingest speed" setting that can slow down its gobbling of STDOUT data. Maybe such a setting exists now, all these years later?
One thing that I remeber on a old terminal was the speed. Now, running the cool terminal, when I run one command seems so fast! Maybe would be good add an option to simulate the old hardware.. a "line lag" time used for display each line of a command.