[ncurses] Compilation error: fatal error: ncurses.h: No such file or directory compilation terminated.

[Fabrizio-Caruso]

As you mentioned the support for ncurses I have tried to compile my game with "ncurses" character/text graphics but I get:

fatal error: ncurses.h: No such file or directory
compilation terminated.

I am compiling with -lncurses.

The very same compile line works with standard gcc on both Cygwin and Linux.

[th-otto]

Of course you have to install ncurses first, either from Vincent's site http://vincent.riviere.free.fr/soft/m68k-atari-mint/archives/mint/ncurses/ or a more up-to-date version from my site http://tho-otto.de/crossmint.php

[vinriviere]

@Fabrizio-Caruso ncurses is installed automatically with my setup, no trouble. But you need to use #include <ncurses/curses.h>. From the documentation, I see that such subdirectory is considered as a valid alternate configuration. I may switch to something more standard in the future.

[th-otto]

Or setup symlinks similar to a linux environment, if they don't exist already:

lrwxrwxrwx 1 root root 17 21. Mai 10:28 /usr/include/ncurses.h -> ncurses/ncurses.h -rw-r--r-- 1 root root 82038 21. Mai 10:27 /usr/include/ncurses/curses.h lrwxrwxrwx 1 root root 8 21. Mai 10:27 /usr/include/ncurses/ncurses.h -> curses.h

[Fabrizio-Caruso]

@th-otto thanks but I consider this sort of a hack. My library builds the (very same) game(s) on 200 different computers/consoles/handhelds/calculators/etc. without adding any link or configuration to the host system. I will have to temporarily adapt my code with the suggested non-standard include, hoping for an update with support for the standard include.

[vinriviere]

When I first configured ncurses, I wasn't aware of best practices. Now it is clear that #include <ncurses/ncurses.h> is less standard than #include <ncurses.h>. I will fix future builds.

[Fabrizio-Caruso]

Merci @vinriviere ! I am giving some visibility to your very cool SDK in the retro-programming groups in which I am active. You have done a very clean work for me. What is missing is some APIs for classic hardware but if I understand well, your main focus is new hardware. Has anyone developed some libraries for classic hardware that expose C APIs usable with your SDK?

[vinriviere]

@Fabrizio-Caruso Thanks! My goal is only to make existing tools and libraries easily available for cross development. We already discussed the case of SDL. Unfortunately, I don't know any other easy framework which could be used for ST.

[Fabrizio-Caruso]

@vinriviere I have managed to build my game wit ncurses but I get an error when I run it: error opening terminal unknown

The same code works when compiled with gcc.

[vinriviere]

@Fabrizio-Caruso Ah. This is because Atari ncurses applications are generally intended to be run under a full FreeMiNT environment. You lack the terminfo database. Please unpack the attached ZIP file at the root of your C:, and keep the directory structure. So you should get a file named C:\USR\SHARE\TERMINFO\S\ST52 Then at the beginning of your program, please do: putenv("TERM=st52");. This should work. But keep in mind that it will be rather slow on plain ST.

[Fabrizio-Caruso]

@Fabrizio-Caruso my game does not require very high speed and it can be compiled in turn-based mode. I am going to try your suggested solution. What is the purpose of including ncurses in your binary if no terminfo is provided? It looks like the terminal uses VT52. Doesn't it? Could I move the cursor with just VT52 control codes with no need for terminfo and ncurses?

[vinriviere]

@Fabrizio-Caruso Purpose of ncurses is to allow direct ports of Linux software to a full-featured and fast FreeMiNT environment. As the MiNTLib (our C standard library) is very compatible, resulting binaries can also run on plain ST, as long as the terminfo database in installed and TERM is set to st52. But that's not the main target. I'm curious to see how good it will work in your case.

And indeed, the Atari ST uses VT52 escapes. See VT52 documentation on tos.hyp. Display will be much faster than with ncurses. This is the way to go for text output on plain ST.

Also, please consider medium resolution (4 color) or high resolution (monochrome) for 80x25 characters display.

[Fabrizio-Caruso]

@vinriviere your fix does not work and I don't understand how it should work: it still produces the same error. I am building inside Cygwin (and I also would like everything to work under Linux). Cygwin probably does not expect anything in C:\USR\SHARE\TERMINFO\S\ST52.

[vinriviere]

@Fabrizio-Caruso C: is your Atari C:, not Windows one. It depends where you configured Atari C: on your emulator. It may even be A: if you don't have C:.

[Fabrizio-Caruso]

How is Cygwin going to know where ST52 is located if it is in C:\USR\SHARE\TERMINFO\S\ST52? I will probably try VT52 and see if I can get to move the cursor.

[vinriviere]

@Fabrizio-Caruso Please read my answer above. The terminfo database is a runtime thing, it has nothing to do with Cygwin or Windows environment.

[Fabrizio-Caruso]

Merci @vinriviere ! Cela marche! Sorry for not understanding your solution! ncurses is indeed very slow and only usable in turn-based mode. I am using the default resolution which is probably medium but I am not sure.

[Fabrizio-Caruso]

It is much slower than any 8-bit system including 8-bit systems with super slow bitmap-only graphics. Something must be wrong in the implementation but it is functionally OK. I will definitely try VT52.

[th-otto]

@Fabrizio-Caruso this has nothing to do with a hack. It is just that those symlinks are missing in vincents archives. But if your games are build by something like autoconf, you can of course also test for presence of either header file, and use the appropiate one. That would be a good idea anyway, because on some BSD systems that header might be just

[Fabrizio-Caruso]

@th-otto I have chosen not to adapt/modify the host system or avoid this as much as possible because I want to keep my meta-framework as easy to install as possible: you just install the C compiler(s) with no extra modification/links/configs and you type make c64, make atari_st, make nes, etc. and it should just work straightaway. Consider I have managed this so far with more than 200 different cases. I prefer polluting my code and Makefile so that it will search different includes for different systems rather than having extra sym links that any user has to set up to get my framework up and running. It is my choice.

[Fabrizio-Caruso]

@vinriviere How can I avoid seeing the pressed keys on the screen? noecho() seems not to be working. Is there some sort of no echo option? My code is already using noecho():

#if defined(__ATARI_ST__)
    #include <ncurses/curses.h>
#else
    #include <ncurses.h>
#endif

void INIT_GRAPHICS(void)
{
    #if defined(__ATARI_ST__)
        putenv("TERM=st52");
    #endif
    initscr();   
    noecho();
    curs_set(0);
    start_color();
    cbreak();
    intrflush(stdscr, TRUE);
    init_pair(COLOR_YELLOW, COLOR_YELLOW, COLOR_BLACK);
    init_pair(COLOR_CYAN, COLOR_CYAN, COLOR_BLACK);
    init_pair(COLOR_RED, COLOR_RED, COLOR_BLACK);
    init_pair(COLOR_GREEN, COLOR_GREEN, COLOR_BLACK);
    init_pair(COLOR_BLUE, COLOR_BLUE, COLOR_BLACK);
    init_pair(COLOR_WHITE, COLOR_WHITE, COLOR_BLACK);
    init_pair(COLOR_MAGENTA, COLOR_MAGENTA, COLOR_BLACK);
}

Other missing feature is colors. A bonus feature that would allow ncurses to create simple games is an option to force "unbuffered keyboard input", i.e., you just press a key without return (and without echo on the screen).

[vinriviere]

@Fabrizio-Caruso That's already a good result. I don't use ncurses myself, so I can't help you more.

Default resolution is ST-Low: 40x25 characters. At the desktop, you can manually switch to Medium resolution from the Option menu, then "Change resolution". For High resolution you need to select a monochrome monitor in the emulator.

Anyway, for quick text output, forget ncurses. You can also forget printf(). Instead, use direct TOS system calls (GEMDOS layer). See documentation on tos.hyp. And use VT52 escapes for to change colors and text location.

Examples:

#include <mint/osbind.h>

Cconout('X'); /* Display a single character */
Cconws("Hello\r\n"); /* Display a string */
char ch = Cnecin(); /* Read a single character, no echo */

[th-otto]

ncurses relies on working termios() calls. They should work on MiNT, but are only rudimentarilly emulated on single TOS. That's why turning off echo etc. might not work as expected.

[Fabrizio-Caruso]

@th-otto any hope to get a little bit more temios() support? What I see as missing is:

• noecho (very useful on any application with input and some text/character graphics)
• unbuffered input, i.e., no wait for input (useful for interactive action games)
• color support (self-explanatory)

I will follow @vinriviere's suggestion to use different functions but it would be cool to have ncurses basic support for turn-based games and tools that could be ported straightaway with no modification.

[th-otto]

Not really i think. Do get that right, you would have to reimplement all tty related stuff from the mint kernel also in mintlib.

I think a better approach is to use GEMDOS or BIOS functions directly. Maybe you can emulate most what you need by writing some small functions for echo(), noecho() etc., ie. some mini-ncurses lib.

As already said, all what you need like unbuffered input etc. already works when run on MiNT, but of course that is even slower, and not suitable for games.