NPPAngband/NPPMoria QT port

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

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

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

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

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]

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

Not garbage at all. That would work.

Only I predict that once you & the devteam get a taste of all the possibilities of QT you all will become addicts like me.

[Nick]

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.

Right, that fits with my understanding.

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.

OK, now you're talking.

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.

This is precisely what I believe the plan should be for V. What we have currently done is split the code so that no game code depends on the UI, so we have a set of game files and a set of UI files. So those UI files then become the "Text UI", and we translate them to make another version, which is the "Qt UI". Then the game can be built with either.

The beauty of this is we already have a functioning game which can be developed in parallel with the writing of the Qt UI, and the two don't have to interfere with each other.

In the end, Jeff, I think we'll have you porting NPP back to the V game engine

[Zireael]

This port is looking better and better!

[nppangband]

Thank you. There are some extremely quirky bugs I am trying to figure out, and I am working on improving some of the dialog boxes before putting out a beta for people to try out. Soon.....

[Diego Gonzalez]

Yes, every dungeon grid has a QGraphicsItem. And every animated object too. It's easier to let Qt do all the redrawing and cleaning of the items underside your animation. QGraphicsItem also can receive events so it's simpler to grab mouse clicks and things like that.
Every time we need to animate something we create a custom graphics item that is only an empty rectangle where you can draw things. Qt handles all the stuff related to the whole scene. Like this:

When the beam item is hidden or destroyed Qt redraws everything under it. Really a piece of cake.
This image also shows the pseudo-ascii mode. Tiles are used for everything except player and monsters.
Tiles are handled in a different way now. All tilesets are accesible at any time. But the tileset is not loaded in memory. The specific tile is fetched on demand. To reduce disk access the game has a couple of tile caches to store the most used tiles, like walls and floors. I think that this scheme works quite fast.

[AnonymousHero]

Yes, every dungeon grid has a QGraphicsItem. And every animated object too. It's easier to let Qt do all the redrawing and cleaning of the items underside your animation. QGraphicsItem also can receive events so it's simpler to grab mouse clicks and things like that.
Every time we need to animate something we create a custom graphics item that is only an empty rectangle where you can draw things. Qt handles all the stuff related to the whole scene. Like this:

When the beam item is hidden or destroyed Qt redraws everything under it. Really a piece of cake.
This image also shows the pseudo-ascii mode. Tiles are used for everything except player and monsters.
Tiles are handled in a different way now. All tilesets are accesible at any time. But the tileset is not loaded in memory. The specific tile is fetched on demand. To reduce disk access the game has a couple of tile caches to store the most used tiles, like walls and floors. I think that this scheme works quite fast.

Great, thanks for the information.

[Diego Gonzalez]

We did some visual effects by changing the size, color and opacity of certain tiles. Qt simplefies those tasks. A bit of particle theory (simplified) was used for some spell effects too.

[AnonymousHero]

We did some visual effects by changing the size, color and opacity of certain tiles. Qt simplefies those tasks. A bit of particle theory (simplified) was used for some spell effects too.

I was mostly concerned about the performance of just doing a "dumb" matrix of QGraphicsItem. (In my initial tests it performed well, but going to 2560x1440 fullscreen there was a bit of a worry. I suspect the problem is actually the fact that in my port I still had a lot of indirection between Angband_Term (struct Term?, whatever) and the actual display code.)

[Diego Gonzalez]

NPP doesn't use the term structure. We still have the old light_spot function. It marks the proper graphics item as dirty. Qt redraws that spot later. At some point, we had separate graphics items for monsters, objects and terrain. But it was slow. Now, the DungeonGrid object takes care of drawing all the dungeon layers in one grid. The code is a bit more complex but faster. Animations and targetting use their own graphic items.
Perhaps you need to reduce the frecuency of full screen redrawings. I had to pay special attention to this problem. Qt is great with this because it takes care of redrawing just the necessary items. We dont have to write the code necessary to redisplay a bunch of grids under an animation with a size of 10x10. The graphics engine does that for us.
Qt doesnt care about a dungeon of grids. It works only with graphics items that overlap each other partially and it knows how to redraw the necessary items when some of them change positions or visibility (most of the time hehe).

[Derakon]

Question, then: how do you handle screen scrolling? Shifting the screen by 1 character effectively dirties every single part of it. Or do you just limit yourself to "big" scrolling? In other words, would a "character is always centered in the screen" option work in NPPQt?

Pyrel uses a canvas for its drawing (and thus manually draws each cell individually), but as a consequence, when the screen scrolls, it can detect that, draw the current screen at an offset, and then manually fix dirtied cells (mostly around the edges).