Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old July 3, 2016, 20:42   #21
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,862
Donated: $40
Pete Mack is on a distinguished road
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.
Pete Mack is offline   Reply With Quote
Old July 3, 2016, 21:07   #22
t4nk
Swordsman
 
Join Date: May 2016
Posts: 300
t4nk is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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:
Code:
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?
Code:
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...

Quote:
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.

Last edited by t4nk; July 3, 2016 at 22:05.
t4nk is offline   Reply With Quote
Old July 3, 2016, 21:25   #23
t4nk
Swordsman
 
Join Date: May 2016
Posts: 300
t4nk is on a distinguished road
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 is offline   Reply With Quote
Old July 4, 2016, 01:00   #24
t4nk
Swordsman
 
Join Date: May 2016
Posts: 300
t4nk is on a distinguished road
In fact, what if Term_save() looked something like this:
Code:
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?

Last edited by t4nk; July 4, 2016 at 19:03.
t4nk is offline   Reply With Quote
Old July 9, 2016, 00:10   #25
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,164
Donated: $60
Nick is on a distinguished road
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.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old July 16, 2016, 04:07   #26
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
Quote:
Originally Posted by t4nk View Post
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.

Quote:
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.

Quote:
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

Quote:
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.

Quote:
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
calris is offline   Reply With Quote
Old July 16, 2016, 04:09   #27
Pete Mack
Prophet
 
Join Date: Apr 2007
Location: Seattle, WA
Posts: 4,862
Donated: $40
Pete Mack is on a distinguished road
@calris-
I think UnAngband already works this way, though the console is fixed in one configuration.
Pete Mack is offline   Reply With Quote
Old July 17, 2016, 11:47   #28
t4nk
Swordsman
 
Join Date: May 2016
Posts: 300
t4nk is on a distinguished road
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
t4nk is offline   Reply With Quote
Old August 14, 2016, 04:26   #29
calris
Adept
 
Join Date: Mar 2016
Posts: 194
calris is on a distinguished road
Quote:
Originally Posted by t4nk View Post
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
calris is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
RFC: Reworking sound sub-system calris Development 125 April 19, 2016 16:04
Reworking the entire magic system (yay)! TricksterWolf Development 8 September 20, 2015 20:22


All times are GMT +1. The time now is 05:19.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.