[feature] Suggestion: screen buffering and update...?

[Zorgatone]

I was thinking it would be cool, and would also be a workaround for #14.

We could implement an optional screen buffering and an update function, maybe like this:

// Global buffer
char **buffer = NULL;

char **rlutil_init(void) {
    int rows = trows(), cols = tcols(), i;

    buffer = (char **) malloc(rows * sizeof(char **)); // Matrix of chars

    for (i = 0; i < rows; i++)
        buffer[i] = (char *) malloc(tcols * sizeof(char)); // sizeof(char) is always 1

    return buffer; // Optional
}

void rlutil_free(void) {
    int i, rows = trows();

    for (i = 0; i < rows; i++)
        free(buffer[i]);

    free(buffer);
}

void tupdate(void) {
    int i, j, rows = trows(), cols = tcols();

    cls();

    // Print the contents of the buffer to the terminal's screen
    for(i = 0; i < trows; i++) {
        for(int j = 0; j < tcols; j++) {
          // call whatever i/o function that outputs the chars and doesn't move the position
        }
    }
}

Imagine this, you have a game loop in which you update a lot of game logic, monster positions... and you use the normal rlutil's i/o functions. The functions would know if rlutil_init() was called, and in this case would use the buffer rather than outputting on the screen directly. Then you explicitly call update once per game loop to display everything to the player.

If you don't use rlutil_init and rlutil_free the i/o functions will work as usual.

The only downside to this would be that we need to handle the terminal resize event, and eventually add rows and/or realloc each column of the buffer. But I suppose if the user won't resize the terminal often we could have some performance boosts if done correctly.

Another way to do this would be to initialize a bigger matrix[MAXROWS][MAXCOLS] without huge numbers, but that can handle most of the terminal screens and resolutions.

I could even try to implement it myself (in C), if I can find some free time (job and university...)

[nabijaczleweli]

• This is not curses
• You can't have a cross-TU static field in a header-only library

[nabijaczleweli]

If you want curses-like functionality, use curses. Unconditionally updating the whole screen is just a very, very bad idea for realtime stuff on the teminal

[Zorgatone]

Uh, right about that. Header-only library.

Still a Roguelike-oriented library should some more utilities Ok..

[nabijaczleweli]

This is just way out of scope of this library, IMO. It's supposed to be a lightweight language-adapting header-only thing to ease communicating with the terminal (or to make roguelikes, if you really want to), not a GUI utility (that field is already taken by curses and many other curses-like libraries).

[Zorgatone]

I wasn't going anywhere near GUI utilities, just about handling the screen. But you have a point, no problem.. Just forget this :)

[nabijaczleweli]

:)