Tears unnumbered ye shall shed

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • debo
    Veteran
    • Oct 2011
    • 2402

    If forced descent were a thing, I imagine deep descent would have to go. That would be... awful. Like, "I will delete this from my local copy if you don't change it" awful
    Glaurung, Father of the Dragons says, 'You cannot avoid the ballyhack.'

    Comment

    • fizzix
      Prophet
      • Aug 2009
      • 3025

      Originally posted by debo
      If forced descent were a thing, I imagine deep descent would have to go. That would be... awful. Like, "I will delete this from my local copy if you don't change it" awful
      It's not that bad...but it should probably go back to dropping you 2 levels. Considering that you usually ID scrolls on the downstairs, this means you only lose one level, which honestly, is not that big of a deal.

      Comment

      • PowerWyrm
        Prophet
        • Apr 2008
        • 2986

        Unless you play pure ironman, you can still sell unID scrolls to shops to avoid reading an unID scroll of deep descent. Usually you won't lose anything valuable by doing so (though I sold an unID scroll of acquirement once that way in a game not so long ago).
        PWMAngband variant maintainer - check https://github.com/draconisPW/PWMAngband (or http://www.mangband.org/forum/viewforum.php?f=9) to learn more about this new variant!

        Comment

        • AnonymousHero
          Veteran
          • Jun 2007
          • 1393

          Originally posted by PowerWyrm
          Unless you play pure ironman, you can still sell unID scrolls to shops to avoid reading an unID scroll of deep descent. Usually you won't lose anything valuable by doing so (though I sold an unID scroll of acquirement once that way in a game not so long ago).
          Heh, maybe that's a kind of emergent strategy with the new 3.5-git drops: Never sell any consumable of which you only have 1.

          (That's my experience at least: Immediately identify (by selling) one of any consumable of which you have more than one. Keep ?oIdentify for any consumables you have accumulated no more than one of during the past few levels.)

          EDIT: Of course you could still miss out on an !Exp (unlikely as that may be), but at least you can just chug another one just after losing it.

          Comment

          • Derakon
            Prophet
            • Dec 2009
            • 9022

            The problem with that technique as a strategy for avoiding accidentally reading Deep Descent is that it can show up in stacks...

            I think that if Deep Descent doesn't show up prior to, say, 150', then we're generally fine; if you can survive 150' then you probably have enough ability to avoid being instantly splattered at 400', though I will grant that mages and priests would have a somewhat rough time of things. Going from 50' to 300' is a rather different story.

            Comment

            • AnonymousHero
              Veteran
              • Jun 2007
              • 1393

              Originally posted by Derakon
              The problem with that technique as a strategy for avoiding accidentally reading Deep Descent is that it can show up in stacks...

              I think that if Deep Descent doesn't show up prior to, say, 150', then we're generally fine; if you can survive 150' then you probably have enough ability to avoid being instantly splattered at 400', though I will grant that mages and priests would have a somewhat rough time of things. Going from 50' to 300' is a rather different story.
              Oh, right. I wasn't actually thinking about Deep Descent, but stuff like accidentally selling !Exp. My bad. Apologies, I'm a bit tipsy

              Comment

              • AnonymousHero
                Veteran
                • Jun 2007
                • 1393

                Sorry for the thread necromancy, but I thought some people who posted in here might find this interesting: ToME 2.x running on Qt 5.x.

                Just to clarify this is not quite UI/engine separation, but the engine is running in a thread separate from the GUI, which is something right?

                Comment

                • Nick
                  Vanilla maintainer
                  • Apr 2007
                  • 9634

                  Originally posted by AnonymousHero
                  Sorry for the thread necromancy, but I thought some people who posted in here might find this interesting: ToME 2.x running on Qt 5.x.

                  Just to clarify this is not quite UI/engine separation, but the engine is running in a thread separate from the GUI, which is something right?
                  OK, yes, this is very interesting. Thanks for posting!
                  One for the Dark Lord on his dark throne
                  In the Land of Mordor where the Shadows lie.

                  Comment

                  • Derakon
                    Prophet
                    • Dec 2009
                    • 9022

                    Congrats, that's excellent news.

                    How are you handling drawing? Are you drawing individual characters to specific positions on a canvas, or using some kind of text GUI widget? The speed problems most UI attempts run into are probably due to trying to draw 1920 (80*24) individual character glyphs every time things change. Pyrel was able to work around this problem by intelligently caching tile information so that the vast majority of tiles don't need to be redrawn each tick, but full-screen refreshes are still pretty slow.

                    Comment

                    • AnonymousHero
                      Veteran
                      • Jun 2007
                      • 1393

                      Originally posted by Derakon
                      Congrats, that's excellent news.

                      How are you handling drawing? Are you drawing individual characters to specific positions on a canvas, or using some kind of text GUI widget? The speed problems most UI attempts run into are probably due to trying to draw 1920 (80*24) individual character glyphs every time things change. Pyrel was able to work around this problem by intelligently caching tile information so that the vast majority of tiles don't need to be redrawn each tick, but full-screen refreshes are still pretty slow.
                      The great thing is that it's a really dumb implementation which seems to be performing quite well. The standard QGraphicsScene is (apparently) easily capable of handling thousands of little "items" (as they call them) in a scene(*), so I just create MxN QGraphicsSimpleTextItem-derived instances and (at the window-open event) position them appropriately for the MxN grid. That's all setup, so when I want to write something I just look up the "character" (QGraphicsSimpleTextItem) at the appropriate place and change its "text" and foreground color. After a whole line is "written"/cleared/whatever I just call "invalidate" on the QGraphicsScene on the portion I updated and it takes care of the rest!

                      Now, there is a caveat which I haven't mentioned and that is that I haven't yet tried the torture-test which is "center on player" and then go running around (mainly due to lack of arrow key handling ), but given that the current implementation is so unbelievably dumb, I'm not expecting much trouble there.

                      (*) Using all manner of interesting stuff like BSPs for optimizing exactly which items get redrawn on invalidation/re-paint.

                      Comment

                      • Derakon
                        Prophet
                        • Dec 2009
                        • 9022

                        Hunh, I wouldn't have expected that to be efficient. Interesting. Thanks for describing your approach, anyway. It's possible the Qt front-end for Pyrel would want to steal it.

                        Comment

                        • nppangband
                          NPPAngband Maintainer
                          • Dec 2008
                          • 926

                          Originally posted by AnonymousHero
                          The great thing is that it's a really dumb implementation which seems to be performing quite well. The standard QGraphicsScene is (apparently) easily capable of handling thousands of little "items" (as they call them) in a scene(*), so I just create MxN QGraphicsSimpleTextItem-derived instances and (at the window-open event) position them appropriately for the MxN grid. That's all setup, so when I want to write something I just look up the "character" (QGraphicsSimpleTextItem) at the appropriate place and change its "text" and foreground color. After a whole line is "written"/cleared/whatever I just call "invalidate" on the QGraphicsScene on the portion I updated and it takes care of the rest!

                          Now, there is a caveat which I haven't mentioned and that is that I haven't yet tried the torture-test which is "center on player" and then go running around (mainly due to lack of arrow key handling ), but given that the current implementation is so unbelievably dumb, I'm not expecting much trouble there.

                          (*) Using all manner of interesting stuff like BSPs for optimizing exactly which items get redrawn on invalidation/re-paint.
                          Hi Anonymoushero,

                          I was looking through the QT examples, and I found this:



                          It appears to be just moving around an "@" with direction keys, in a roguelike settings. This code will probably be pretty useful to me soon.

                          I should post my start to a QT port soon. I am focusing on developing a menubar and toolbars for the game. I haven't actually incorporated any angband code yet. My next step will be to get the port to load the edit files, and close them up on exit.
                          Last edited by nppangband; December 28, 2013, 05:49.
                          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

                            Originally posted by Derakon
                            Hunh, I wouldn't have expected that to be efficient. Interesting. Thanks for describing your approach, anyway. It's possible the Qt front-end for Pyrel would want to steal it.
                            I am finding QT to be quite well documented. I faced a little learning curve the first couple days, but now that I am getting used to it things are moving along nicely. Plus there are countless examples out there to learn from.

                            It is amazing that can be done with just a couple lines of code in QT that takes hundreds or thousands of lines in the Angband "game engine".
                            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

                            • Derakon
                              Prophet
                              • Dec 2009
                              • 9022

                              If you need them, Pyrel has fairly optimized drawing routines that aren't specific to any given front-end library here. This handles issues like:

                              * Deciding which subset of the map to display (centering on @ but taking map boundaries into account)
                              * Drawing text, including pairs of left/right-aligned items (e.g. for inventory display: item name on one side, weight on the other)
                              * Mapping from pixel space to the map grid

                              The qtPyrel subclass of that class has Qt-specific code for performing drawing operations. Note that window setup is handled by other files.

                              Comment

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