Mouse playability

[Magnate]

@Jeff: I hadn't realised that you'd done the same thing as Nick and updated to 3.1.2v2 - that was very unfortunate, in both cases. It was a time of tremendous momentum in the team (which we've now lost). I hope we can come up with some way of mapping or otherwise notifying people of what is intended to happen (without being able to commit to when, of course), so this can be avoided in future.

I wasn't aware of the change from returning -1 for failure to returning 0 - I can imagine that that was a huge headache.

I think we all want the same thing here, which is someone who's going to "own" the frontends (and ditto for the underlying util/z-* code) in the same way that other devs sort-of own other bits of the code (dungeon generation, item generation, stats, tests, traps etc. etc.). The usual issue is that this stuff is less attractive to 'own' than bits of the game, so there are fewer volunteers. The other perennial problem is that we haven't ever had anyone on the team who specalises in front-end stuff. I wonder if Blubaron could be persuaded to join ;-)

[nppangband]

@Jeff: I hadn't realised that you'd done the same thing as Nick and updated to 3.1.2v2 - that was very unfortunate, in both cases. It was a time of tremendous momentum in the team (which we've now lost). I hope we can come up with some way of mapping or otherwise notifying people of what is intended to happen (without being able to commit to when, of course), so this can be avoided in future.

Yep. Overall it was worth it for NPP because of the mosue support.
IIRC FA is current with 3.2. I think he started his update a couple months after me.

The usual issue is that this stuff is less attractive to 'own' than bits of the game, so there are fewer volunteers.

Not to mention the challenge of finding somebody who can work on all 7-8 ports.

I know it is getting about time for me to be considering getting current with the latest Vanilla code. The two features I most want are the UTF-8 capability/fonts to replace x-char, and the ability to use Shockbolt's tiles (filling in the gaps for NPP monsters/features/objects with the ones Buzzkill and I did for the NPP DVG set), and double-tile mode. I assume for that it is best for me to just try to get all of the main-xxx.c files for the various ports working with NPP. This will doubtless lead to changes in the "core" files (util.c, x-term, etc.. ). I also noticed that the files that handle mouse-driven menus have been significantly updated (ui.c, etc). I kind of don't want those, becuase I just spent several months improving the ui for virtually every menu in the game based on the menu handling code in 3.1.2v2.

So do you all plan major changes in the main-xxx files any time soon? Do you forsee any time in the future where these files will be relatively consistent for the near future? Or does anyone have any other suggestions for how to best get the UTF-8 and shockbolts tiles working in NPP?

As I start NPP 060, I think my first UI project will be to work on the left sidebar. I am going to make it so it scrolls all of the most recent changes rather than being a static display (allowing the user to customize how long the information stays onscreen). Any leftover space will display health and mana bars for the closest monsters, along with an abbreviated name. That should transfer fairly smoothly over to other variants and Vanilla.

[Magnate]

So do you all plan major changes in the main-xxx files any time soon? Do you forsee any time in the future where these files will be relatively consistent for the near future? Or does anyone have any other suggestions for how to best get the UTF-8 and shockbolts tiles working in NPP?

I'm not the best person to answer this, but here's what I know:

UTF-8 was a very invasive change. IIRC noz made about thirty commits, touching almost every file (pretty much all string handling). There are probably tricks you can use for global replace etc. but there are likely to be changes needed in NPP that weren't in V, especially if your message handling is different etc. If you PM noz here, he can probably give you a list of the basic functions you need to copy, and how to make use of them. Oh wait a sec - he wrote it up - see if this page helps.

On Shockbolt's tiles, my impression from previous discussions is that all current tile handling is supremely hackish, and the accommodation of Shockbolt's 64x64 tiles even more so. If I were involved I'd suggest rewriting graphics handling from scratch (see takkaria's ideas about z-canvas.c) - but this is pure theory as I can't really help. It's certainly possible to borrow the current Shockbolt support from 3.4-dev, but this might not serve you well in the long run.

[Nick]

Core/UI split

So here's a vague plan - I'd be interested to hear whether it (a) sounds feasible and (b) is in some sense a Core/UI split:

• Have a "game state" with values like (tentatively) NEED_COMMAND, NEED DIRECTION, NEED_TARGET, NEED_NOTHING, NEED_OBJECT, NEED_SCROLL
• Have a single function call from the game which asks for user input
• Have the UI then handle the business of getting appropriate information from the player based on the game state

So menus, buttons, keypresses, etc are all handled by the UI.

Please shoot holes in this.

[Derakon]

I suspect you need instead for the game to tell the UI "I need the player to select from these options" in various ways:

* Select an item from a list (e.g. wield/drop/quaff/etc.)
* Select a spell from a book (browse/cast spell)
* Select a target

Some commands should also be purely UI commands, like viewing the character sheet or looking about the map. Basically anything that doesn't change game state.

[Nick]

* Select an item from a list (e.g. wield/drop/quaff/etc.)

get_input(NEED_WEARABLE)/get_input(NEED_CARRIED_OR_WORN)/get_input(NEED_POTION)

* Select a spell from a book (browse/cast spell)

get_input(NEED_SPELL) (or maybe NEED_BOOK)

* Select a target

get_input(NEED_TARGET)

I'm starting to think maybe this works.

[Blue Baron]

I have checked this out and it is excellent. When Psi and I did a similar thing for FA, we avoided right-clicking to make playing on a WinCE device (where the equivalent was holding down the stylus) easier; that involved some messy workarounds, though, and I like your method better. I assume there will be some way of (effectively) getting two types of click for smartphones, etc.

For an android port (I might do a graphical one at some point in the indefinite future, possibly based on BreathesFire's (maybe future) OpenGL port), I was originally thinking about a button in a corner to apply a button 2 press at the point of the next press that is not on a button. My current thoughts are to use a short press for button 1 and a long press for button 2. on multi-touch devices it could be a two finger press for button 2. though button 2 is mostly used as ESC, and that could be taken care of by the phone's back key so long presses would only be needed for the main view. or perhaps not use the long press, so presses could be sent on press down, rather than press up, and use the back key to send esc, except on the main screen with no menu on screen, where it would setup the next press to be a button 2 press. Just some ideas

There are still places where you can't do mouse stuff (character dump to a file, for example), but that should be just a matter of making the appropriate buttons.

Did I miss anything else?

I almost completely agree here, but I hope it can be done at the level of ui-menu - so get_item would call the (Term->menu)(params). I already have get_item calling the menu code in FA - see here.

Using the menu system is definitely a better way than I did the mouse support in get_item and should replace the stuff I wrote in get_item.

However, if the override was in the menu system, it might be too generic? Would a port have enough information to show a backpack backdrop, perhaps with equipment character and floor backdrops, filled with the tiles of the items that pass the tester function? (This is part of what we are aiming for, I think?)

Snip stuff I furiously agree with. The only thing I would add is the ability to add custom buttons based on keymaps.

With something like the current buttons you could add a couple commands to the keymap menu to add/kill buttons for a key press.

For future GUI buttons, I think what you mean would be the buttons of a hotkey toolbar menu? If so then it would be up to the menu (actually main screen subwindow) to do something like either scan the keymaps for the hotkeys and get the object tiles to use or to accept a right click to setup something.

For SDL, could you change font/tile size while keeping the window boundaries fixed when you zoom? This would require the game to know the number of rows and columns had changed, but that ought to be possible.

There are some functions that can be skipped after setting the new sizes, so that is not the problem. The problem is that SDL apparently does not have a function to scale an image as it copies it to the screen. If you tried to copy a 32x32 tile to a 48x48 area of screen half of the 3 adjacent tiles would also be copied to the spot. Or if you tried to copy a 32x32 tile to a 16x16 area on screen, only a quarter of the tile would show. There is a function that could be modified to do this in main-sdl.c but it would be very slow to use for every tile drawn. Text is in the same situation.

The font and tile sheet could be rebuilt after every zoom step, the SDL port already does this when the tile multipliers change, but the performance will depend on how often the zoom step changes.

I need to change what I said about zooming in windows. I thought that there was a text drawing function that took a size as a parameter, but I was mistaken and cannot find one in the documentation. So like SDL the font would need to be recreated with every zoom step. So again the performance would depend on how often the zoom step changes. Tiles are still easy to modify the size of.

[AnonymousHero]

So here's a vague plan - I'd be interested to hear whether it (a) sounds feasible and (b) is in some sense a Core/UI split:

• Have a "game state" with values like (tentatively) NEED_COMMAND, NEED DIRECTION, NEED_TARGET, NEED_NOTHING, NEED_OBJECT, NEED_SCROLL
• Have a single function call from the game which asks for user input
• Have the UI then handle the business of getting appropriate information from the player based on the game state

So menus, buttons, keypresses, etc are all handled by the UI.

Please shoot holes in this.

This can work if the game "engine" is a separate thread/process which just receives messages (and blocks if none are available), but for that to work you'd need all game state to be entirely internal to the engine. (So the UI becomes a dumb canvas or gets a copy of all the information it needs.)

You'd also need for every "wait for input" command to handle the unexpected, and a "abort command" (ESC now)... but I think that's pretty doable.

[Blue Baron]

I wonder if Blubaron could be persuaded to join ;-)

umm that's not likely . I don't want to make any more commitments at the present time, and I prefer being able to respond as "merely" a code contributor, rather than as a dev team member.

On Shockbolt's tiles, my impression from previous discussions is that all current tile handling is supremely hackish, and the accommodation of Shockbolt's 64x64 tiles even more so.

Jeff: this is true, but if you still want to do it you can:
1. copy grafmode.c and .h,
2. use them to load graphics.txt (which has the rows to use with double high tiles)
3. modify the function that adjust the windows menu bar to use the information in graphics.txt.
4. you would want to copy Term_pict_alpha_win from main-win.c
5. modify Term_react_xtra_win to switch the term's pict hook to Term_pict_alpha_win when used with a tile set that uses alpha blending or double high tiles (since the only current tileset that uses either uses both), and back to Term_pict_win when neither is used. (Term_pict_win uses faster functions than Term_pict_alpha_win).

you probably also want to copy readpng.c and the new init_graphics function from main-win.c for the windows png support so you do not have to distribute a huge bmp file.

there are some other steps in there, like setting up global variables to hold the alphablending state, but that is the gist of it.

[Blue Baron]

get_input(NEED_WEARABLE)/get_input(NEED_CARRIED_OR_WORN)/get_input(NEED_POTION)

get_input(NEED_SPELL) (or maybe NEED_BOOK)

get_input(NEED_TARGET)

I'm starting to think maybe this works.

Maybe you can add a parameter for a pointer to a command and an argument number to assign the input to.

I still worry that this might still be too generic (not enough context for the ui to know how to ask for the information from the player). However, if you can see it working, it is definitely worth a try.

Edit: Ignore this last paragraph, the additional context could just be more NEED_ enumerations that include more context.

[takkaria]

get_input(NEED_WEARABLE)/get_input(NEED_CARRIED_OR_WORN)/get_input(NEED_POTION)

get_input(NEED_SPELL) (or maybe NEED_BOOK)

get_input(NEED_TARGET)

I'm starting to think maybe this works.

The game already does this pretty much, no? There's get_item() and get_target() etc. You just need to swap them out for a different version depending on the UI. (Make them function pointers!) This is already the case with get_file(), I think - you can override it to replace it with a port-specific save box.

The only problem I see with this system is that it will break the 'n' command (and macros would have to stay as sequences of keypresses). Any solutions to this would be welcomed - I don't think either of those are blockers, but they deserve some thought.

[takkaria]

I suspect you need instead for the game to tell the UI "I need the player to select from these options" in various ways:

* Select an item from a list (e.g. wield/drop/quaff/etc.)
* Select a spell from a book (browse/cast spell)
* Select a target

Some commands should also be purely UI commands, like viewing the character sheet or looking about the map. Basically anything that doesn't change game state.

This is pretty much what already happens.

[takkaria]

The game already does this pretty much, no? There's get_item() and get_target() etc. You just need to swap them out for a different version depending on the UI. (Make them function pointers!) This is already the case with get_file(), I think - you can override it to replace it with a port-specific save box.

The only problem I see with this system is that it will break the 'n' command (and macros would have to stay as sequences of keypresses). Any solutions to this would be welcomed - I don't think either of those are blockers, but they deserve some thought.

Ah, I don't think this is such a big deal anymore. At the moment, commands are defined in game-cmd as taking certain ordered arguments, like:

    { CMD_TUNNEL, "tunnel", { arg_DIRECTION }, do_cmd_tunnel, TRUE, 99 },

These arguments are then passed to do_cmd_tunnel() when it's run:

void do_cmd_tunnel(cmd_code code, cmd_arg args[])
{
    bool more = FALSE;

    int dir = args[0].direction;

    /* Get location */
    int y = p_ptr->py + ddy[dir];
    int x = p_ptr->px + ddx[dir];

The way this happens is:

1. player presses 'T'
2. UI pushes CMD_TUNNEL onto the game's command stack
3. UI notices that it needs an argument but doesn't happen and prompts the user
4. UI sets the first parameter of the command at the top of the stack to whatever the user said
5. UI returns flow to core
6. Core executes CMD_TUNNEL command with argument

When the command is repeated ('n'), the last command looked like (CMD_TUNNEL, left). This means it can repeat easily.

This is fine for verbs which have a fixed number of arguments but not otherwise, as I said above. What we could do is to move back to how we used to do things (as NPP probably does), where do_cmd_tunnel() takes no parameters but instead calls out to get_direction(). get_direction(), when successful, could then modify the command currently being executed (in this case, a tunneling command) to store the direction, in some kind of dictionary, like (CMD_TUNNEL, { direction = left }). If the command is repeated, then get_direction() can always check the current commend to see if it has a direction field and use it instead of calling out to the UI.

I hope that makes sense! In bullet points and code:

do_cmd_tunnel would look more like:

bool do_cmd_tunnel(void)
{
    bool more = FALSE;

    int dir = get_direction();
    if (!dir) return FALSE;

    /* Get location */
    int y = p_ptr->py + ddy[dir];
    int x = p_ptr->px + ddx[dir];

get_direction would look like:

bool get_aim_dir(int *dp)
{
    /* Global direction */
    int dir = 0;

    /* Initialize */
    (*dp) = 0;

    /* Hack -- auto-target if requested */
    if (OPT(use_old_target) && target_okay() && !dir) dir = 5;

    /* Check command */
    if (cmd_has_arg(TYPE_DIRECTION)) {
       dir = cmd_get_direction();
       return TRUE;
    } 

    ...

    /* Save direction */
    (*dp) = dir;
    cmd_set_direction(dir);

    return TRUE;
}

This would make macros really easy to specify, too; you could start writing them like:

tunnel(direction = left)

or even

cast(spell = "Magic Missile", target = closest)

really easily! Just some thoughts, I hope they make sense. This was the biggest roadblock for me in actually doing the core/ui split so i'm glad we've figured something workable out, I was worrying that it was impossible/highly inelegant!

[Nick]

This was the biggest roadblock for me in actually doing the core/ui split so i'm glad we've figured something workable out, I was worrying that it was impossible/highly inelegant!

All sorted, then