NPPAngband/NPPMoria QT port

[nppangband]

is this for nppmoria, or just nppangband?

Both. They are in the same codebase.

The way the new UI works is when you open the game, you can start a game of NPPAngband or NPPMoria. If you load a prior character, it detects which game the savefile is for and loads it up.

You can also close up a character in NPPAngband and then play a game in NPPMoria, and vice-versa, without having to exit the program.

[klassik]

yay!!!!!!!!!

[nppangband]

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.

[nppangband]

One final dialog box; the new birth screen. It needs uncluttering, but everything is on one screen. Things don't have to be selected in any particular order any more (gender-race-class-stats-name)Anything can be changed at any time. For the new players, the complete help topic can be called up for every field of information on the screen with a simple mouse hover.

In terms of a basic playable beta, that was the last thing on the list. There are some minor things to clean up, but a release for anyone wanting to playtest and provide feedback will be out shortly. It is missing some important features that would make playing a complete game tedious (the extra windows, macros), but finally the finish line is in sight.




edit: It isn't nearly this big onscreen. Not sure why the png file is so big.

[Carnivean]

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

[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.

[Carnivean]

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

Glad I could help.

[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?

[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.

[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

[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.

[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?

[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.

[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...

[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