NPPAngband/NPPMoria QT port

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • AnonymousHero
    Veteran
    • Jun 2007
    • 1393

    #91
    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...?

    Comment

    • kaypy
      Swordsman
      • May 2009
      • 294

      #92
      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?

      Comment

      • nppangband
        NPPAngband Maintainer
        • Dec 2008
        • 926

        #93
        Originally posted by 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?
        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 current home page: http://nppangband.bitshepherd.net/
        Source code repository:
        https://github.com/nppangband/NPPAngband_QT
        Downloads:
        https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57

        Comment

        • nppangband
          NPPAngband Maintainer
          • Dec 2008
          • 926

          #94
          Originally posted by 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...?
          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 current home page: http://nppangband.bitshepherd.net/
          Source code repository:
          https://github.com/nppangband/NPPAngband_QT
          Downloads:
          https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57

          Comment

          • nppangband
            NPPAngband Maintainer
            • Dec 2008
            • 926

            #95
            Originally posted by Derakon
            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 current home page: http://nppangband.bitshepherd.net/
            Source code repository:
            https://github.com/nppangband/NPPAngband_QT
            Downloads:
            https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57

            Comment

            • nppangband
              NPPAngband Maintainer
              • Dec 2008
              • 926

              #96
              Originally posted by Nick

              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.
              NPPAngband current home page: http://nppangband.bitshepherd.net/
              Source code repository:
              https://github.com/nppangband/NPPAngband_QT
              Downloads:
              https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57

              Comment

              • Nick
                Vanilla maintainer
                • Apr 2007
                • 9634

                #97
                Originally posted by nppangband
                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.

                Originally posted by nppangband
                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.

                Originally posted by nppangband
                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
                One for the Dark Lord on his dark throne
                In the Land of Mordor where the Shadows lie.

                Comment

                • Zireael
                  Adept
                  • Jul 2011
                  • 204

                  #98
                  This port is looking better and better!

                  Comment

                  • nppangband
                    NPPAngband Maintainer
                    • Dec 2008
                    • 926

                    #99
                    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/1x7k65ghsmc31usmj329pb8415n1ux57

                    Comment

                    • Diego Gonzalez
                      Adept
                      • May 2007
                      • 170

                      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

                      • AnonymousHero
                        Veteran
                        • Jun 2007
                        • 1393

                        Originally posted by 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.
                        Great, thanks for the information.

                        Comment

                        • Diego Gonzalez
                          Adept
                          • May 2007
                          • 170

                          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

                          • AnonymousHero
                            Veteran
                            • Jun 2007
                            • 1393

                            Originally posted by 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.
                            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

                            • Diego Gonzalez
                              Adept
                              • May 2007
                              • 170

                              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

                              • Derakon
                                Prophet
                                • Dec 2009
                                • 9022

                                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

                                Working...
                                😀
                                😂
                                🥰
                                😘
                                🤢
                                😎
                                😞
                                😡
                                👍
                                👎