Angband color rooms

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • t4nk
    Swordsman
    • May 2016
    • 336

    Angband color rooms

    Too much C for main forum! I think it belongs here.

    Originally posted by droof
    I tried changing the room templates from level 5 to 1 in dungeon_profile.txt, but that change also doesn't trigger the function. So to test this, I need to dive to level 5 and use words of recall?
    Yes, they start on level 5 (this is actually in dungeon_profile.txt, see "room:room template:" lines).
    Of course, you shoudn't use words of recall Press Ctrl-A, that enables debug commands. Some useful commands: 'A' - get max experience (so your @ becomes level 50); 'j' - jump to some level, 'w' - reveal whole level (like with scroll of magic map).

    From what little I understand from the code, each terrain type has a terrain index from terrain.txt and a color index from z-color. Terrain bits from build_room_template() are set through square_set_feat(). This sets the appropriate terrain feature to a chunk / cave x y coordinate.
    Right (except it's y, x coordinate instead of x, y! good source of bugs ) So you'll need to implement square_set_color(), which should be similar to square_set_feat(), but for colors.

    And this information somehow ends up in grid_data_as_text() where the color of the feature type is displayed.
    When the core wants to update something on the map, it calls square_light_spot(); that tells the ui that a grid shoud be redrawn. The ui then calls map_info(), that fills struct grid_data with all information that a player is allowed to know. grid_data_as_text() then translates grid_data to text (or to tiles).

    To color room templates, maybe I can pass along the color_map color with the feature index in build_room_template() and store both at the cave square coordinate. Is this what you meant with the additional attribute for cave.h:132, t4nk?
    So struct square (in cave.h) looks like this:
    Code:
    struct square {
    	byte feat;
    	bitflag *info;
    	byte noise;
    	byte scent;
    	s16b mon;
    	struct object *obj;
    	struct trap *trap;
    };
    I suggest to add another field to it:
    Code:
    struct square {
        byte feat;
        byte color;
       /* and all other stuff... */
    And initialize color field much like how feat is initialized (functions in cave-square.c). Roughly:
    Code:
    void square_set_color(struct chunk *c, int y, int x, byte color)
    {
        assert(square_in_bounds(c, y, x));
        c->squares[y][x].color = color;
    }
    Then just call square_set_color() when appropriate in room builder.

    But grid_data_as_text() doesn't have current square coordinates or the cave object to look up and overrule the feature color for display.
    See ui-map.c:
    Code:
        /* Determine what is there */
        map_info(y, x, &g);
        grid_data_as_text(&g, &a, &c, &ta, &tc);
        Term_queue_char(t, vx, vy, a, c, ta, tc);
    The Term stuff then passes characters and their colors to a frontend, e.g., to ncurses client.
  • droof
    Apprentice
    • Dec 2013
    • 71

    #2
    Thank you, t4nk. I have optional color maps for room_template.txt working with custom colors.

    GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.


    I left the custom colors and color maps out of the commit, since that's a work in progress.

    I used int instead of byte for the color, because grid_data_as_text() also uses "int a" for the color value. I initialize the color as -1. If the color remains -1, then use the feature color. I'm sure the added code could be improved, but at least it is working, stable and no compiler complaints.

    Now I can experiment with color palettes

    Comment

    • t4nk
      Swordsman
      • May 2016
      • 336

      #3
      That looks good! If you have any additional questions, feel free to ask.

      Originally posted by droof
      I used int instead of byte for the color, because grid_data_as_text() also uses "int a" for the color value.
      Well, it doesn't really matter, because of what C calls 'default argument promotions'... or is it 'usual arithmetic conversions'? Something like that Anyway, this stuff only makes any sense if you know assembler, so don't care about it. Int is fine.

      I'm sure the added code could be improved, but at least it is working, stable and no compiler complaints.
      The new colors won' persist through saving/loading (I'd expect all new colors to become black *), so if you want it, take a look at wr_dungeon_aux()/rd_dungeon_aux() (save.c and load.c, respectively). There are some general explanations in savefile.c.
      Also, tiles are ruined now If you want them to work, you can move color assignement into grid_get_attr(), since that one is called only when tiles are not used.

      *edit: come to think of it, they should turn into white again? I haven't actually tested it yet
      Last edited by t4nk; December 10, 2016, 04:03.

      Comment

      • droof
        Apprentice
        • Dec 2013
        • 71

        #4
        Oops! Thank you for testing, I did not test with tiles

        I'll fix it like you said and look into saving and loading tomorrow. This idea is definitely going somewhere thanks to you and Nomad. I hope the color idea will work well in practice and convince some people

        Comment

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