Reworking the UI

[t4nk]

So, I'm thinking about giving it a go... (not the SFML stuff, LOL ). There are 30855 lines in ui-*.c ui-*.h lines... hopefully much of that could be reused. I think textui is actually pretty good (I like it a lot, a lot better than NPP UI), the only major problems are with tiles dimensions and Term_fresh()... hmm... I don't know

edit: ui-*.c code makes me RAGE, though! I know I won't be able to resist the temptation to rewrite pretty much all of it... so, I'm not doing it alone

[Pete Mack]

I'll bite. What in particular do you dislike in the ui-* code? (It's a whole lot better than it was in 3.0.)

edit: ui-*.c code makes me RAGE, though! I know I won't be able to resist the temptation to rewrite pretty much all of it... so, I'm not doing it alone

[t4nk]

I'll bite. What in particular do you dislike in the ui-* code? (It's a whole lot better than it was in 3.0.)

1) C89
2) Term, inkey_xtra, inkey_flag, text_out_pad (and the whole text_out_hook thing), ex_width, ex_offset, etc.
3) Magic numbers everywhere

void display_player_stat_info()
{
    ...
    /* Row */
    row = 2;

    /* Column */
    col = 42;
    ...
}

static void display_player_sust_info(void)
{
    ...
    /* Row */
    row = 2;

    /* Column */
    col = 26;
    ...
}

4) Ncurses-ness (Term_gotoxy(), cu, cv, TERM_XTRA_SHAPE, "icky corner"...)
5)

$ ack -i -c hack ui-term.c
30

And some other stuff

[takkaria]

So, I'm thinking about giving it a go... (not the SFML stuff, LOL ). There are 30855 lines in ui-*.c ui-*.h lines... hopefully much of that could be reused. I think textui is actually pretty good (I like it a lot, a lot better than NPP UI), the only major problems are with tiles dimensions and Term_fresh()... hmm... I don't know

I was sort of imagining that a lot of the code could be shared. One of the things I was keen to avoid when thinking about NextUI was duplication of functionality. In an old GTK frontend, there were frontend-level windows for various things like object lists and monster lists, except rendered in a proportional font... which obviously broke really fast when things changed. Hopefully basics like textblock and maybe a 'virtual' term/grid type that is just used for drawing, not for input etc. and then overlaid onto a real display would avoid a lot of this.

[Pete Mack]

Tak-
The goal should be a clean, portable graphics package to get rid of all term-xxx.c files. I recommend against SDL, since it is really out of date on Windows (using directx 5!). The newer SFML package will actually work in Metro (windows 8/winphone) apps, as well as ios and android. That is *portable.* And yes it is C, not C++, so there still wouldn't be annoying binding errors between different C++ manglers. (It is the latter that makes Windows sound and image rendering a big problem.)

[Pete Mack]

Then C89 stuff and global are annoying it is true. And I agree, Term is archaic, even if it was pretty good when written ca 1984.

[t4nk]

I was sort of imagining that a lot of the code could be shared. One of the things I was keen to avoid when thinking about NextUI was duplication of functionality. In an old GTK frontend, there were frontend-level windows for various things like object lists and monster lists, except rendered in a proportional font... which obviously broke really fast when things changed. Hopefully basics like textblock and maybe a 'virtual' term/grid type that is just used for drawing, not for input etc. and then overlaid onto a real display would avoid a lot of this.

This is a valid point. Having two full blown UI systems for one game is not practical. Therefore, unfortunately the NextUI must be another small pile of hacks on top of textui I'm having some vague thoughts like this:

void spawn_new_term(struct term_hints hints)
{
    if (frontend_supports_next_ui) {
        Term_spawn(hints);
    } else {
        screen_save();
    }
}

Then all 82 calls to screen_save() could be replaced with this, and similar for screen_load()... As for info panel on the left side of main term, status line etc... probably different event handlers should be installed?

if (frontend_supports_next_ui) {
    event_add_handler_set(player_events, N_ELEMENTS(player_events),
			      update_sidebar_next_ui, NULL);
} else {
    event_add_handler_set(player_events, N_ELEMENTS(player_events),
			      update_sidebar, NULL);
}

Hmm... that doesn't seem terribly difficult...

edit: another idea; how about replacing Term_activate() with Term_push(term *t) and Term_pop()? Then Term_push(NULL) would create new term...

I recommend against SDL, since it is really out of date on Windows (using directx 5!).

Apparently, you're thinking about SDL1; I said SDL2, which, to my best knowledge, doesn't have any support for directx5.

[t4nk]

Anyway, we shouldn't forget good things about term system; it has a good, simple API for writing new frontends, and all in all, it's pretty appropriate for a grid-based game like Angband. It just lacks some features (and has some misfeatures)... but it probably could be cleaned up a little and taught new tricks?
The question is, who is going to do that?

[t4nk]

In fact, what if Term_save() looked something like this:

errr Term_save(void)
{
    int w = Term->wid;
    int h = Term->hgt;

    if (!Term->save_hook) {
        term_win *mem = mem_zalloc(sizeof(term_win));

        term_win_init(mem, w, h);
        term_win_copy(mem, Term->scr, w, h);
        mem->next = Term->mem;
        Term->mem = mem;
    } else {
        Term->save_hook(&w, &h);

        term_win *scr = mem_zalloc(sizeof(*scr));
        term_win *old = mem_zalloc(sizeof(*old));

        *old = *Term->old;
        *scr = *Term->scr;

        term_win_init(Term->old, w, h);
        term_win_init(Term->scr, w, h);

        Term->old->next = old;
        Term->scr->next = scr;
    }

    Term->saved++;

    return 0;
}

Term->save_hook(int, int) asks the frontend about the dimensions of term (presumably term_screen) when the term is in text (as opposed to tiles) mode. For example; term_screen is 800 * 600 pixels and displays Shockbolt's tiles at full scale (64x64). That's 12x9 grid cells. But, with the 10x20x font it would be 80x30 cells. So w is 80 and h is 30. Now textui can draw whatever menus it wants over the new screen. On Term_load() the old 'scr' and 'old' will be restored.
The code is not complete (Term->wid etc) and i probably made a mistake somewhere... or ten but hopefully the idea is clear?
The other things that are drawn over the main term are prompt, player info panel, messages and status line. Prompt would require changes to prt() I assume; the rest would need installing different event handlers so that they could be displayed in their own terms. ANGBAND_TERM_MAX would have to be increased to 11 then.
Any opinions? That seems to preserve backwards compat and yet eliminate the need for tile_width/tile_height for those frontends that can provide Term->save_hook() and load_hook(). It also wouldn't require a lot of code (so chances are someone may actually go ahead and do it )

edit: something will have to be done about right mouse click menus too, so that they would pop in the right spot.

edit2: There are macros ROW_MAP and COL_MAP. Argh! Those need to go.
Also, PW_STATUS subwindow seems to be completely unused?

[Nick]

I'm not likely to be looking at any of this any time soon, so I'm very happy to see other people discussing it.

[calris]

The text panels on the main term (messages line, status line, and player info on the left) should just become separate terms. There is no reason for them to be parts of the main term.

The idea I had was for each game 'element' to be rendered onto it's own 'virtual terminal' with a 'compositor' mapping the contents of the virtual terminals onto a 'real' terminal. Which virtual terminals, and how they are positioned, will be left entirely up to the compositor.

For each front-end port, only the compositor will change.

All menus (store interface, inventory, mouse click menus etc) should be popups, instead of being rendered on the main term.

Agreed - they will just be virtual terms that the compositor will be asked to show/hide. For X11 for example, menus could be displayed in completely separate pop-up windows for example.

NextUI should know how to ask the frontend to spawn new terms (or term-like things). It could give some hints to the frontend about how to better place them. For example: "center the new term in the main term", or "place the new term such that its top left corner is over the top left corner of tile x, y of the main term". I don't see why any futher granularity is needed; thinking about pixels is frontend's job.

Each front end (compositor) will probably need a configuration file to allow the positioning of virtual terms to be tweaked

The textui should consider very carefully when to update the screen. Most display that are in use today can only be updated 60 times per seconds; currently, textui demands hundreds of updates a second. So the frontend has no other choice but to drop some frames; and it has very little information about how to do that in a reasonable manner. The visible effect of that is "flickering" of the screen. That's present in all Angband's UI (at least on Linux), except, OF COURSE, main-gcu.c.

Each virtual terminal will have a 'dirty' flag. The compositor will only need to redraw those virtual terminals for which the 'dirty' flag is set. We will need to tweak the code which updates the virtual terminals to avoid excessive setting of the 'dirty' flag. For example, the flag should no be set every time a monster moves - it only needs to be set when control returns to the player. However, we also need to consider the 'shimmering' effect which cycles through colours while the player is doing nothing.

Oh, and I'm completely sure the NextUI should drop all support for ncurses. Graphical and (pseudo)terminal UIs have completely different needs; and in any case, ncurses is already well served by existing textui.

The ncureses UI will just be another compositor - if we do NextUI right, discussions about support for various UIs should be a non-issue because they will in now way impact on the core game engine and virtual terminal architecture

[Pete Mack]

@calris-
I think UnAngband already works this way, though the console is fixed in one configuration.

[t4nk]

Well, calris, I'm already doing it my way as described in another thread... it's on https://github.com/t4nk074/angband, branch "textui2". Of course, nothing works yet

[calris]

Well, calris, I'm already doing it my way as described in another thread... it's on https://github.com/t4nk074/angband, branch "textui2". Of course, nothing works yet

Thanks for taking on such a monumental task I've read through the thread and it's looking good. Looking forward to having a closer look at what you've done so far