x11 major code cleanup

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • calris
    Adept
    • Mar 2016
    • 194

    #16
    What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

    - Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
    - Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
    - Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
    - Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
    - Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

    Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

    My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated

    Comment

    • Nick
      Vanilla maintainer
      • Apr 2007
      • 9634

      #17
      Originally posted by calris
      What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

      - Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
      - Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
      - Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
      - Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
      - Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

      Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

      My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated
      I really like this idea, but I think I need some time for it to sink in so I can understand how the code would need to change.
      One for the Dark Lord on his dark throne
      In the Land of Mordor where the Shadows lie.

      Comment

      • calris
        Adept
        • Mar 2016
        • 194

        #18
        Originally posted by Nick
        I really like this idea, but I think I need some time for it to sink in so I can understand how the code would need to change.
        PWMAngband already does something along these lines I believe - See for example this screenshot

        Comment

        • takkaria
          Veteran
          • Apr 2007
          • 1951

          #19
          Originally posted by calris
          What we really need to do is to separate the 'cave' grid from the 'term' grid, thus allowing the size of the cave grids to be independent of the term grids. But we also need to account for drawing menus using text. My thought is fairly simple:

          - Have the main term windows (i.e. angband_term[0]) grid be sized to the font - this is used for all text operations including menus
          - Define a new term windows (struct term cave_term) which all attr/char for the cave are draw into
          - Have angband tell the front end where the 'cave term' gets mapped relative to the main term - for example, an 80x25 main window and a cave term mapped from (10,1) to (79, 23) give one row of text at the top, one row of text at the bottom, and 9 columns of text on the left.
          - Have the front end use Term_resize() to specify the size (in text grids) of the angband_term[0] term (and other terms)
          - Add a new cave_term_resize() function to specify the size of the cave view in graphical tile sizes (or text sizes if we are in text mode)

          Now, the front-end simply renders the cave term first, then the main term over the top - so menus will appear over the main cave. I think the front end changes will be fairly minimal.

          My big problem is, figuring out how the cave drawing code fits in - I'm trying to figure out how to make the cave draw to a term other than angband_term[0] - any help would be appreciated
          Yup this is defintely the right way to go, I think. I spent a while fiddling with this a while ago too and these are some of the things I thought made sense; take them or leave them as you wish.

          1. screen_load()/screen_save() need changing. As well as the terminal package keeping track of the different saved screens, with graphics done separately you need frontends to have their own 'save' / 'load' hooks which save/re-load the actual graphic image displayed on the screen.

          2. to avoid reimplementing logic across frontends you need some kind of graphics compositor that does all the work and just gives frontends a few hooks: save/load currently displayed image, some way of telling it what the font dimensions are and what size the window is, and obviously a tile plotting hook (which plots a given tile at a given pixel location, rather than grid location).

          3. I also think there's scope here for stopping using the ugly system where we encode graphic tiles for the term package as attr/chars by turning on the highest bit. Instead we could just have a plotting function which takes row/col in the bitmap.

          4. We need support for transparent backgrounds in the terminal package

          In answer to your question, map drawing for the main terminal is set up/torn down in ui_enter_world() and ui_leave_world() in ui-display.c, and hooks into the EVENT_MAP event type. The hook is ui-display.c:update_maps(), which either redraws the whole map (see ui-map.c: prt_map()), or if a particular point is to be redrawn (specified in the event data), redraws just that point. The same hook is also used to display the map subwindows. HTH.

          (PS I wrote something quite similar to what you're proposing a few years ago but I think I probably architecture astronauted it out of existence. Linking to it because you might find it useful, but feel free to ignore! http://trac.rephial.org/wiki/NextUi)
          Last edited by takkaria; May 8, 2016, 17:42.
          takkaria whispers something about options. -more-

          Comment

          • calris
            Adept
            • Mar 2016
            • 194

            #20
            What is really going to start messing things up is this global Term variable. I purged the x11 frontend of all it's 'activate window/colour/font' rubbish, and I think it's about time the main UI got the same treatment. But for now, I'm hacking around it.

            Comment

            • calris
              Adept
              • Mar 2016
              • 194

              #21
              I've pushed some more onto my repo - it's as ugly as ugly can get, and it only 'kind of' works (i.e. it doesn't crash)

              Text displays nicely, the virtual cave term does get some (rather random) rendering. Text mode is completely borked - not sure what I did there.

              I think it's a pretty solid start, but I also think it's going to need eyes and fingers from people who are more intimately familiar with the term code

              Comment

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