I would like to modify certain coordinates on the terminal screen for example. How would I be able to draw, say, char c at x, y? All I know is that the terminal outputs chars and scrolls up like a typewriter.

I'm talking about a graphics-based game that plays out on the terminal in all it's ASCII glory. Do you have a big char buffer and just clear/write it? How does something like that work?

Any help, thanks

I think you typically use something like ncurses. It literally has a function that allows you to print stuff at the location you want.

No idea how it actually works underneath the hood though .

You will probably want to look into the curses library family... Generally there's the problem of different terminals speaking different "control characters" so you will certainly want a library to do it. In the general sense, control characters written as bytes to the terminal device (just as with any other data) are specially interpreted... Knowing that you can achieve dynamic content on supported terminals and emulators.

/beaten

In case you're curious, such library typically relies on the terminal's support of some character sequences, especially using the characters with codes in the 0-31 range.
For example in a MS-DOS or Linux/Unix console, printing the C string: "\x1B[10;12H" would move the cursor to position 10, 12
( \x1B is the single character of ASCII code 27: 'ESC')
http://www.real-world-systems.com/docs/ANSIcode.html

Yeah, ANSI-codes are fun. Didn't work on Windows, though, last time I tried.
There might be old conio.h support on some Windows compilers, I believe there is also Windows API stuff to clear a terminal screen and to do other things. You can hack together some simple abstraction if you feel like it.

I don't think cmd.exe supports ANSI. At least, not colors... I have a Mercurial wrapper that toggles the color configuration setting so that paged things that are piped to less use "ansi" and unpaged things use "win32" codes, whatever that means, but I imagine it's custom...

Reminds me of my time maintaining a MUD Clients connected using telnet, color codes...
Nowadays there is a running "Nyan cat" server if you want to see how your telnet.exe supports the standards
http://nyancat.dakko.us/

conio.h would make the work too. I don't know if any modern compiler still support it though. Free Pascal has CRT units.

Ways to do it (links in Python):

• curses

• Emacs Lisp (because terminals are weird)

• STFL

• Urwid

• npyscreen

Input is a key concept. You wait for a character (not keypress) to appear. Any notion of a key being held down is limited by users' key repeat rates and your ability to hack around them. Ｄｏｕｂｌｅ－ｗｉｄｔｈ　ｃｈａｒａｃｔｅｒｓ require extra care. I have found developing within XTerm (maintained by the same maintainer as ncurses) has provided peace of mind, as XTerm is ubiquitous and goes hand in hand with ncurses.

Draw text the way the terminal does naturally--left to right, top to bottom. Doing otherwise can slow down your program.

Have you considered "emulating" terminal?

Terminal
+ Works over SSH / etc
- Bandwidth issues
- Features are only available per terminal software support
- Portability problems (UNIX color codes on UNIX, Windows/UNIX both support different resolution sizes, as well as line ending encoding)

Emulated:
+ No need for users to have a terminal
+ Simulate any features as needed
+ Faster draw rate
- No actual terminal support, so no cool SSHing

Remember Dwarf Fortress? They moved over to emulated terminal so that people could easily switch out text characters with graphic tilesets.

One thing I've loved that most people never saw: You can edit font glyphs in real time in DOS. So you can actually draw "graphics" in text mode.

All of these are standard 16-color (<- IIRC) text mode from the same game system:

{"name":"maxresdefault.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/a\/fa78507cc38ac3f6b2fadc282ed78f88.jpg","w":1920,"h":1080,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/a\/fa78507cc38ac3f6b2fadc282ed78f88"}

{"name":"320px-And.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9e2fbec0f4787576e8ed8441ae20fe5.png","w":320,"h":175,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e9e2fbec0f4787576e8ed8441ae20fe5"}

{"name":"glade03.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f450e5c723857228a8bafd4b07987eb.png","w":592,"h":322,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/f\/0f450e5c723857228a8bafd4b07987eb"}

{"name":"ejet2.gif","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4585810b48b3964a7a5cdd6f9614de9.gif","w":640,"h":350,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/4\/a4585810b48b3964a7a5cdd6f9614de9"}

MegaZeux was a spiritual successor to ZZT and basically "ZZT on crack". Some of my first games ever were made in MegaZeux.

I loved working within the constraints of 256 glyphs of ~16x8 bicolor, 16 colors total. You could do "animations" by changing glyphs--either replacing one character with another, or changing the glyph itself. (Like a bitmap version of palette swapping. Changing the glyph changed all characters using it.) You could do bigger characters by combining glyphs together.

People did INSANE stuff with Megazeux like doing actual animated cutscenes by spamming glyph and palette color changes each frame.

Megazeux also supported MODs/S3ms.

This is text mode!

I have actually, but it's not something I'm interested in. The purpose of this project would be to have a terminal window with graphical output alongside other programs in a multi-pane terminal session.

Emulating an ASCII-only display in, say, a Allegro is a bit overkill since I'm actually going for "underkill"

I had never heard of MegaZeux until now. Had it come along at the right time in my life, I would have fallen head over heels for it. S3M support seals the deal.

Thanks for the history lesson.

Megazeux correction, it was VGA text mode so you have a 64-color (real-time adjustable) palette. This video explains the details of how the software works.