[Announce] NPPAngband and NPPMoria 8.0.1 (Qt Port) released

[takkaria]

Originally Posted by Pete Mack

Well, the main-xxx.c files still exist, as does z-term.c, and I see NPP is still using Makefile.inc. So the old Makefile.osx* should be based on V well enough for the OSX port to work with little changes. I suppose you can do this as part of make install instead of copying the directories directly:

        for i in `find lib -type d`; do mkdir -p $(APPDIR)/$i; done
        for i in `find lib -name '*.txt'`; do cp -fb $(APPDIR)/$i; done

And yes, Makefile.osx and Makefile.win still exist on NPP, since it is reasonable not to expect users to install Qt just to play.

I'm not wanting to be difficult, but I don't think you're looking at NPP 8. There are no makefiles or main-* files there.

[Pete Mack]

I see. I was looking at NPPWip, which is apparently not where new development is happening :/

Originally Posted by takkaria

I'm not wanting to be difficult, but I don't think you're looking at NPP 8. There are no makefiles or main-* files there.

[nppangband]

Yes. It would be incredibly difficult to compile or code NPP with anything but QT creator from this point out.

Thanks Takkaria for the suggestion about the directory structure. Once I got everything in the right place, QT made the bundle on its own. Assuming it included all of the dependencies, it should work now.

[nppangband]

Originally Posted by Pete Mack

I see. I was looking at NPPWip, which is apparently not where new development is happening :/

The current NPP source is now at https://github.com/nppangband/NPPAngband_QT. I need to update my autosignature or now that the QT port is done merge it back with the original NPP Github repository. Although it would me more of a total replacement than a merge. I don't think a single file survived the transition, except perhaps the "THANKS" and "AUTHORS" files.

[Pete Mack]

I hate to be the one to say it, but I don't think I would want to contribute to that code. The Qt stuff is not well isolated, so a lot of stuff that was handled by simple menus is more complicated now.
It isn't great, but Angband has at least some amount of MVC* abstraction, and it was developing ever so slowly in that direction.** I don't see that plan in the Qt port.

Going by what I was familiar with, the knowledge code is something like 3x longer than it is in V, and it is no longer automatic to add new knowledge groups. For example, compare knowledge-monster.c with lines 1048-1325 in V ui-knowledge.c. Similarly compare qt_commands.c with cmd-core.c. In both examples, the controller and view have been separated in V but are now mixed together in the Qt port. And the separation took a lot of effort from various individuals (UnAndrew, Nick, Andrew, "magnate", myself, and many others.)

*Model-view-controller.
https://en.wikipedia.org/w/index.php...iew-controller

** At least to the extent that unsightly display stuff should be hidden from polite view.

Originally Posted by nppangband

The current NPP source is now at https://github.com/nppangband/NPPAngband_QT. I need to update my autosignature or now that the QT port is done merge it back with the original NPP Github repository. Although it would me more of a total replacement than a merge. I don't think a single file survived the transition, except perhaps the "THANKS" and "AUTHORS" files.

[bio_hazard]

I can confirm loading seems to be working now on OSX- I was able to slip the last savefile into the package and it opens on initial and subsequent launches.

I don't have a ton of time now but I'll try to give some UI/gameplay feedback when I have a chance to head back into the dungeon.

[shadow]

Using the roguelike keyset here in NPPMoria... when moving the cursor while targeting, vi keys don't seem to work.

[nppangband]

Originally Posted by Pete Mack

I hate to be the one to say it, but I don't think I would want to contribute to that code. The Qt stuff is not well isolated, so a lot of stuff that was handled by simple menus is more complicated now.
It isn't great, but Angband has at least some amount of MVC* abstraction, and it was developing ever so slowly in that direction.** I don't see that plan in the Qt port.

Going by what I was familiar with, the knowledge code is something like 3x longer than it is in V, and it is no longer automatic to add new knowledge groups. For example, compare knowledge-monster.c with lines 1048-1325 in V ui-knowledge.c. Similarly compare qt_commands.c with cmd-core.c. In both examples, the controller and view have been separated in V but are now mixed together in the Qt port. And the separation took a lot of effort from various individuals (UnAndrew, Nick, Andrew, "magnate", myself, and many others.)

*Model-view-controller.
https://en.wikipedia.org/w/index.php...iew-controller

** At least to the extent that unsightly display stuff should be hidden from polite view.

All valid points. The organization of the codebase is only as good as I know how to make it. And I am most definitely not an experienced programmer, so it probably isn't that good. Also please bear in mind I was learning C++, object oriented programming, and Qt on the go while creating the port. And much of the code design was a trade-off of time vs. "quality programming".

The knowledge code is a great example. It is the same code in 5 different places with some re-named variables and slightly different criteria for determining content (terrain, objects, ego items, artifacts, and monsters) It could be done much cleaner and better, but then it would have taken me much longer, especially since I am learning as I go. On the other hand, IMHO the hotkey interface is one of the more pronounced improvements.

I also agree there is no way the vanilla code could adopt this as one of its ports. The QT port would be an all-or-nothing venture.

The biggest advantage is this: So far, the total # of lines of code unique to a single operation systems is........6. And it works on Windows, OSX, and any Linux OS that supports QT. With a few more optional toolbars the QT port is close to being easier and quicker to play with a mouse than with a keyboard. After that, a version that is playable on an IPad and android tablets, using a complete touchscreen interface. Then hopefully a new audience of players for Angband who would have never given it a chance with the old UI.

[Pete Mack]

I totally see the benefit of Qt. My complaint is that the Q* stuff is showing up where I would least expect it. My recommendation would have been be to first write a main-qt.c file, then start taking chunks out by replacing the stat panel, rewriting ui-menu.c for Qt menus, character page, etc. Study up on MVC (or more properly MVP) and see how your application can benefit from the idea. As an example of a negative result, your changes have pretty much guaranteed that html dump files broken, and will be painful to re-implement.

The old view was just a grid that automatically displayed grid elements. This was hugely useful for basic cave features. It's not so good for menus and the stats panel. So figure out how to break those out of the grid view.


Take a look at what Andrew Doull (UnAndrew) has done with UnAngband. He has done a lot of the work in a very clean manner. And I see from his blog page that he just made a new release, though GitHub does not reflect it.

Originally Posted by nppangband

All valid points. The organization of the codebase is only as good as I know how to make it. And I am most definitely not an experienced programmer, so it probably isn't that good. Also please bear in mind I was learning C++, object oriented programming, and Qt on the go while creating the port. And much of the code design was a trade-off of time vs. "quality programming".

The knowledge code is a great example. It is the same code in 5 different places with some re-named variables and slightly different criteria for determining content (terrain, objects, ego items, artifacts, and monsters) It could be done much cleaner and better, but then it would have taken me much longer, especially since I am learning as I go. On the other hand, IMHO the hotkey interface is one of the more pronounced improvements.

I also agree there is no way the vanilla code could adopt this as one of its ports. The QT port would be an all-or-nothing venture.

The biggest advantage is this: So far, the total # of lines of code unique to a single operation systems is........6. And it works on Windows, OSX, and any Linux OS that supports QT. With a few more optional toolbars the QT port is close to being easier and quicker to play with a mouse than with a keyboard. After that, a version that is playable on an IPad and android tablets, using a complete touchscreen interface. Then hopefully a new audience of players for Angband who would have never given it a chance with the old UI.

[nppangband]

Originally Posted by Pete Mack

I totally see the benefit of Qt. My complaint is that the Q* stuff is showing up where I would least expect it. My recommendation would have been be to first write a main-qt.c file, then start taking chunks out by replacing the stat panel, rewriting ui-menu.c for Qt menus, character page, etc. Study up on MVC (or more properly MVP) and see how your application can benefit from the idea.

We actually started with nothing, and built the foundation of the codebase and main window from scratch. We went through feature by feature and either re-wrote the code or copied it in and converted it to Qt/C++.

Originally Posted by Pete Mack

As an example of a negative result, your changes have pretty much guaranteed that html dump files broken, and will be painful to re-implement..

I confess this comment confuses me. The game has HTML character dumps and both html and png screenshots. It was pretty simple to get working.

Originally Posted by Pete Mack

The old view was just a grid that automatically displayed grid elements. This was hugely useful for basic cave features. It's not so good for menus and the stats panel. So figure out how to break those out of the grid view..

They are broken out. All communication with the player comes in the form if dialog boxes and on-screen widgets. The sidebar and message bar are in different widgets, are not displayed in a "grid format", and do not interact or overlap with the dungeon grid at all.

Originally Posted by Pete Mack

Take a look at what Andrew Doull (UnAndrew) has done with UnAngband. He has done a lot of the work in a very clean manner. And I see from his blog page that he just made a new release, though GitHub does not reflect it.

It might not appear like it at first glance, but the game actually has a very clean and organized core/ui split. The files starting with "qt_" pertain to the permanent screens and windows. Most of the complicated dialog boxes have their own dedicated files. The main object-oriented classes have their own dedicated files. There are a couple smaller simpler dialogs that are in the same file as the related code, just for convenience.

As for separating the It is impractical to separate the view and the controller code because in Qt they are one and the same. The whole game is event-driven. Part of the process of creating a widget the player sees onscreen is to add the commands for what to do when the player interacts with the widget.
As an example:

Here is the code from inside the loop that adds the birth option checkboxes to the birth screen:

QCheckBox *this_checkbox = new QCheckBox(opt_ptr->description);
this_checkbox->setChecked(op_ptr->opt[idx]);
this_checkbox->setToolTip(get_help_topic(QString("option_info"), opt_ptr->name));
group_options->addButton(this_checkbox, idx);
return_layout->addWidget(this_checkbox);
 connect(group_options, SIGNAL(buttonClicked(int)), this, SLOT(option_changed(int)));

The first two lines are self-explanatory. They create the checkbox, and decide if it should be created checked or not. (View)
The setToolTip command instructs the game what to display during a mouse hover . in this case, the option description from the help menus. (Another view command) Group_options is a single command for all the checkboxes (Controller). The connect command a couple lines down links together the core code, the view, and the controller. The game gives off a SIGNAL when the checkbox is clicked, which instructs the game to run the command listed in the SLOT (the controller). The SLOT command must be part of the same class as the widget to which it is connected. The option_changed function interacts with the core code to change the option. Finally, the return_layout command in an instruction for where on the dialog box the widget appears. Qt takes care of everything else, such as waiting or inputs, checking/unchecking the box or deciding if the mouse is hovering over the widget. To break that code apart defeats the whole purpose of Qt.

I might be completely missing your point. Again, my knowledge of coding and computers is a small fraction of the members of the devteam.