Evžen Wybitul wrote on 06/19/2018 07:21 AM:
>
> Pretty cool, didn't know about this! So let's say I now can display a
> "@" char with whatever color wherever I want. Then there is only a
> last thing I need to know how to do before I can ditsch the libraries —
>
> 1. How do I open a new, clear terminal window from within racket? Kind
> of like what happens when I use big-bang (a black rectangle in a
> window opens), but with terminal instead. You know, I don't want to be
> drawing into the terminal the user inputs his /racket main.rkt/.
Like Alex and Martin said, when your Racket program is running in a
terminal, you probably want to use that terminal (saving and restoring
the page, ideally, which most terminals nowadays support).
However, there are a couple ordinary scenarios in which a terminal might
not be available:
* Running a terminal program from a GUI desktop interface that doesn't
create the terminal window automatically.
* Running a terminal program under development from DrRacket, and there
is no terminal window for it to use.
What I'd suggest doing (coincidentally, this was on my Rust TODO list),
is make a package/procedure that, if no terminal is available, it
attempts to create the terminal, in a platform-specific way. It could
look through a list of possible commands for one that is available
("xdg-terminal", "x-terminal-emulator", "urxvt", "rxvt", "xterm",
"konsole", "gnome-terminal", etc.). It might be easiest to do portably
across Un*xen by not getting into subtleties of TTYs, and instead using
the command line for that terminal emulator program to invoke another
instance of your Racket program.
> Can I make it so that only the two changing tiles get redrawn, not the
> entire scene? Normally, the entire rectangle would be drawn "under"
> the old one; I haven't yet looked into the ANSI wikipage, so maybe
> there's an answer there — if so, I'm sorry.
Like Alex said, you can do the drawing incrementally from your
application code (the terminal itself has at least one persistent screen
buffer, and this is the interface that ANSI X3.64 provides), and you
don't normally need to refresh/redraw it from application code, like
many GUI drawing interfaces would have you do.
However, two reasons why you might want to use/make a library that *can*
do a complete or partial redraw of the terminal screen, even though the
terminal remembers what's on the screen:
* You can have display corruption, such as due to a window resize, or
other sources of text going to the screen (from, e.g., error messages,
systems notices, or "line noise").
* You might want to implement GUI elements that temporarily obscure part
of the display (e.g., inventory menu in a roguelike), and the redraw them.
You might prefer to use an interface like "curses" that can handle these
redisplays, or implement a library like that yourself. And it can also
let you make your changes to a display state in the program, and the
library figures out an efficient set of terminal control codes to update
the terminal's display from what the library thinks it currently is.
(The efficiency of updates usually isn't important anymore, since you
can usually redraw an entire display in an instant over a slow SSH link
from halfway around the world. But most old hardware terminals on which
you might want to proudly display your roguelike, in your living room,
still max out at around 1000 to 2000 bytes per second when wired direct
to an RS232 port, and a single attribute change takes a few/several
bytes in ANSI, so it could take you a few seconds to redraw a pretty
ordinary display even on a direct wired line.)
BTW, if you're looking for an old terminal for your roguelike, a DEC
VT102 is mostly ANSI, and has a couple important features that a VT100
doesn't, while still being very retro. A VT220 or VT320 is also a good
choice, more features, not as retro. There are a ton of other old
terminals, and some with some archaic but neat properties, but, once you
start needing ANSI, they usually look more modern and boring. (BTW, you
might be able to fit a Raspberry Pi and peripherals inside a VT102
chassis, without interference or overheating, which would be a fun
living room computer appliance for a roguelike, sadistic guest `elinks`
Web browser, Kodi controller, etc.)