Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old March 29, 2012, 05:46   #51
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,775
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by Derakon View Post
* 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)
Quote:
* Select a spell from a book (browse/cast spell)
get_input(NEED_SPELL) (or maybe NEED_BOOK)
Quote:
* Select a target
get_input(NEED_TARGET)

I'm starting to think maybe this works.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old March 29, 2012, 06:12   #52
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by Nick View Post
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

Quote:
Originally Posted by Nick View Post
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?

Quote:
Originally Posted by Nick View Post
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?)

Quote:
Originally Posted by Nick View Post
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.

Quote:
Originally Posted by Nick View Post
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.
Blue Baron is offline   Reply With Quote
Old March 29, 2012, 06:12   #53
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,367
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Nick View Post
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.
AnonymousHero is offline   Reply With Quote
Old March 29, 2012, 06:45   #54
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by Magnate View Post
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.

Quote:
Originally Posted by Magnate View Post
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 is offline   Reply With Quote
Old March 29, 2012, 06:58   #55
Blue Baron
Adept
 
Join Date: Apr 2011
Posts: 103
Blue Baron is on a distinguished road
Quote:
Originally Posted by Nick View Post
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.

Last edited by Blue Baron; March 29, 2012 at 07:05.
Blue Baron is offline   Reply With Quote
Old March 29, 2012, 18:57   #56
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,932
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by Nick View Post
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 whispers something about options. -more-
takkaria is offline   Reply With Quote
Old March 29, 2012, 18:59   #57
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,932
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by Derakon View Post
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 whispers something about options. -more-
takkaria is offline   Reply With Quote
Old March 29, 2012, 23:45   #58
takkaria
Veteran
 
takkaria's Avatar
 
Join Date: Apr 2007
Posts: 1,932
Donated: $40
takkaria is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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:

Code:
    { CMD_TUNNEL, "tunnel", { arg_DIRECTION }, do_cmd_tunnel, TRUE, 99 },
These arguments are then passed to do_cmd_tunnel() when it's run:

Code:
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:

Code:
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:

Code:
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:

Code:
tunnel(direction = left)
or even

Code:
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!
__________________
takkaria whispers something about options. -more-
takkaria is offline   Reply With Quote
Old March 30, 2012, 13:57   #59
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 54
Posts: 7,775
Donated: $60
Nick is on a distinguished road
Quote:
Originally Posted by takkaria View Post
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
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Mouse Suppotr Notes Blue Baron Development 3 December 11, 2011 07:51
Mouse movement change request Speusippus Vanilla 1 March 1, 2010 19:53
Disable mouse move Whelk Variants 3 August 11, 2009 04:27
[FA] WinCE port + Mouse buttons screenshots Psi Variants 6 March 4, 2008 08:16
Mouse buttons Nick Vanilla 4 October 20, 2007 23:22


All times are GMT +1. The time now is 04:21.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.