Resizing Terminal Screen

[Pueo]

I'm having trouble with my C/nCurses setup.  When I call "resizeterm" or "resize_term" (I'm not sure what the difference is), either nothing happens, or my terminal window disappears.  I've also tried "is_term_resized" and I get a non-null character, so I should be able to resize the terminal.  It's a little frustrating, since I do want to eventually distribute this, and it's no good if everyone has to manually resize their terminal.  Also, to clarify, I want to resize the physical screen (that you see on the monitor and has a little title bar near the top), not the virtual screen in the curses window.

Right now (as a little test run) I have:

Code: [Select]

#include <ncurses.h>

int main()
{
    initscr();
    resize_term(34, 142);
    getch();
    endwin();
}
Is that correct?  Should the first integer in "resize_term" be the rows, or the columns?  Should "resize_term" be "resizeterm?"  Should "resizeterm" be before or after "initscr()?"

Short Version:
Question: How do you properly use "resizeterm" (or "resize_term") in order to reliably resize a terminal on almost any machine?
Note:  I want to resize the physical terminal screen, not the virtual screen used by Curses.

[yam655]

Have you looked at the man page for these functions?

http://linux.die.net/man/3/resizeterm

These do not -- can not -- resize a terminal window. These resize the ncurses-internal data structures associated with the terminal.

Did you read this bit?

While these functions are intended to be used to support a signal handler (i.e., for SIGWINCH), care should be taken to avoid invoking them in a context where malloc or realloc may have been interrupted, since it uses those functions.

SIGWINCH is the signal sent to a terminal application when the window it is running in is resized. That is, the user either manually resized the window or changed the font so that contents have been resized though the bounds remain the same.

There is one escape sequence that can resize a terminal -- and that toggles between 80 column and 132 column modes and is rarely supported. It's a genuine xterm escape code -- much like the Techtronix mode is a standard xterm feature that is rarely implemented in terminals advertising themselves as "xterm".

I recommend you do what some roguelikes do: develop a tight dependency on a particular terminal emulator, and use a two-phase process where the "initial" application is just a script that passes arguments to the terminal emulator setting the window resolution, size and font and specifying that it needs to run the "real" executable instead of a shell. There may be standard command-line arguments you can use for this in the general case, but I wouldn't trust them to be universally supported by all terminal emulators. (They should be tested before they're enabled by default.)

The script can easily test for a DISPLAY to see if it can launch the terminal emulator or if it needs to make-do with an unknown lying POS terminal emulator.

I've given up on writing terminal-based games because the terminal emulators are generally crap and it's become the norm for terminal application developers to jump trough insane hoops to work-around lying terminal emulators and incomplete Terminfo data.

Ncurses should be able to know if the terminal emulator has 0, 8, 16, 88, or 256 colors. Official "xterm" terminal emulators have shipped with all of these settings as defaults in the past.

Oh, but now even though ncurses knows that "xterm" is only 16 color, if you ignore that and send xterm-256color escape codes sometimes it will still work.

If TERM is set properly -- and the system even has the "xterm-256color" Terminfo data -- ncurses can handle all 256 colors automatically. It can even tell you when you can arbitrarily redefine the 256 colors. Awesome stuff -- but it only works if the terminal emulators and the Terminfo data is correct -- which it almost never is.

I wish you luck.

[Pueo]

I've given up on writing terminal-based games because the terminal emulators are generally crap and it's become the norm for terminal application developers to jump trough insane hoops to work-around lying terminal emulators and incomplete Terminfo data.

...snip-snip...

I wish you luck.

Thanks for the reply; sorry for my pretty late reply. :/  What do you (personally) do when you want a non-terminal based game that still has the "feel" of a terminal-based game?  What kind of languages do you use?

Thanks

[requerent]

HaXe is a good way to go, or Flash. Really easy to set up. Nolithius' Dance of Death looks the part using flash.

http://www.nolithius.com/dod

Should take you to the code for his Screen class.
http://code.google.com/p/dance-of-death-worldgen/source/browse/#svn%2Ftrunk%2Fsrc%2Fcom%2Fnolithius%2Fdodworldgen%2Fscreen

[Ancient]

What do you (personally) do when you want a non-terminal based game that still has the "feel" of a terminal-based game?

Use libtcod, fpcvalkyrie, libjcsi, noteye ... you name it.

What kind of languages do you use?

A good kind. I could recommend you my favorites but that would be missing the point. Pick any you are familiar with and go with it.

[Krice]

Use libtcod, fpcvalkyrie, libjcsi, noteye ... you name it.

Does any small gui style console library for C/C++ exist? Other than curses or libtcod which both seem very intrusive, forcing to do stuff their way.

[Pueo]

HaXe is a good way to go, or Flash. Really easy to set up. Nolithius' Dance of Death looks the part using flash.

I'm looking into HaXe now, one of my main 'wants' in a language is portability.

[yam655]

I've given up on writing terminal-based games because the terminal emulators are generally crap and it's become the norm for terminal application developers to jump trough insane hoops to work-around lying terminal emulators and incomplete Terminfo data.

...snip-snip...

I wish you luck.

Thanks for the reply; sorry for my pretty late reply. :/  What do you (personally) do when you want a non-terminal based game that still has the "feel" of a terminal-based game?  What kind of languages do you use?

Thanks

Personally? I'm a fan of Python and PyGame. Of course, I'm a fan of Python 3 and PyGame's been slow to port from Python 2, so at one point I started a PythonTk terminal-like thing.

I've had problems restarting and changing interface libraries. I think at one point I started a similar project for PyGame before I decided Python 3 was so much better that I needed to migrate my code. The only problem with Python is that so much of the support library code hasn't been upgraded to Python 3.

At one time I was going to write a Roguelike in C. If I were to do that today and wanted a traditional interface, I'd just marry it with the PuTTY/MinTTY user-interface. You'd need a solution for Mac OS X, but doing that would get you Linux and Windows.

I've finally stopped churning my own codebase long enough that I have my own user-interface project. It's called Blacken and it is inspired by Curses. <https://code.google.com/p/blacken/> It's 100% Java.

In general, I hate Java. The only reason for anyone to program a Roguelike in Java is (1) they're straight out of university and that's what they were taught there, or (2) they have a day-job using Java.

I have a day-job using Java.

If I were doing a Roguelike in C today and wanted to concentrate on the Roguelike instead of all the boring user-interface stuff, I'd use LibTCOD.

Cheers,
Steven Black

[yam655]

Does any small gui style console library for C/C++ exist? Other than curses or libtcod which both seem very intrusive, forcing to do stuff their way.

If you want to do things your own way the simple solution would be to use SDL to write your own simple console library. <http://www.libsdl.org/>

To get something simple shouldn't be a lot of work.

Cheers,
Steven Black

[TheCreator]

If you want to do things your own way the simple solution would be to use SDL to write your own simple console library. <http://www.libsdl.org/>

To get something simple shouldn't be a lot of work.

My own rule of thumb is that whenever I am able to program something by myself instead of using an external library, I do it. One might be fooled into thinking that an external library saves time, but in many cases that is simply not true. Whenever you encounter a bug in the library, you waste a lot of time (much more than you'd waste on your own bug). Whenever you create your own bugs because you misunderstood the author's intents, you waste a lot of time as well. And of course if you struggle to understand the author's intents and use the library the right way, you still waste a lot of time because the documentation is poor, or there is no documentation, or the library design is overcomplicated, or it just sucks. Even if you happen to get a well-documented, well-designed and robust library, it might not do exactly what you want it to do, so you have to modify it (another waste of time; you either waste it fixing the bugs you have made or striving to modify the library carefully - choose what you like). And if you are very, very lucky and the library needs not to be modified (it is always nearly impossible to predict), it still must take some time to learn how to use it as it's very unlikely that they do the things your way.

The conclusion is: use only your own code. For a custom console window (not associated in any way with a system terminal) it cannot be hard.

[yam655]

My own opinion falls directly counter to UglyTroll's.

Stupid/primative user interfaces are easy. Good ones are quite a bit of work.

The task is primarily about understanding the library. Open source libraries mean you can help out with documentation and examples. One shared stupidly simple example can fairly easily be looked over and corrected to become the canonical best example.

I have dicked around with just trying to get a decent user interface library to make a Roguelike for over a decade. Nothing fancy, just the core features I need to make the game I want. I wish LibTCOD had been around when I started (originally I was going to use C) I could have focused on extending it to do what I wanted instead of reinventing wheels.

This is actually one of the reasons that after ARRP I'm working on a comprehensive tutorial to create Roguelike games with my interface library. Good documentation and clear  examples are important.

Cheers,
Steven Black

[getter77]

...
This is actually one of the reasons that after ARRP I'm working on a comprehensive tutorial to create Roguelike games with my interface library. Good documentation and clear  examples are important.

Cheers,
Steven Black

 When you get to this stage, this is the highwater mark to equal or best outright:

http://users.freebasic-portal.de/rdc/tutorials.html

[yam655]

When you get to this stage, this is the highwater mark to equal or best outright:

http://users.freebasic-portal.de/rdc/tutorials.html

Thank you for pointing this out to me.

My plan is to write a small Roguelike, then write the tutorial backwards breaking it down in to simpler and simpler parts. While I was at it, I'd be fixing issues and adding features to my core library. The tutorial text becomes simpler because the code is already written. Plus if I can't explain something clearly in the tutorial it showcases a weak spot in the code.

I'm of the opinion that it's not a complete tutorial unless at the end there's an actual complete and playable game. I think it comes from learning to program as a kid and first wanting to play something and then wanting to understand and extend it.

My plan was to release it in ebook form, so it seems what I had independently been planning would have at least been a contender.

It's nice to have a benchmark on which to track my progress.

Again, thank you.

Cheers,
Steven Black

[Ari Rahikkala]

One thing that I wish existed is Urwid for languages other than Python. ncurses is really low level, it doesn't do much beyond reading characters and putting characters on screen cells. That's exactly what you want for things like drawing the map screen and other such things that you need fine control for, but rather annoying when you want to implement an inventory menu for tefirst time. The Curses Development Kit is too high-level and inflexible - for instance, it has a menu widget that's probably fairly easy to use, but that also draws borders for you (which mightn't be what you want when you are working with a limited amount of character cells and want a visual style of your own), sets up a set of default keybindings that I'm not even sure you can change, etc.. Basically, ncurses does too little for you, while CDK does too much for you.

At least based on its documentation (I haven't actually used it), Urwid is the only console UI library I've ever seen that's actually based on modern UI library concepts. If you want padding around something, you pack it in a Padding widget, if you want borders you put it in a LineBox, and then when you use a Text or Button or BarGraph or whatever widget inside it, it draws nothing more on the screen than what you asked for. It handles laying text out into rows, it has mouse support, etc. the standard stuff. Being that it works on the widget level, it handles a lot of the trouble of resizing for you. It of course has deep support for extending the existing base of widgets and reusing as much code as possible to do that.

Oh, and just like basically every other UI library out there, instead of having the programmer call input functions and block on them, it has its own main loop and you write event handlers on your widgets instead. So, instead of saying do_inventory_menu() and doing stuff with its return value, you call up the inventory menu and place it in focus, so that coming input events will go to that menu and its event handlers (well, more correctly, they go to the topmost widget first and down through its children to the inventory menu until some widget handles the event and stops it from propagating further). I understand that mightn't go over well with developers who are so... libertarian... that even libtcod's really pretty low-level console is too much, and a lot of the reasons why UI libraries take control of the main loop are somewhat moot for roguelike interfaces anyway, but all the graphical programmers are living with an evented approach and they seem to be doing just fine.

[yam655]

At least based on its documentation (I haven't actually used it), Urwid is the only console UI library I've ever seen that's actually based on modern UI library concepts. [...]

For Java, if using curses, there is: http://sourceforge.net/projects/javacurses/ -- It's an AWT subset implemented in Curses.

At some point in the future I want to see if I can make it use my Blacken AWT-based interface library instead. It'll probably mean a fork of javacurses, as I doubt it was designed for multiple back-ends.

It'll mean we'll have an AWT-like interface to a TUI running on AWT. It's so perverse I just have to try it.

Cheers,
Steven Black