Textui reform (warning: long and full of C)

[t4nk]

Bump

The first significant milestone has been achieved - Angband now can be compiled with the new UI.
That by itself maybe doesn't mean much. Nothing works yet, in particular, there is no frontend that can work with it.
Still... 30000 lines of C were refactored. All the ui-* files (except ui-signals.c) were converted to the new Term API. The changes are big... It was a lot of work.
I did cut some corners. The signals stuff was excluded, and I'm not at all sure the UI should handle them (btw, I wrote in the commit that handler functions don't do anything, but I just didn't notice the ifdef soup ). Signals probably should be handled by main-gcu.c. I don't see why anything else should care...
There are also "wizard" files (wiz-debug.c and friends). I disabled them for now. They should either call themselves ui-debug etc, or they shouldn't call into Text UI directly.
Tile picker, glyph picker, the '/' command and a couple other things that I don't remember are all casualities of the refactoring.
Step two is to actually adapt one of Angband's frontends to the new UI. I think I'll use the best one available

[Nick]

Bump

The first significant milestone has been achieved - Angband now can be compiled with the new UI.
That by itself maybe doesn't mean much. Nothing works yet, in particular, there is no frontend that can work with it.
Still... 30000 lines of C were refactored. All the ui-* files (except ui-signals.c) were converted to the new Term API. The changes are big... It was a lot of work.
I did cut some corners. The signals stuff was excluded, and I'm not at all sure the UI should handle them (btw, I wrote in the commit that handler functions don't do anything, but I just didn't notice the ifdef soup ). Signals probably should be handled by main-gcu.c. I don't see why anything else should care...
There are also "wizard" files (wiz-debug.c and friends). I disabled them for now. They should either call themselves ui-debug etc, or they shouldn't call into Text UI directly.
Tile picker, glyph picker, the '/' command and a couple other things that I don't remember are all casualities of the refactoring.
Step two is to actually adapt one of Angband's frontends to the new UI. I think I'll use the best one available

This is brilliant, well done. I will try to have a proper look at it some time...

[t4nk]

Bump

https://postimg.org/image/bki03nh45/

It is super, super alpha... I was able to take several steps in town

So the next step is: fix the frontend and try to get through the birth menu without segfaults and failed assertions.

[takkaria]

Bump

https://postimg.org/image/bki03nh45/

It is super, super alpha... I was able to take several steps in town

So the next step is: fix the frontend and try to get through the birth menu without segfaults and failed assertions.

Very impressive

[t4nk]

Returning to SDL2 frontend feels so good It's great that I can finally see something displayed on screen. I believe I refactored it enough and can now concentrate on the text ui again... So, I'd like some advice.
The old Term API is really relaxed about various errors:

    /* Verify */
    if ((x < 0) || (x >= w)) return (-1);
    if ((y < 0) || (y >= h)) return (-1);

The new one is very strict:

    assert((x) >= 0); \
    assert((x) < TOP->width); \
    assert((y) >= 0); \
    assert((y) < TOP->height); \

That leads to crashes, right in the birth menu:

angband: ui2-term.c:339: term_wipe_line:
Assertion `(y) < (term_stack.stack[term_stack.top])->height' failed.
Aborted

Because the menu tries to print something off screen... which approach is better? I prefer strict, but UI was written around old Term, which tries to just ignore all errors... opinions?

[takkaria]

The old Term API is really relaxed about various errors / the new one is very strict / which approach is better? I prefer strict, but UI was written around old Term, which tries to just ignore all errors... opinions?

strict is way better. We've had a gradual trend towards being stricter with function arguments for several years, so if you can be bothered, it would be great to continue this.

[t4nk]

strict is way better. We've had a gradual trend towards being stricter with function arguments for several years, so if you can be bothered, it would be great to continue this.

Yes, I'll keep the Term like it is. It's really better in the long run, or even in the short run.

Oh, and to Nick: you said you have some thing to do in RL; don't let my work bother you! My intention is to produce something reasonably stable and relatively polished, and there is still a long way to go. Also, lately I'm having some vague thoughts about how to make ncurses client work with it... it will take some time before I'll cosider the new text ui a beta! As for now, everything is subject to change without notice, so looking at it too hard is probably not even very useful

[t4nk]

Wow, I didn't expect so many things to work! Making good progress...

https://postimg.org/image/riaon99kb/

edit: Maybe I'll do it sooner than I expected. Player can already move on the map, enter dungeon, take many steps before segfault Probably some arithmetic errors when calculating map offsets...

edit2: term stack in action: https://postimg.org/image/fr46heizp/

[t4nk]

Perhaps some people might want to compile it (hi calris! ) Here's the installation instructions (FOR LINUX):

1) clone my repo and checkout 'textui2' branch:

git clone https://github.com/t4nk074/angband
cd angband
git checkout textui2

2) Install SDL2, SDL2_ttf, SDL2_image libraries and their dev files (headers and sdl2-config utility) - assuming Debian-based system:

apt-get install libsdl2-dev libsdl2-ttf-dev libsdl2-image-dev

(you might also find this useful: https://wiki.libsdl.org/Installation)

3) Configure angband and disable all frontends:

./configure --with-no-install --disable-curses --disable-x11

4) There is a Makefile.ui2 in angband's src directory. Just use it:

cd src
make -f Makefile.ui2

Note that it compiles without optimizations and with address sanitizer enabled, but I found performance to be ok.

5) Now, if everything is ok, you should be able to run Angband with Text UI2 and SDL2:

../angband -msdl2

If it doesn't work, let me know! Anyway, works for me

[t4nk]

Really want to nuke the "-more-" prompt... it's buggy and complicates everything

[Carnivean]

Really want to nuke the "-more-" prompt... it's buggy and complicates everything

Does the code present a different method of conveying the information that could be used instead (as opposed to ignoring the rest of the messages)? Such as multiple lines displayed on the screen at once?

[Nick]

Oh, and to Nick: you said you have some thing to do in RL; don't let my work bother you! My intention is to produce something reasonably stable and relatively polished, and there is still a long way to go. Also, lately I'm having some vague thoughts about how to make ncurses client work with it... it will take some time before I'll cosider the new text ui a beta! As for now, everything is subject to change without notice, so looking at it too hard is probably not even very useful

Great, thanks for that.

On the -more- prompt, if you can think of a way of dealing with messages without assuming a dedicated message window, then go for it.

[t4nk]

Does the code present a different method of conveying the information that could be used instead (as opposed to ignoring the rest of the messages)? Such as multiple lines displayed on the screen at once?

There is a separate term for messages. It's optional, though...

On the -more- prompt, if you can think of a way of dealing with messages without assuming a dedicated message window, then go for it.

The problem is that the prompt term (or prompt area, in current angband's ui - the upper line of the term_screen) displays two kinds of messages: messages and prompts from the ui ("Do you want to quit?") and messages from the game core ("You hit the kobold!"). This is just buggy by design...
Well, for now I'll reset the prompt state (the equivalent of message_column) to 0 every time the ui prints a prompt. That should eliminate the worst cases at least.

[t4nk]

I came to the conclusion that the term stack thing was a pretty good idea It works a lot better than I expected. Of course, that's because Angband's UI, in practice, already has this stack - it's just implemented as a linked list (of Term->mem->mem->mem...). Here's the stack with textbox:

https://postimg.org/image/xpxc7js95/

And note that the shop is not drawn on the same term as the map! It's just displayed like that. The map is completely separate from everything else (and doesn't have to be the same size).

[takkaria]

The problem is that the prompt term (or prompt area, in current angband's ui - the upper line of the term_screen) displays two kinds of messages: messages and prompts from the ui ("Do you want to quit?") and messages from the game core ("You hit the kobold!"). This is just buggy by design...

Maybe it looks like a hack from an engineer's perspective, but as far as design goes, I think it's reasonably elegant - the user is always looking at the top line of the screen anyway, and when a prompt is being displayed you don't need to read previous messages.

Under the new term stack model, I could see a case being made for each new term window being given a titlebar with the prompt in it instead - it doesn't really make sense for it to be right at the top if the window that's opened is in the middle of the screen. Then in the curses ui version that can just be printed at the top of the screen again.