NPPAngband/NPPMoria QT port

[nppangband]

Oof, that's unfortunate. Qt shouldn't inherently go against the idea of having a core-UI split; Pyrel has a strong core-UI split and one of the front-ends uses Qt, for example. In fact, Vanilla's new, well-defined separation between the game state and the user interface should make it a lot easier to have a Qt front-end now.

Porting Vanilla to the NPP engine would be effectively throwing away all of the work that the devs have been doing for the better part of the last year. Somehow I suspect they aren't going to be in favor of that plan.

In thinking about it, it wouldn't be that bad. I chose to use QStrings for all string manipulation, but Vanilla could bypass that if it chose to. All of the string manipulation functions in util.c could be modified to simply produce QStrings and pass them on to the front-end UI. That would remove most of the necessary code modifications.

In a way, we unintentionally did do a core-UI split, but in a different manner than vanilla. All user input is handled by actions, dialogs, and events. There is no function like "inkey" in vanilla.

All of the QT screen output is handled by only a couple files. It could exist alongside ports with a couple well chosen #defines like the game does now for the various ports. It would even be possible for the QT port to be a C++ program while all the other ports continue to be a C program. It would all be extremely ugly coding, but it is possible.

[nppangband]

Btw, @nppangband: I guess I could just look at the code, but being lazy I thought I'd ask: How did you end up coding the dungeon (terminal) display? QGraphicsItem, QML, or...?

An excellent question. Diego did that part. ::checks::

The basic "canvas" is a QMainWindow. It has a QGraphicsView and a QGraphicsScene that work together to display widgets onscreen.

Et looks like each dungeon square has its own QGraphicsItem. The QMainWindow has a 2D array of a QGraphicsItem class assigned to each square in the dungeon (DungeonGrid). DungeonGrid has plenty of methods to handle the size, onscreen location, and visible image for each square. It looks like when things need to be temporarily painted over the top, such as monster breath and targeting grids, the underlying DungeonGrid is left intact. A new QGraphics item is simply placed over the top of it and then deleted.

All the code is inside qt_mainwindow.cpp and emitter.cpp. I barely understand it. Thank God for Diego.

[nppangband]

A question regarding that options page from a while back:

What happens if the screen size is too small? Will you get eg a scrollable pane or will you just be unable to access the lower and right halves of the window?

QT *should* shrink the dialog and use smaller fonts, etc. This is the advantage of drawing the dialog boxes with code instead of using the dialog designer, and making absolutely no assumptions about the # of pixels high or wide any widget should be.

I have tried it on a 24 inch monitor, a 19 inch windows laptop, and a 13 inch MacBook, and it handles the resizing extremely well. I think tablets will display well also. If Qt handles resizing perfectly on smartphones as well, than I shall be truly be amazed and impressed.

I look forward to hearing from people on different OSs and screens how well this works.

[kaypy]

A question regarding that options page from a while back:

What happens if the screen size is too small? Will you get eg a scrollable pane or will you just be unable to access the lower and right halves of the window?

[AnonymousHero]

Btw, @nppangband: I guess I could just look at the code, but being lazy I thought I'd ask: How did you end up coding the dungeon (terminal) display? QGraphicsItem, QML, or...?

[Nick]

I've been sort-of-contemplating porting my T2.x Qt5.x work to post-restruct Vanilla. I've gone in the just-assume-it's-a-dumb-terminal direction, so it shouldn't be that much work, hopefully. My port is based on the idea of "command channel" between two threads, currently just "keystrokes" from UI->Game thread and "UI updates" from Game->UI. Without having looked at the new Vanilla code, I would probably need to split out all the front ends out into separate main functions (and executables) because Qt is very finicky about which thread does what -- so much so that it became a complete hack to ensure that the UI got started in the correct (main) thread and the game logic got a separate (background) thread.

Anyway...

This would be wonderful. I think what we have done will fit in pretty well with this plan. Certainly the game core does not now depend on the UI at all, but there are still places where the UI directly affects the game core - that may need to be turned into message passing, I don't know. And if you were to find places where the separation needed to be more complete, then that's an improvement we would like to make anyway.

I suspect that the way the new NPP would contribute to any Vanilla Qt port would chiefly be by already having solved most of the UI problems. The difference is that functions which for Vanilla would live just in the UI will be made up of pieces found in different places in the NPP code.

Or possibly I'm just talking garbage

[AnonymousHero]

Oof, that's unfortunate. Qt shouldn't inherently go against the idea of having a core-UI split; Pyrel has a strong core-UI split and one of the front-ends uses Qt, for example. In fact, Vanilla's new, well-defined separation between the game state and the user interface should make it a lot easier to have a Qt front-end now.

Porting Vanilla to the NPP engine would be effectively throwing away all of the work that the devs have been doing for the better part of the last year. Somehow I suspect they aren't going to be in favor of that plan.

I've been sort-of-contemplating porting my T2.x Qt5.x work to post-restruct Vanilla. I've gone in the just-assume-it's-a-dumb-terminal direction, so it shouldn't be that much work, hopefully. My port is based on the idea of "command channel" between two threads, currently just "keystrokes" from UI->Game thread and "UI updates" from Game->UI. Without having looked at the new Vanilla code, I would probably need to split out all the front ends out into separate main functions (and executables) because Qt is very finicky about which thread does what -- so much so that it became a complete hack to ensure that the UI got started in the correct (main) thread and the game logic got a separate (background) thread.

Anyway...

[Derakon]

I think we *really* went in opposite directions. Using QT is kind of the opposite of a core-ui split. QT appears in every single line of string/character manipulation and throughout the codebase.

Oof, that's unfortunate. Qt shouldn't inherently go against the idea of having a core-UI split; Pyrel has a strong core-UI split and one of the front-ends uses Qt, for example. In fact, Vanilla's new, well-defined separation between the game state and the user interface should make it a lot easier to have a Qt front-end now.

Porting Vanilla to the NPP engine would be effectively throwing away all of the work that the devs have been doing for the better part of the last year. Somehow I suspect they aren't going to be in favor of that plan.

[nppangband]

It looks super good.

Minor nitpick: the text on the left hand side of the in-game screen is hard to read. I think it'd look better if the text was left-justfied and the numbers were right-justified, and also if the numbers used comma separators (e.g. 1,000,000 rather than 1000000).

Also I'd kinda prefer a monospace font for this sort of thing but maybe I'm just old fashioned.

A.

answer to klassic - While I am currently de-bugging the play testing version, it is not yet a complete port. It is probably close to the end of the year before it would be ready for Vanilla to consider a QT port.

To Antoine: Yes, the sidebar needs some cleaning up. Same with the message line (you all don't need to see the game turn count with every message). Those were done hastily while we were testing the new event-driven game commands. We were trying to confirm basic game mechanics like: Does the player heal when resting? Do monsters and the player gain an equal amount of energy if they are the same speed. Do the commands burn off the proper amount of energy? Do the monsters get unfair double-turns? Do repeated commands work properly?

[nppangband]

Well, technically we're in a position to now, but it's a lot of work - we've kind of done things in the opposite order to NPP, and so how long it will take us to meet up again is an interesting question

I wrote a patch that makes it pretty simple:

src/defines.h
@@ -48,18 +48,18 @@
 
 
 /*
  * Name of the version/variant
  */
-#define VERSION_NAME "NPPAngband"
+#define VERSION_NAME "Angband"
 
-#define VERSION_MODE_NAME (game_mode == GAME_NPPMORIA ? "NPPMoria" : "NPPAngband")
+#define VERSION_MODE_NAME "Angband"
 
 /*
  * Current version string
  */
-#define VERSION_STRING	"8.0.0"
+#define VERSION_STRING	"6.0.0"
 
 
 /*
  * Current version numbers
  */

{Just Kidding} I think we *really* went in opposite directions. Using QT is kind of the opposite of a core-ui split. QT appears in every single line of string/character manipulation and throughout the codebase.

Plus, there is now a lot of C++ code in NPP. So working the NPP changes into the vanilla codebase would be time consuming.

But the opposite is possible. Since C is almost entirely a subset of C++, it actually wouldn't be too hard to copy the vanilla game into the NPP codebase and keep the QT UI, and wipe out all the NPP code that differs from vanilla.

[Nick]

wow!!! when will vanilla copy this?

Well, technically we're in a position to now, but it's a lot of work - we've kind of done things in the opposite order to NPP, and so how long it will take us to meet up again is an interesting question

[Antoine]

It looks super good.

Minor nitpick: the text on the left hand side of the in-game screen is hard to read. I think it'd look better if the text was left-justfied and the numbers were right-justified, and also if the numbers used comma separators (e.g. 1,000,000 rather than 1000000).

Also I'd kinda prefer a monospace font for this sort of thing but maybe I'm just old fashioned.

A.

[klassik]

Here is a sample of the statusbar, albeit for an absurd wizard mode character.

The icons, from left to right, tell the player:
1) They are not currently searching. You can click the icon to search, or enter the keyboard command.
2) Food status, currently full.
3) The character can learn 47 new spells (the absurd part). The player can click on the icon to study, as well as access the command by keyboard.
4) As the mouse hover shows, trap detect has not been cast.

There are icons for all temporary status (word-of-recall, heroism, resist fire, etc) that will pop up when the state is active.



The final feature before this will be playtestable beta is the character screen. There are not yet macros, multiple windows, character dumps and a couple other features, but anyone willing to playtest the basic new UI will get the chance very soon.

wow!!! when will vanilla copy this?

[Carnivean]

(which, oops! I forgot to add a title to the widget)

Glad I could help.

[nppangband]

That looks very static. If you add more birth options, what happens to the text below it? Likewise for classes/races.

While it doesn't look it, it is all dynamic. That is what is taking so long. This is all done with code that draws and updates each box.

The way QT works, each group of buttons is inside a box, or "layout". The top half is one long horizontal layout, with 6 layouts nested inside of it, some of which are vertical layouts, and some of which are "grid" layouts. The bottom half another horizontal layout, with 4 vertical layouts inside of it and 1 "grid" layout. Both of those horizontal layouts are inside of another vertical layout, which also has a third section for the two buttons at the bottom right. That vertical layout is placed inside of a basic widget with a title bar (which, oops! I forgot to add a title to the widget). So if one of the vertical layouts inside of a horizontal layout got larger, the entire horizontal layout gets longer, and the second horizontal layout gets moved down to accommodate it. If it is all too big for the screen, it shrinks everything until it fits.

Between all those blocks are spacers that ensure things stay in the same alignment. For example, when starting a game of NPPMoria, there are only about 4 birth options, and less classes and races. It all appears in the same layout, but with spacing at the bottom of each block. If 5-6 more races were added in race.txt, that would be the longest column in the top half and everything else would be spaced accordingly.

When the player switches from point based to auto-roller, the combo boxes for buying and selling stats become ordinary labels for the base stat, the two labels pertaining to points disappear, and a button for "roll player" appears. If maximize mode is disabled, the two columns showing race adjustment and class adjustment disappear in the bottom right, and re-appear if it is enabled again.