NPPAngband/NPPMoria QT port

[nppangband]

Update: The development phase for a fully functional NPPQT windows port is finished!

There is some de-bugging to do but a final beta will be out soon.

Ports for Linux and the MAC will follow shortly after that.

[nppangband]

All set to release. Unfortunately the simple days of zipping up the files and uploading them are over. Qt binaries require a release package with all the DLLs.

Step 1) learn how to do a release package.

Is anyone experienced with this process? Thanks to anyone who can offer some help or advice. I am trying to read up on it but I haven't quite gotten my head around it yet.

[Zireael]

We are done coding the beta version, and it is just being de-bugged now. I am down to finding a bug maybe once every 15 minutes of play. When it can be played for an hour without any bugs the beta of the QT port will be released.

That's some great news!

[nppangband]

We are done coding the beta version, and it is just being de-bugged now. I am down to finding a bug maybe once every 15 minutes of play. When it can be played for an hour without any bugs the beta of the QT port will be released.

[Diego Gonzalez]

The canvas has a method, centerOn. It takes care of the current window size and set the scrollbars to the proper coordinates and size. Also we can scroll the canvas view to any grid, if we traslate the dungeon coordinates to canvas coordinates (it depends on the current tile size). How Qt optimizes that, I don't know. Perhaps it uses a big offscreen pixmap and redraws only the edges like you said. A change in the window size is also handled by Qt without our intervention. Once you get used to the idea that the dungeon as a whole doesn't exists anymore and all we have is a bunch of grids that are separately redrawn at any time, some parts of the code get easier to write. Full redraws are rare. If we write a good draw method for one grid everything flows. Well, mostly, because I remember some strange flickering situation that I had to solve with a full screen redraw (that Qt surely limits to the items that are currently visible).

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

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

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

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]

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]

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.

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

[Zireael]

This port is looking better and better!

[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

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