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.
Textui reform (warning: long and full of C)
Collapse
X
-
I came to the conclusion that the term stack thing was a pretty good ideaIt 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:
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).Leave a comment:
-
Originally posted by NickOn the -more- prompt, if you can think of a way of dealing with messages without assuming a dedicated message window, then go for it.
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.Leave a comment:
-
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
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.Leave a comment:
-
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?Leave a comment:
-
Really want to nuke the "-more-" prompt... it's buggy and complicates everythingLeave a comment:
-
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:
Code:git clone https://github.com/t4nk074/angband cd angband git checkout textui2
Code:apt-get install libsdl2-dev libsdl2-ttf-dev libsdl2-image-dev
3) Configure angband and disable all frontends:
Code:./configure --with-no-install --disable-curses --disable-x11
Code:cd src make -f Makefile.ui2
5) Now, if everything is ok, you should be able to run Angband with Text UI2 and SDL2:
Code:../angband -msdl2
Last edited by t4nk; August 14, 2016, 07:58.Leave a comment:
-
Wow, I didn't expect so many things to work! Making good progress...
edit: Maybe I'll do it sooner than I expected. Player can already move on the map, enter dungeon, take many steps before segfaultProbably some arithmetic errors when calculating map offsets...
edit2: term stack in action: https://postimg.org/image/fr46heizp/Last edited by t4nk; August 13, 2016, 11:57.Leave a comment:
-
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 usefulLeave a comment:
-
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.Leave a comment:
-
Returning to SDL2 frontend feels so goodIt'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:
Code:/* Verify */ if ((x < 0) || (x >= w)) return (-1); if ((y < 0) || (y >= h)) return (-1);
Code:assert((x) >= 0); \ assert((x) < TOP->width); \ assert((y) >= 0); \ assert((y) < TOP->height); \
Code:angband: ui2-term.c:339: term_wipe_line: Assertion `(y) < (term_stack.stack[term_stack.top])->height' failed. Aborted
Leave a comment:
-
Bump
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.Leave a comment:
-
Bump
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.Last edited by t4nk; August 11, 2016, 11:10.Leave a comment:
-
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 availableLeave a comment:
-
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 availableLeave a comment:
Leave a comment: