Textui reform (warning: long and full of C)

[t4nk]

takkaria, I added some debugging dumping to the frontend (concerting finger events), could you try to use your trackpad for half a minute and then send me the report? (via email, or just post here)
Finger events are really stuff for tablets and the like, though... and I see no evidence that main-cocoa.m listens for them in particular? of course, I don't really understand Objective-C...

[t4nk]

I think there's three things I've noticed/wondered-

I noticed when you get 'full-screen' style popups (options, stores, knowledge menus), there's insufficient contrast between the foreground screen and the background. I was imagining some kind of shading out of things in the background for those screens. Maybe more padding could be a solution as well though, I'm not sure.

https://postimg.org/image/tj0wt5zpr/

Like so? (except probably not COLOUR_RED , more like https://postimg.org/image/5itj6g7mt/) Good idea.

Also for some reason on OS X I can't use my trackpad to click on size or move, I have to use my external mouse. I was going to investigate that; I wonder if SDL uses a different event type for trackpads or something.

Hmmm, I'd expect at least the mouse cursor to move. Apple's own documentation says "When users touch and move their fingers on the trackpads of the MacBook Air and more recent models of the MacBook Pro, OS X generates multitouch events, gesture events, and mouse events. The trackpad hardware includes built-in support for interpreting common gestures and for mapping movements of a finger to mouse events." (if I'm looking at the right place - https://developer.apple.com/library/...uchEvents.html).
I don't know much about OSX (what is MacBook Air? ) Trackpad does work on Linux. I'll see what I can do. There are indeed "finger" events, but normally touch devices should also produce mouse events...

Finally I was thinking about the prompt line, and how maybe some questions should appear in windows instead... in a store when you're buying, you are not looking at the top of the screen, likewise with the options menu when you change the numeric options. I guess looking at the popup that happens for keymap changes made me wonder if modal dialogues might be better in some places.

That's also sensible. I'm really not a designer, keep in mind

[takkaria]

BTW, pull requests and suggestions are welcome!

Sure, I want to hack on it but I've not had time... I think there's three things I've noticed/wondered-

I noticed when you get 'full-screen' style popups (options, stores, knowledge menus), there's insufficient contrast between the foreground screen and the background. I was imagining some kind of shading out of things in the background for those screens. Maybe more padding could be a solution as well though, I'm not sure.

Also for some reason on OS X I can't use my trackpad to click on size or move, I have to use my external mouse. I was going to investigate that; I wonder if SDL uses a different event type for trackpads or something.

Finally I was thinking about the prompt line, and how maybe some questions should appear in windows instead... in a store when you're buying, you are not looking at the top of the screen, likewise with the options menu when you change the numeric options. I guess looking at the popup that happens for keymap changes made me wonder if modal dialogues might be better in some places.

[t4nk]

There's some stuff I'd like to tweak but it's all pretty minor.

BTW, pull requests and suggestions are welcome!

[t4nk]

So I think the only thing missing really is a curses interface for textui2 (and to a lesser extent, OS X), and then I don't see any reason not to switch over.

ncurses support was something I paid some attention to when writing textui2... It will have to incorporate some of the functionality of the current Term (its own arrays of points, to do compositing/"fake transparency", and also ncurses-specific things, like icky corner and signals), but all in all, I think that's one of those things that are relatively easy... Except I'm not familiar with ncurses API, but we'll see

(I use the pronoun 'they' btw, not 'he')

Understood.

[takkaria]

takkaria was following my work on github and his advice and judgement were invaluable. takkaria, I want to ask you to tell your opinion on this project, now that it's in a fairly complete stage. How does it compare to textui1, in terms of functionality and code?

I'd say it's obviously a huge improvement over the current setup. I don't use tiles but I'd imagine anyone who did would find it vastly better in that area. There's some stuff I'd like to tweak but it's all pretty minor. I'm also super impressed by the quality of your code. I think it would be a lot easier to do a decent port for Android or iOS, too.

About merging... it doesn't make any sense to have textui & textui2 at the same time. So I think the only thing missing really is a curses interface for textui2 (and to a lesser extent, OS X), and then I don't see any reason not to switch over.

(I use the pronoun 'they' btw, not 'he')

[t4nk]

When I said "third party software", I meant software that makes these kinds of screenshots:

https://postimg.org/image/yjiaslzgz/

If this site doesn't have enough storage capacity for those, other sites can be used. I certainly don't think that screenshotting functionality justifies the existence of two additional commands. Angband has way too many commands.
Even if someone (who's not I) will decide to restore html screenshots, I'd strongly suggest not to make it a command, but put it somewhere in options, since the options menu doesn't overwrite the map.

[AnonymousHero]

This is the only one I have doubts about - I'm not sure whether the ladder screenshot gallery (see the 'Screenshots' tab at the top of the page) has constraints on what html it accepts.

That, and, it's not exactly easy to get HTML out of a screenshot of a graphical window (e.g. anything non-curses).

(Not that I personally care much about these screen shots, but I imagine some people would.)

[Nick]

Excellent - I haven't checked it lately, but takkaria has and tells me it's looking good.

'(' and ')' (text/html screenshots; use third party software instead)

This is the only one I have doubts about - I'm not sure whether the ladder screenshot gallery (see the 'Screenshots' tab at the top of the page) has constraints on what html it accepts.

[t4nk]

currently I'm in the middle of the third refactor of the ui

And I think it's done.

While textui2 doesn't have (yet?) some of the features that I talked about - minimap, better macros, improved handling of messages, separate tiles, drawing API (lines and, as takkaria suggested, rectangles) - the core of it is essentially complete and the game is fully playable. The most notable change is that all ui elements are drawn on their own "canvases"; there are now many of those, and there is no ANGBAND_TERM_MAX.
There were very few changes in the core: the includes are changed (obviously) and textui2 doesn't handle signals anymore. The way that textblock splits lines (textblock_calculate_lines()) was changed. The store commands update gold amount (player->au) immediately, since now the sidebar is visible even when the player is in store. redraw_stuff() doesn't block full map redraws when the player is running. And, I think, that's pretty much it.
I removed some of the commands (and wanted to remove a lot more, but probably others wouldn't agree ): '/' ("identify symbol"; use knowledge menus instead), '(' and ')' (text/html screenshots; use third party software instead), Ctrl-O ("show previous message"; use Ctrl-P instead), Ctrl-V ("show version"; use help screen instead), Ctrl-R ("redraw screen"; use nothing instead) and Ctrl-G (do you know that it exists? that's right, Angband even has a command that's doing nothing at all!).
I think, all in all, it's still very clearly looks and feels like the Angband UI (unlike, say, NPP's UI). That was one of the main goals.
takkaria was following my work on github and his advice and judgement were invaluable. takkaria, I want to ask you to tell your opinion on this project, now that it's in a fairly complete stage. How does it compare to textui1, in terms of functionality and code?
I probably won't be pushing so many new commits anymore. For example, I can't bring myself to work on tilesets... just don't like any of them enough. There are still things that could be done, and some of those are not difficult to do, so I will probably do that. No promises anymore, though! I think textui2 is "reasonably stable and relatiely polished" and won't change in significant ways. So take it or leave it.

[t4nk]

Still don't know what to do with the char screen. Think I'll go with this variant:

https://postimg.org/image/5ohwuhz83/

https://postimg.org/image/68fuv45ur/

At least that gave me an idea to get rid of the "18/666" notation for stats. Other than that, yeah, I'm not a designer...

edit: No, it still looks like crap. Reverted.
edit: No, it's better than the old screen. Unreverted

[t4nk]

Exciting! I just managed to get this working on OS X. Using Makefile.ui2 worked (with some tweaks) once I got SDL2 installed. It's pretty amazing to see tiles render separately to the rest of the text at last...

Expect bug reports and the like soon

Wow, a real user! Note that currently I'm in the middle of the third refactor of the ui, fixing various bugs (that I can find) and making the ui look better; here are the files that still need to be refactored

main2-sdl2.c

ui2-birth.c
ui2-birth.h
ui2-context.c
ui2-context.h
ui2-curse.c
ui2-curse.h
ui2-input.c
ui2-input.h
ui2-keymap.c
ui2-keymap.h
ui2-menu.c
ui2-menu.h
ui2-mon-list.c
ui2-mon-list.h
ui2-mon-lore.c
ui2-mon-lore.h
ui2-obj-list.c
ui2-obj-list.h
ui2-output.c
ui2-output.h
ui2-player.c
ui2-player.h
ui2-prefs.c
ui2-prefs.h
ui2-term.c
ui2-term.h
ui2-wizard.h
ui2-wiz-debug.c
ui2-wiz-spoil.c
ui2-wiz-stats.c

Bug reports and suggestions are certainly very welcome That, naturally, also applies to all other files:

ui2-command.c
ui2-command.h
ui2-death.c
ui2-death.h
ui2-display.c
ui2-display.h
ui2-event.c
ui2-event.h
ui2-game.c
ui2-game.h
ui2-help.c
ui2-help.h
ui2-history.c
ui2-history.h
ui2-init.c
ui2-init.h
ui2-knowledge.c
ui2-knowledge.h
ui2-map.c
ui2-map.h
ui2-object.c
ui2-object.h
ui2-options.c
ui2-options.h
ui2-score.c
ui2-score.h
ui2-spell.c
ui2-spell.h
ui2-store.c
ui2-store.h
ui2-target.c
ui2-target.h

There are quite a few known (to me ) bugs, especially related to tiles, but feel free to report anything!
edit: Fixed a couple, hopefully that will make it easier for you to test it!

[takkaria]

Exciting! I just managed to get this working on OS X. Using Makefile.ui2 worked (with some tweaks) once I got SDL2 installed. It's pretty amazing to see tiles render separately to the rest of the text at last...

Expect bug reports and the like soon

[t4nk]

Restored the debug commands. Some of them look pretty buggy to me, but the game warns you that they're "dangerous" and "unsupported"! Anyway, I was able to summon a stone troll and generate object spoiler file, so I think it works, for the most part.
At this point textui2 has essentially the same functionality as textui1, so perhaps it's a good time to talk what was done and what still has to be done...
The game is fully playable (assuming absense of game-breaking bugs... ). The '@' can be born, can move on the map, attack monsters, pick up items, can interact with stores, use equipment, inventory and quiver menus, cast spells, can be controlled by the mouse, display help files and knowledge screens, change game options, can die and can cheat.
Looking back at the original post...
1) term_screen reform - done. The main map was separated from all other ui elements, and only the contents of the dungeon is displayed on it.
2) Term_fresh() reform - almost done. It's pretty much as I described in the OP. Just about the only thing left to do is speeding up breath animations (60 tiles/sec is a bit too slow for them, IMO)
(edit: I just noticed that I was testing with op_ptr->delay factor 40! Actually, 60 tiles/sec is pretty ok).
(edit: done now. Term_fresh() reform is complete!)
3) Input reform - done. All the low level input and output routines were rewritten pretty much from scratch.
4) Colors reform - halfway done. All of the ui uses uint32_t for colors, and background color information is separate from font glyph color info (that is, no "a / MAX_COLORS"); other then that, it's still essentially the same. As takkaria and Pete Mack noted, more far-reaching reform wouldn't be approprate for the game "Angband"; but, if someone wanted to create a more colorful game, this is now significantly easier to do.
5) Tilesets reform - nothing done yet; it's the same as it was (int col = wchar_t & 0x7F)...

There are plenty of things to do still:
a) Finding and fixing various bugs.
b) Actually doing something with tilesets.
c) Different sizes for tiles (as in, 50%, 60%, ..., 150%, ...)
d) Mouse cursor? (highlighting the tile that is pointed at by the mouse)
e) Making the ui look better in general. It was designed with some assumptions in mind, which are no longer true. For example, inventory menu: https://postimg.org/image/3q8oadogh/ Why does it have so much space on the right? Well, that's how it always was... But it's not necessary now, and doesn't look good.
There is also this thread with some interesting food for thought.
f) New features - minimap, better handling of messages... monster and player hitpoints on top of their tiles? (including in text mode, a la NPPQT)
g) Optimizations - I found the performance is generally ok even with "-O0 -fsanitize=address -fsanitize=undefined" on a pretty old laptop, but the ui is certainly doing more then necessary, and there is a bit of lag, noticeable with "center player" option on. Think I'll just reimplement "diff" optimization from old ui, since it is easy to do and proven to work. Another good thing to do is reduce the number of calls to event_signal_point(EVENT_MAP, -1, -1), including in core. For example, disturb() does this, and it's pretty useless, as far as I can tell.

But anyway, I think at this point it's fair to say that Text UI2 is a thing that exists and works.

[t4nk]

I liked this one

Too late! This is how it looks like now:

https://postimg.org/image/c8pfcybpj/

I think this objectively gives more information: "1 2 3 ... 9 A B" implies some kind of ordered list of something, while "Ils Mls" just doesn't mean anything at all.

Anything that cuts into vertical screen space is a problem on small screens. So it should be possible to suppress any titles

The status bar (the thing on top of screen) is a feature of the frontend, not of text ui. I'm doing all development on a laptop, and it's ok there. Personally I'm not interested in adapting this frontend to tablets, cells phones, calculators and what not.