Floating buttons and more...

[Wonkyth]

let's say I had a room large enough that it had to be scrolled when played.
would it be possible to make buttons that did NOT scroll with the rest of the screen? If so, How?


another question:
I have a game mainly controlled by keyboard, how do you make it so that instead of using the arrow keys to toggle movement(like in trilbys notes), that you move while the key is pressed, but not while it's not?

and another:
if you made  tile based game, could you make it so that when you press, say, the "Right" arrow key, that you move one tile right, and then there is a delay between that and moving to next tile, even if you held it down?

hope all those questions made sense, because I'm not quite sure what I mean myself.
I'm just trying to foresee future problems in my first full-scale AGS project.

any help would be greatly appreciated.
ThankYou.

[Shane 'ProgZmax' Stevens]

If you mean that you want the gui objects to be static when the screen moves, it's pretty easy.  Since gui coordinates are SCREEN coordinates (ie, they range from 0-max dimensions of the game resolution) you can manually lock them in place by using the GetViewportX() and GetViewportY() functions, which use room coordinates.

Something like this should work:

Code: ags

gGUI.X=gGUI.X-GetViewportX();
gGUI.Y=gGUI.Y-GetViewportY();

Now, wherever the gui is on your scrolling background it will be locked there by the current viewport coordinates rather than by the screen.



For sustained movement, you will need to abandon the use of the Walk function, the reason being because NoBlock will keep repeating the first frame on additional calls (even when looping) and block is useless in this situation.  What you want to do is make your own variables to store the player's frame number, max frames (per walkcycle), x and y velocities, and timers that will place a delay between keypresses.  A common way of wrapping this all up would be in a structure, something like this:

Code: ags

//this would go in the .ash file

struct CHARMOVE_STRUCT
{
     int xv;  //how much to move the player by horizontally
     int yv;  //how much to move the player by vertically
     int curr_frame;  //the current frame of the movement animation
     int max_frames;  //maximum frame of the movement animation (this isn't mandatory but it's good in case you add \
                               //more frames later)
     int curr_delay;  //This delay between keypresses will allow you to fine-tune the animation speed
     int max_delay;

};

import CHARMOVE_STRUCT charmove;

//this would go in the .asc file

CHARMOVE_STRUCT charmove;
export charmove;

With the following you'd have charmove which will handle all the variables for manually moving the player around.  You would need to initialize some of these in Game_Start first, like the velocities and delays, and then it is a matter of making some IsKeyPressed() calls for each direction (taking into account collision).  One of the calls would look something like this:

Code: ags

  if(IsKeyPressed(375))  //if the left arrow was pressed
  {
       cEgo.Loop=1;  //change to the left animation loop

      if(GetWalkableAreaAt(cEgo.x-GetViewportX()-charmove.xv, cEgo.y-GetViewportY()))
      {
         //we can move because there's a walkable area here!
         
         cEgo.x-=charmove.xv;  //move the character left by xv

         if(charmove.curr_delay<=0) //check our animation counter
         {

             if(cEgo.Frame<charmove.max_frames) //check to make sure the frames are good
             {
                cEgo.Frame+=1;
 
              }
              else
              {
                   cEgo.Frame=1; //this could be zero if you leave out a standing frame, but this
                    //is more compatible with other ags functions
               }

               charmove.curr_delay=charmove.max_delay; //reset the animation counter

         }

       }
       else
       {
          cEgo.Frame=0;  //if there's no walkable area to the left of the player just make him
          //stand
       }
  }

Now all you need to do is place a check for the counter in repeatedly_execute that counts it down until it is zero and another if statement to check to see if none of the directional keys are pressed so it can set the frame to 0 so he reverts to a standing pose.  I don't recommend using this code verbatim since I haven't tested it (though the concept is identical to one I've used many times), but hopefully it gives you an idea of how to arrange your own movement with the keys.

[Wonkyth]

Thanks, ProgZmax!
hopefully that should be enough to at least get a working model.
thankyou again.