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...?
NPPAngband/NPPMoria QT port
Collapse
X
-
-
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 current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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 current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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 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 current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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
Only I predict that once you & the devteam get a taste of all the possibilities of QT you all will become addicts like me.NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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.
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.
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 engineOne for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.Comment
-
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.....NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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.Last edited by Diego Gonzalez; February 12, 2015, 15:29.Comment
-
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.Comment
-
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.Comment
-
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.)Comment
-
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).Comment
-
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).Comment
Comment