Reworking the UI

[calris]

New thread - it's gone well beyond X11 tile support

Unfortunately, my term rework came about as a consequence of the X11 rework, but ultimately I plan to separate the two.

The concepts are pretty well summed up in takkaria's NextUI.

The idea is that each 'term' will be a proper 'virtual terminal', each encompassing a specific game function (message bar, status bar, player info bar, cave area, mini-map, etc). These 'virtual terminal' can then be mapped to physical 'displays' at will - So you could have virtual terminals mapped to individual windows, or you might map basic and extra player stats to the same window (using a y-offset for one to keep them separate, or maybe toggle between them)

The upshot is all about the 'cave' term - the end-goal is that the grid sizes of the cave tile and the text tiles are completely separate.

My work so far has focused on ditching the global 'Term' variable - all term related functions now take a term * argument.

There have been some 'collateral damage'

• The screen save and load code has been axed - I think it best to trash this and create a better mechanism
• text_out_to_file() - The global text_out_hook is a horrible hack, so sorry, but out she goes. It's ONLY used for creating the artifact spoiler files anyway
• There's probably going to be more - we'll see

What I'm doing isn't going to break existing front ends - It will completely shatter them. And I'm sorry, but X11 is the only front end I'm keen to work on at the moment. I can't do Windows or Mac, and I have no idea about the ncurses API - so X11 it is.

I'll TRY to push stuff into my x11-rework branch as often as possible. Once things have stabilised, I'll create a new branch focused on UI

EDIT: I'm just going to dump a todo list here

• Monster and object tile support in text block

[calris]

Menus will probably be split out into a virtual terminal as well

EDIT: Correction - I think menus will be tied to specific virtual terms like panels and text blocks

[calris]

So we have struct term, struct panel, and struct textblock these are really well defined constructs that tie in very nicely with each other - i.e. textblocks and panels created arbitrarily and (currently) plotted into a term structure.

Now the term structure is very heavy - maybe we could make panels and text blocks a kind of 'sub term' - i.e. they are intrinsically tied to a term with a specified x/y offset and inherit all of the term's attributes to keep them light.

I'm thinking slightly bigger picture here - how do we support file exports seamlessly?

File I/O is a hodgepodge at the moment. What if we add a file output hook to the term structure? We can have a type flag (text/html) which can dump the contents of a term to file. I've trashed the existing file dump for artifact knowledge, maybe we just create a virtual terminal, hook it into the 'raw text file output' renderer and boom - we're done

[Nick]

If you get all this working for x11, I'm guessing (or at least hoping) we should be able to adapt the other front ends. And I believe this is the direction we want to be heading.

I hope the best thing I can do is stay out of your way, because I'm not getting much Angband time at the moment.

[calris]

Correction - textblocks are not tied to a specific 'term' - They could be output to the main term, or they could be output to a dedicated term (monster lore for example) - So what we have, in essence, is a 'lite term' - a term that contains attr/char pairs that can be display on any term at will.

Should panels be the same? Panels are slightly fancier text blocks - they contain an array of 'lines', each of which have a label (printed using the basic foreground attribute) and a value (printed using the specified attribute). I see no reason (EDIT: not) to have panels as 'lite terms' that get tied to a term at will - Thus we can have a panel displayed on multiple 'terms' simultaneously.

I see great potential here - Take the 'player extra' term - there are three 'panels' (or are they text blocks?) for resistances and abilities - If you create a tall term window, you can display all three panels vertically. You can put the 'stats' panel(s) in a separate term (if you want to see them)

So basically I see that we have:

• Panels, Text Blocks, and Menus are are lowest level 'configurable' entities - they are 'lite terms'
• A 'term' has Text Blocks, Panels, and Menus rendered onto it
• The 'cave map' and 'cave mini map' are 'special' terms - they are the only terms that 'can' be 'graphical' (NOTE: currently the graphical UIs allow for displaying the player's equipment using graphical tiles, also the monster and object recall need to support displaying a graphical tile)
• A 'window' has multiple 'terms' mapped to it

The really neat thing about X11 (and I'm sure other graphical front ends) is that we can render terms to a 'virtual window' (XImage) and then just plaster them together in the window - will be HEAPS more efficient when we display a menu and then exit from it - we don't need to redraw any tiles, just redraw the whole XImage

[Pete Mack]

The slow part of the redraw is the cave data. The various text panels redraw too fast to see the change. And pretty much all of them use two canvases for fast (blitted) redraw.

The really neat thing about X11 (and I'm sure other graphical front ends) is that we can render terms to a 'virtual window' (XImage) and then just plaster them together in the window - will be HEAPS more efficient when we display a menu and then exit from it - we don't need to redraw any tiles, just redraw the whole XImage

[AnonymousHero]

The slow part of the redraw is the cave data. The various text panels redraw too fast to see the change. And pretty much all of them use two canvases for fast (blitted) redraw.

AFAICT the X11 code is Xlib which is... drumroll: synchronous. If the vanilla X11 frontend is anything like the T2 one (which it seems to be given some of the stuff in this thread) it's drawing each single tile using an X11 blit command. Even for a 80x50 grid the delay can be quite noticable and you'll want to draw into an off-screen bitmap. (Plus this also helps avoid the "half-drawn" flicker effect.)

(IME this is noticable both for the "cave" portion of the main window and the "messages" window. YMMV.)

Any optimization that happens inside the "term" structure (I recall it trying to do "diff"-type patchups, only modifying lines flagged as "modified" in the backing structure, etc.) are probably completely swamped by these round-trip delays.

(I imagine it's similar for the other frontends, but haven't looked at the code.)

[Pete Mack]

@AnonymousHero
Ugh. No, all the terms do differential updates on character moves, monster drops, etc. But on full redraws, the other terms all use double-buffering. Without double-buffering, gfx just won't work, and even pure-text will be ugly. That's really bad.

[AnonymousHero]

@AnonymousHero
Ugh. No, all the terms do differential updates on character moves, monster drops, etc. But on full redraws, the other terms all use double-buffering. Without double-buffering, gfx just won't work, and even pure-text will be ugly. That's really bad.

I think you're assuming something I'm not saying. I wasn't arguing against double-buffering. One should just double-buffer bitmaps and not try any fancy tile-based diffing and such[1]

[1] At best it's completely wasted on modern CPUs and at worst it's a pessimization since modern CPUs thrive on prefetching.

[t4nk]

This is relevant to my interests Any news about it?

[calris]

This is relevant to my interests Any news about it?

Real life got in the way - I'm hoping to get back into it soon

[t4nk]

Real life got in the way - I'm hoping to get back into it soon

That would be great. For the last month I was working on a new, SDL2-based frontend for Angband. ATM it's complete (modulo bugs) and playable (on my machine, and, I think, on Nick's ). There are several things that bother me still, and tile_width/tile_height are very high on this list. I considered rewriting some parts of textui, but it would be too boring to do it alone. If you decide to return to improving Angband's UI, could you post on this forum then? I also don't think X11 is entirely adequate for the job...

Here's what I think should be done:
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.
All menus (store interface, inventory, mouse click menus etc) should be popups, instead of being rendered on the main term. 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.
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.
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.

[Pete Mack]

SDL is sort of a clunker--rather old design gfx. By many accounts SFML is much easier, as well as leaner and meaner.

http://www.sfml-dev.org/

[t4nk]

SDL is sort of a clunker--rather old design gfx. By many accounts SFML is much easier, as well as leaner and meaner.

http://www.sfml-dev.org/

Are you going to write a frontend for Angband in SFML?

[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