I really tried tweaking this one, but I need your help. I was trying to figure out a way to make the player's sprite move less as you held down the keys. Specifically it was to try to make the sprite move only a certain amount when you held down a key, but stop until you released it and pressed it again, instead of doing it continuously as you held down the key (this would be for stuff like moving a character like on a grid, the way some old school CRPGs did).
I couldn't find a way to make it work. This is the code so far, that didn't accidentally stop the sprite from moving at all, or in two directions only (at least I figured out that THEN limits results from an IF statement to one, so I need ENDIF for more).
SETCURRENTDIR("Media") // go to media files
SETTRANSPARENCY RGB (244, 124, 0)
LIMITFPS 60
LOADSPRITE "whatever.bmp", 5 //any picture will do; the code here works with a 32x32 one
GLOBAL shield% = 5
GLOBAL spritex = 128
GLOBAL spritey = 128
GLOBAL spritespeed = 1
GLOBAL KeyHit = 0
WHILE KEY (01) = FALSE
MovePlayer()
DrawScreen()
WEND
FUNCTION MovePlayer:
LOCAL dirx, diry
IF KeyHit = 0
IF KEY (17)
diry = -1
KeyHit = 1
ENDIF
ELSE
diry = 0
KeyHit = 0
ENDIF
IF KeyHit = 0
IF KEY (30)
dirx = -1
KeyHit = 1
ENDIF
ELSE
dirx = 0
KeyHit = 0
ENDIF
IF KeyHit = 0
IF KEY (31)
diry = 1
KeyHit = 1
ENDIF
ELSE
diry = 0
KeyHit = 0
ENDIF
IF KeyHit = 0
IF KEY (32)
dirx = 1
KeyHit = 1
ENDIF
ELSE
dirx = 0
KeyHit = 0
ENDIF
spritex = spritex + (spritespeed * dirx)
spritey = spritey + (spritespeed * diry)
IF KEY (57) THEN spritespeed=3
IF NOT KEY (57) THEN spritespeed=1
IF spritex < 0 THEN spritex = 0
IF spritex > 608 THEN spritex = 608
IF spritey < 0 THEN spritey = 0
IF spritey > 448 THEN spritey = 448
ENDFUNCTION
FUNCTION DrawScreen:
DRAWSPRITE shield, spritex, spritey
SHOWSCREEN
ENDFUNCTION
Here's my thoughts: (pseudocode)
WHILE 1
IF KEY(up) = TRUE AND keypressed = 0
keypressed = 1
ENDIF
IF keypressed = 1
move_sprite(x_amount)
keypressed = 2
ENDIF
IF keypressed = 2 AND KEY(up) = FALSE
keypressed = 0
ENDIF
WEND
Of course now the sprite moves in one big move, but you could change that with a boolean and a function with a timer or something. :P
Put up one for each direction, and adjusted the variables accordingly, but although it compiled and ran, it freezes each time I run it.
EDIT: And just to be sure, I reverted back to the code I posted, and it ran fine.
Summary: Your goal is when the player hits the 'move left' key (for example), you want the player object to move 'x' number of pixels to the left, depending on the grid size? And, if the key is still down, don't repeat the command. To repeat the move, the player must first release the key, and repress it?
For the movement requirement, I would implement an easing / tweening function to smoothly move your player from point a to point b over a set time period. Check these two posts for two tweening libraries done for GLBasic:
http://www.glbasic.com/forum/index.php?topic=5643.msg44318#msg44318 (http://www.glbasic.com/forum/index.php?topic=5643.msg44318#msg44318)
http://www.glbasic.com/forum/index.php?topic=5892.msg46443#msg46443 (http://www.glbasic.com/forum/index.php?topic=5892.msg46443#msg46443)
Of course I recommend the first one. :P
With a tweening library, you don't have to move an object at a linear speed, but can use an ease in and ease out style so it slowly starts moving, gets to max speed, the gradually slows to its final resting location. Much more polished.
Here's a stab at your requirements. I use a lot of static variables, but shouldn't be a problem.
Ideally you want to add custom TYPES for a 2D vector, plus to handle tween calls automatically (or more automatic).
I have another TYPE library to handle my tweens if anybody wants to see it, it handles decrementing the timer for you, etc.
THIS HASN'T BEEN TESTED! I just created this on the spot.
CONSTANT GridSizeX% = 32
CONSTANT GridSizeY% = 32
CONSTANT Key_MoveLeft% = 30 // Or whatever
CONSTANT Key_MoveRight% = 31 // Or whatever
CONSTANT MoveSpeed% = 1000 // A Player movement animation lasts this number of ms
CONSTANT MoveTweenStyle% = TWEEN_TRANSITION_QUAD_INOUT
(or 'CONSTANT MoveTweenStyle% = 7' if GLBasic doesn't allow a constant set to another constant - this was an issue a year ago)
FUNCTION PlayerMove:
STATIC previousKey% = 0 // Remember previous key press between calls
STATIC isMoving% = FALSE // Is player currently in a move animation?
STATIC playerPos_DestX% = 0 // Player's destination 'x' location after the move
STATIC playerPos_DestY% = 0 // Player's destination 'y' location after the move
STATIC playerPos_StartX% = 0 // Player's starting 'x' location before the move
STATIC playerPos_StartY% = 0 // Player's starting 'y' location before the move
STATIC moveTimer# = 0 // Move animation timer (as a float for division calculations)
// Are we currenly in a move animation? Then update position based on tween settings
IF isMoving
DEC moveTimer, GETTIMER() // Reduce the animation timer by how many ms have elapsed since last frame
IF moveTimer < 0
isMoving = FALSE
playerPositionX = playerPos_DestX
playerPositionY = playerPos_DestY
ELSE
playerPositionX = Tween_Get(MoveTweenStyle, playerPos_StartX, playerPos_DestX, (moveTimer / MoveSpeed))
playerPositionY = Tween_Get(MoveTweenStyle, playerPos_StartY, playerPos_DestY, (moveTimer / MoveSpeed))
ENDIF
ENDIF
// Check if 'Move Left' key is pressed
IF KEY(Key_MoveLeft%)
// User must NOT be already moving, and must lift key and repress to repeat a movement
IF (NOT isMoving) AND (previousKey <> Key_MoveLeft%)
playerPos_StartX = playerPositionX // Set to your current player's x position
playerPos_DestX = playerPositionX - GridSizeX // We want to move the player 'GridSizeX' pixels to the left
playerPos_StartY = playerPositionY // Not need for the move, but needed later in the 'isMoving' function
playerPos_DestY = playerPositionY // Since only moving in the 'x' direction, Y stays the same
isMoving = TRUE
moveTimer = MoveSpeed
ENDIF
previousKey = Key_MoveLeft%
// Check if 'Move Right' key is pressed
ELSEIF KEY(Key_MoveRight%)
... copy from above and adjust ...
previousKey = Key_MoveRight%
// No keys hit this frame
ELSE
previousKey = 0
ENDIF
ENDFUNCTION
[EDIT] Moved the 'isMoving' code to above the key checks. I had it inside the checks - oops! I had to then update both x and y locations in the global 'isMoving' check since we don't know which direction we're moving. (We could have use two checks, 'isMovingX' and 'isMovingY' I suppose!) I hate the code listing tabs defaulting to 8 spaces! My text editor is set to 4 spaces! Now my code looks sloppy! ha
[EDIT2] I'm not too confident the 'previousKey' logic is sound. If you lift your finger during a move and rehit the same key again, the logic won't know you had released it. I would remove the previous key logic completely maybe, and allow the user to hold the left key down, and move it one unit each second (as in the sample code).
To your second edit, is there a way for GLBasic to know if a key is held down and then released? It would not only help this, but stuff like holding down the button to charge an attack (like the main laser in R-Type).
No in GLBasic you can only check if a key is pressed at the moment. But you can easily write your own routine to know when it gets released.
Quote from: kanonet on 2012-Dec-04
No in GLBasic you can only check if a key is pressed at the moment. But you can easily write your own routine to know when it gets released.
Well I guess that will be an advanced thing for later, but would it involve linking another language?
As i said, its really easy to do it on your own:
// needs to get called often, lets say every loop...
LOCAL space_old%
IF KEY(57)
space_old = 1
// key is pressed atm
// do what ever you want to do when space is pressed down
ELSE
IF space_old
space_old = 0
// key just got released
// just do here what ever you want, when space gets released
ENDIF
ENDIF
You also find pressed/ down/ released events in my key def. 8)
Quote from: kanonet on 2012-Dec-05
As i said, its really easy to do it on your own:
// needs to get called often, lets say every loop...
LOCAL space_old%
IF KEY(57)
space_old = 1
// key is pressed atm
// do what ever you want to do when space is pressed down
ELSE
IF space_old
space_old = 0
// key just got released
// just do here what ever you want, when space gets released
ENDIF
ENDIF
You also find pressed/ down/ released events in my key def. 8)
How would I incorporate that into the code in the first post? I tried doing it, just modifying the IF statements, but it didn't work.
Can we see some code?
Quote from: Moru on 2012-Dec-05
Can we see some code?
I wrote "in the first post". That means the first post on this thread.
I don't see any edits on that post. I want to see exactly what isn't working and what you tried to do. Preferably with full explanations of what you expect to happen and error messages and what happened instead. Doesn't have to be an essay, just a few lines with the code in code brackets (just like in your first post)
I just noticed an interesting thing in your 1st post that needs to get addressed:
You did write KEY(01) to access the escape key. Please keep in mind, that you need to input a decimal number into the KEY() function and "01" is expression of an octal number. The compiler automatically translates it into a decimal number and since octal "01" = decimal "1" everything works as expected. But if you keep this behaviour you may run into trouble on later projects, lets say you want to access the key with the number 8: if you write KEY(8) everything works fine, but if you write KEY(08) you get a compiler error, since the leading "0" tells the compiler this is a octal numer, but there is no octal number that contains an "8" or "9" (octals only use the digests 0-7, in c and glb they always have a leading 0 so the compiler knows that you want to use octals). So do not add a leading 0 as long as you dont want to use octal numbers!
Quote from: Moru on 2012-Dec-05
I don't see any edits on that post.(1) I want to see exactly what isn't working and what you tried to do.(2) Preferably with full explanations of what you expect to happen(3) and error messages(4) and what happened instead. Doesn't have to be an essay, just a few lines with the code in code brackets (just like in your first post)
1. Why should there be edits in the first post? The code was there from the beginning.
2. Well I did give some of the problems in the first post, the other problem is the other methods don't seem to slow down the movement at all.
3. I did state what I expected to happen in the first paragraph on this thread. Even if it wasn't a format you were used to, that doesn't mean I didn't state the problem.
4. I already fixed the problems that caused errors.
Quote from: Lord_TNK on 2012-Dec-05
Quote from: kanonet on 2012-Dec-05
As i said, its really easy to do it on your own:
// needs to get called often, lets say every loop...
LOCAL space_old%
IF KEY(57)
space_old = 1
// key is pressed atm
// do what ever you want to do when space is pressed down
ELSE
IF space_old
space_old = 0
// key just got released
// just do here what ever you want, when space gets released
ENDIF
ENDIF
You also find pressed/ down/ released events in my key def. 8)
How would I incorporate that into the code in the first post? I tried doing it, just modifying the IF statements, but it didn't work.
This part suggest you tried some change to the code and it didn't work. Ok. I'm not sure what code I'm supposed to look at. Is it still the top code even after all the suggestions in this thread? I'm confused after 10 minutes of staring at this but I guess it's because it's late.
If you want to slow down something, you need to change the speed of this object. For example if your objects speed is +1, you need to make it +(1*0.95) for each update until it gets close to 0. Then you stop adding anything at all to avoid rounding-errors in floating point numbers. This is something similar to what those tweening-libraries would do I imagine. Just easier to adjust the exact curve of the slowdown.
I know about changing the speed. I did include a dash button in the program (where it mentions KEY (57) in the code). The point was to have the sprite move a certain amount per press, sort of how Mario moves on the overworld maps in Super Mario Bros 3, and other games.
But I forgot about the showcase page on the main site. I'll see if I can find a game that did that, and look in its code. I will then report my findings if I come across how to do it.
Ah, misunderstood your "held down" as in speed going down while holding down the key. If you want it to slow down after release, you need to keep a counter or timer that starts after release of key. When the counter reaches 0, you disable the release variable again and stop moving.
One help for the release-event is here:
http://www.glbasic.com/forum/index.php?topic=679.0
It also has named keys, just like you wanted (sort of) :-)
I would avoid using a keyboard control system and instead either use mouse or joystick. This would avoid previously mentioned problems!
Not everything can be played only with mouse or controller. Besides, this can be easily adapted to use the same press/hold/release codes for joystick and mouse.
And the mouse is killing my shoulder and wrist... :-)
I plan on allowing custom buttons for the players in my games, so the codes need to work with keyboards as well as mice and gamepads.
Also, that code you linked to, Moru, looks like it could work. I'll see if I can incorporate that.
What somebody needs to do is create a generic 'Input()' TYPE that handles all the low level details for you, and allows you to query the input with input device type independency.
It would be great also for allowing the player to customize his input keys / buttons.
For example, the new TYPE would allow code such as the following:
// Register input codes and events - Call before starting level
Input.Clear() // Clear any previous event entries
Input.AddKey("FIRE", 62) // Register key code '62' to trigger a 'fire' event
Input.AddMouseButton("FIRE", 0) // Register mouse button '0' to also trigger a 'fire' event
Input.AddMouseAxis("ROTATE", 0) // Register mouse axis '0' to control the 'rotation'
// In your main level game loop . . .
Input.Update() // This may be needed at the beginning of the game loop to set up the input states, unless you code it otherwise
IF Input.Event("FIRE") THEN . . . // Has the user triggered a 'fire' event? (by either clicking key 62 *or* mouse button '0')
playerRotation = Input.GetAxis("ROTATE") // Set the variable to the current 'ROTATE' axis value
[Edit] You could replace the event strings (ie: "FIRE") with event integer constants, if string code speed concerns you:
CONSTANT InputFire% = 1
Input.AddKey(InputFire, 62) // Register key code '62' to trigger a 'fire' event
IF Input.Event(InputFire) THEN . . . // Has the user triggered a fire event?
Slydog this is exactly what Gernots keydef and my improved version does.
@kanonet
Ha, good thing I didn't go ahead and do this myself then! :P
I've never heard of 'keydef' before (I don't think). It isn't a GLBasic keyword.
I suppose it would be great to extend this idea to include key states somehow:
IF Input.Event("FIRE") . . . // The event has started and finished (ie, key has been pressed down AND released this frame)
IF Input.EventOn("FIRE") . . . // Called when the user starts the event (ie. key is currently being pressed but not released)
Is this what you are referring to?:
http://www.glbasic.com/forum/index.php?topic=8759.msg74517#msg74517 (http://www.glbasic.com/forum/index.php?topic=8759.msg74517#msg74517)
So what it does is allow you to store your desired input keys for certain events into an .ini file, and reread them when needed?
That is close to what I outlined, but with fewer options. (ie: no mouse integration, events with multi keys / button definitions, axises, etc). Should be good for most people though. Just not my 'dream' input class! ha
In my Input class (ha, ok, TYPE) I have these predefined key settings:
CONSTANT KEY_MINUS = 12
CONSTANT KEY_PLUS = 13
CONSTANT KEY_TAB = 15
CONSTANT KEY_CAPSLOCK = 17
CONSTANT KEY_ENTER = 28
CONSTANT KEY_SPACE = 57
CONSTANT KEY_COMMA = 51
CONSTANT KEY_PERIOD = 52
CONSTANT KEY_UP = 200
CONSTANT KEY_DOWN = 208
CONSTANT KEY_LEFT = 203
CONSTANT KEY_RIGHT = 205
CONSTANT KEY_PAGEUP = 209
CONSTANT KEY_PAGEDOWN = 201
CONSTANT KEY_INSERT = 210
CONSTANT KEY_DELETE = 211
CONSTANT KEY_HOME = 199
CONSTANT KEY_END = 207
CONSTANT KEY_SHIFT_L = 42
CONSTANT KEY_SHIFT_R = 54
CONSTANT KEY_CONTROL_L = 31
CONSTANT MOUSE_AXIS_X% = 0
CONSTANT MOUSE_AXIS_Y% = 1
CONSTANT MOUSE_WHEEL% = 2
CONSTANT MOUSE_BUTTON_1% = 3
CONSTANT MOUSE_BUTTON_2% = 4
CONSTANT MOUSE_BUTTON_3% = 5
But according to Moru's post on page 3 of that thread, these may not always be accurate, depending on which keyboard type you have? Hmm, but it may be a good starting point . . . or have them stored into a few ini files, and detect which keyboard you have, and load the appropriate keyboard.ini file? ha, no idea if that is even possible, or desired.
Slydog, Gernots keydef is in sampes/common/keydef (also see samples/_projects_/keydefmenu).
My improved version is here: http://www.glbasic.com/forum/index.php?topic=5695.
I dont want to push someone, its just cause you asked. :D
Wow, pretty much exactly what I was proposing! :enc:
I like your method of having each 'event' it's own instance of the TYPE, so code reads better:
IF attack.DOWN() THEN DOSOMETHING()
Plus of course your automatic setting of the key/mouse in the while look example - very cool!
If you wanted to extend (ha, I didn't look at your code, it may already have this) your TYPE, you could add methods to detect 'Down', 'Up', 'Press' (Up then Down) or whatever.
It already has 4 states:
-not pressed
-hit/ just pressed down
-pressed/ holding down
-released
Just read key.state if you need this information.
Ah, there it was. I searched through the first 14 pages of code snippets yesterday since the search would not find it. Thanks :)
Should really sort up those in more categories or it's own site entirely.
There has been a few attempts at a wiki but it's hard to get it accepted and used.
Yes, unfortunately - it's a shame
Quote from: Moru on 2012-Dec-06
Ah, misunderstood your "held down" as in speed going down while holding down the key. If you want it to slow down after release, you need to keep a counter or timer that starts after release of key. When the counter reaches 0, you disable the release variable again and stop moving.
One help for the release-event is here:
http://www.glbasic.com/forum/index.php?topic=679.0
The problem is the sample code shows errors when I try to compile. I'd bring that up on the thread, but it's an old one.
Quote from: kanonet on 2012-Dec-06
Slydog, Gernots keydef is in sampes/common/keydef (also see samples/_projects_/keydefmenu).
My improved version is here: http://www.glbasic.com/forum/index.php?topic=5695.
I dont want to push someone, its just cause you asked. :D
How would I incorporate that into my program? Here's an updated source code, by the way.
SETCURRENTDIR("Media") // go to media files
SETTRANSPARENCY RGB (244, 124, 0) // I used that color because it's not a multiple of 8, and that's how I like to use the colors in the stuff I make.
SETSCREEN 640, 480, 0
LIMITFPS 60
LOADSPRITE "tnk shield.png", 5 //Any sprite will do, but it's best if it's 32x32.
GLOBAL shield% = 5
//Starting positions for the sprite. Some programs call these "px and py, but I prefer something more descriptive.
GLOBAL spritex = 288
GLOBAL spritey = 208
GLOBAL spritespeed = 1
WHILE KEY (1) = FALSE
MovePlayer()
DrawScreen()
WEND
FUNCTION MovePlayer:
LOCAL dirx, diry
//Maps movement to the WASD keys. Adjustable of course.
IF KEY (17)
INC diry, -1
ENDIF
IF KEY (30)
INC dirx, -1
ENDIF
IF KEY (31)
INC diry, 1
ENDIF
IF KEY (32)
INC dirx, 1
ENDIF
//So it knows to update the position of the sprite.
spritex = spritex + (spritespeed * dirx)
spritey = spritey + (spritespeed * diry)
//Makes this essentially a dash button. Second line is so it knows to go to normal speed when not held.
IF KEY (57) THEN spritespeed=3
IF NOT KEY (57) THEN spritespeed=1
//Halts sprite when at edges of screen.
IF spritex < 0 THEN spritex = 0
IF spritex > 608 THEN spritex = 608
IF spritey < 0 THEN spritey = 0
IF spritey > 448 THEN spritey = 448
ENDFUNCTION
FUNCTION DrawScreen:
DRAWSPRITE shield, spritex, spritey
SHOWSCREEN
ENDFUNCTION
Short answer:
lets say your code looks like this:
// inside main loop:
IF KEY(32) THEN INC dirx
Then you would replace it with this:
// on game start, before the main loop
LOCAL backward AS Tkey
backward.SET(32)
// inside your main loop:
IF backward.DOWN() THEN INC dirx
Quote from: kanonet on 2012-Dec-09
Short answer:
lets say your code looks like this:
// inside main loop:
IF KEY(32) THEN INC dirx
Then you would replace it with this:
// on game start, before the main loop
LOCAL backward AS Tkey
backward.SET(32)
// inside your main loop:
IF backward.DOWN() THEN INC dirx
Would that be all, or would I need to do more?
I just tried so many things, and nothing seems to have any effect on the constant movement of the sprite (as in any way to pause or halt it, not the speed).
This is just to show you how you replace one key with my routine, wasnt that your question? Of cause you would need to do more for the other keys.
And your changing of the movement speed is independent from this, can be done with it and without, just in the way you like it. Did you have a look at this one?: http://www.glbasic.com/forum/index.php?topic=5297.msg41251#msg41251
Quote from: kanonet on 2012-Dec-09
This is just to show you how you replace one key with my routine, wasnt that your question? Of cause you would need to do more for the other keys.
And your changing of the movement speed is independent from this, can be done with it and without, just in the way you like it. Did you have a look at this one?: http://www.glbasic.com/forum/index.php?topic=5297.msg41251#msg41251
1. What I meant was if I could just use that code for each key and then just run it, or if I needed to put any more codes in there.
2. I wrote "not movement speed". I had already figured that one out. I did point out a dash button in the code after all. I meant halting the movement, even temporarily.
1. Its the code thats needed for one key. If you want to replace multiple keys, you need to do this for each key.
2. Im not sure if I understand what you mean, but if you want to stop movement, just set spritespeed to 0 or set dirx and diry to 0.
Quote from: kanonet on 2012-Dec-09
1. Its the code thats needed for one key. If you want to replace multiple keys, you need to do this for each key.
2. Im not sure if I understand what you mean, but if you want to stop movement, just set spritespeed to 0 or set dirx and diry to 0.
1. I meant if there was anything to add other than the LOCAL declaration and the IF adjustments. If that's it, I'll try it out today.
2. I meant moving the sprite one increment, and then either stopping or waiting a split second before moving anymore. If the code you gave can do that, awesome.
1. You need the LOCAL and the SET at the beginning of the program for each key. And obviously you need the adjustment of the IF sentence for each key. Thats all.
2. Sorry i really dont know what you mean, i bet its really easy to do, but it seems, that my English skills are to low to help you here, sorry for that. Maybe someone else can do it.
I think #2 is easing. A way of not moving full speed all the time but move at a lower speed, not one pixel each screen update. Faster computer = faster moving.
Try any of these:
http://www.glbasic.com/forum/index.php?topic=8530.0
http://www.glbasic.com/forum/index.php?topic=5892.msg46443#msg46443
Quote from: Moru on 2012-Dec-10
I think #2 is easing. A way of not moving full speed all the time but move at a lower speed, not one pixel each screen update. Faster computer = faster moving.
Try any of these:
http://www.glbasic.com/forum/index.php?topic=8530.0
http://www.glbasic.com/forum/index.php?topic=5892.msg46443#msg46443
I can just set the speed at a lower amount for that. The point is NOT the speed of the movement but causing the movement to not be constant.
Maybe you can describe what you want to do in other words? Cause I have no idea what you want to do...
Anyway im out for tonight.
Quote from: kanonet on 2012-Dec-10
Maybe you can describe what you want to do in other words? Cause I have no idea what you want to do...
Anyway im out for tonight.
Well if you run the code from the first post, or the code I later posted (just pick any picture for the sprite), you will see that the sprite moves smoothly and constantly as long as you press a directional button. I want a way to cause the sprite to move a certain amount, and then either stop moving altogether until the key is released, or wait a certain amount of time before moving again.
The real goal is a way to make the sprite move one "square" at a time, the way player characters in the first six Final Fantasy games moved.
Keep moving until x or y has passed 16 pixels.
Quote from: Moru on 2012-Dec-10
Keep moving until x or y has passed 16 pixels.
How do you put that in code?
This is where that highschool math comes in :-)
If your grid is 16 pixels you can use the command MOD(x,16).
This returns the reminder of the division x/16. When you are on even 16 pixel boundary, it will return 0 so you know when to set the speed to 0 after a keyboard release.
Untested pseudocode since I'm too long away from GLBasic...
IF key_down("w")
speed_y = -1
ENDIF
IF key_released("w")
IF MOD(y,16) = 0
speed_y = 0
ENDIF
ENDIF
y = y + speed_y
repeat for each key ofcourse.
My original code on the first pages attempts to move your player in a grid like fashion.
In my code, the grid was set at 32x32 - it will move 32 pixels each time you click left or right.
Then wait for another key to move another 32 pixels.
I coded it to use a tweening / easing library, but you could replace it with a simple linear ease, meaning it will move at the same speed for the entire 'trip'.
Here's my original post:
http://www.glbasic.com/forum/index.php?topic=8774.msg74593#msg74593 (http://www.glbasic.com/forum/index.php?topic=8774.msg74593#msg74593)
Moru's code wouldn't work if the characters needed to move exactly 16pixels every time - if you remove your finger from the key before the 16th pixel kicks in then the player might be halfway through a 16x16 square or even 15/16th through it. I presume that the player HAS to move 16 pixels smoothly from start to finish after a key has been pressed.
Here's what I think you want -
// --------------------------------- //
// Project: test
// Start: Monday, December 10, 2012
// IDE Version: 10.283
// Create a virtual screen
CREATESCREEN 1,999,16,16
USESCREEN 1
// Draw a rectangle to create a sprite
DRAWRECT 0,0,16,16,RGB(255,0,0)
USESCREEN -1
LOCAL press%, move%, dir%
LOCAL x=320, y=240
WHILE TRUE
// Up
IF KEY(200) AND dir=0
IF press=0
move=16
dir=1
ENDIF
press=20
ENDIF
// Down
IF KEY(208) AND dir=0
IF press=0
move=16
dir=3
ENDIF
press=20
ENDIF
// Left
IF KEY(203) AND dir=0
IF press=0
move=16
dir=4
ENDIF
press=20
ENDIF
// Right
IF KEY(205) AND dir=0
IF press=0
move=16
dir=2
ENDIF
press=20
ENDIF
// Move square
IF move>0
IF dir=1 THEN DEC y
IF dir=2 THEN INC x
IF dir=3 THEN INC y
IF dir=4 THEN DEC x
DEC move
ENDIF
IF move=0 THEN dir=0
PRINT "PRESS "+press,10,10
IF press>0 THEN DEC press
DRAWSPRITE 999,x,y
SHOWSCREEN
WEND
There are many ways to recreate this.
Quote from: Ian Price on 2012-Dec-10
Moru's code wouldn't work if the characters needed to move exactly 16pixels every time - if you remove your finger from the key before the 16th pixel kicks in then the player might be halfway through a 16x16 square or even 15/16th through it. I presume that the player HAS to move 16 pixels smoothly from start to finish after a key has been pressed.
Here's what I think you want -
...
There are many ways to recreate this.
That is pretty close to what I want. I'll see about incorporating it into the code I'm using.
Now I don't know if you came up with that yourself, or just are pasting it from elsewhere, but thank you either way. :happy:
Um, why wouldn't I have come up with that myself? It's not exactly rocket science. You ask for help and then wonder if it's pasted from somewhere else. Nice. That's not the best way to ask for help in the future...
See my post for Blobo's Quest - that had tile-based movement where the character would move on a grid until the key is released. I imitated RPG Maker's movement system, basically.
Quote from: Ian Price on 2012-Dec-11
Um, why wouldn't I have come up with that myself? It's not exactly rocket science. You ask for help and then wonder if it's pasted from somewhere else. Nice. That's not the best way to ask for help in the future...
I'm a newbie, both to this site and to programming languages. I honestly am not at the point where thinking up such code comes naturally. From my perspective, that could likely be a commonly used type of program, that's listed somewhere I haven't visited.
I was just stating I didn't know the origin of that program. If you think I was thinking you plagiarized it, I would have stated so, and not have thanked you or given a happy cloud emoticon in my response.
Quote from: Darmakwolf on 2012-Dec-11
See my post for Blobo's Quest - that had tile-based movement where the character would move on a grid until the key is released. I imitated RPG Maker's movement system, basically.
Got a link to it? I can look for it, but I wouldn't know which section, or how many pages in to click.
There you have it:
http://www.glbasic.com/forum/index.php?topic=8791.0
I´m still to give it a try too.
You might want to use the "Show unread posts since last visit." button when you get on this forum to see recent stuff.
QuoteIFrom my perspective, that could likely be a commonly used type of program, that's listed somewhere I haven't visited.
Did it really matter where it came from? You got a simple answer to a simple problem. Glad it was what you were looking for. :) Something similar probably is listed elsewhere, but that example code is my own, and is actually based on something I am working on at the moment.
The GLBasic forum is filled with beginners, intermediates and experts that will have individual solutions to any problem you can think of. Users have just got to ask for help to a problem in a way that other people understand!
Just because it doesn't come naturally yet, doesn't mean it won't over time. :)
Quote from: Ian Price on 2012-Dec-11
QuoteIFrom my perspective, that could likely be a commonly used type of program, that's listed somewhere I haven't visited.
Did it really matter where it came from? (1) You got a simple answer to a simple problem. Glad it was what you were looking for. :) Something similar probably is listed elsewhere, but that example code is my own, and is actually based on something I am working on at the moment.
The GLBasic forum is filled with beginners, intermediates and experts that will have individual solutions to any problem you can think of. Users have just got to ask for help to a problem in a way that other people understand!
Just because it doesn't come naturally yet, doesn't mean it won't over time. :) (2)
1. I guess it didn't come across when I wrote it, but my comment about that was mainly simple curiosity.
2. That's the plan, and should definitely happen with help from all of you. =D
Okay, with Price's code, I actually managed to make it stop until I released the key.
I took this line:
IF KEY(200) AND dir=0
IF press=0
move=16
dir=1
ENDIF
press=20
ENDIF
Tweaked it to:
IF KEY(200) AND dir=0
IF press=0
move=16
dir=1
ELSE
move=0
ENDIF
press=20
ENDIF
And did it for the other three directions. Now the square will not move until I release the button, and the counter goes to zero.
But for some reason, changing "press=20" to another number only works at 17 or higher. Lower numbers ignore the pause. I honestly wonder why that is. I'm still working on more of this though.
That's because the "press" variable is being decreased while the player is moving (in total 16 counts) hence the "press" count needs to be more than 16.
My code already makes the character stop until the key is released. You haven't actually improved or understood the code at all. :P
Quote from: Ian Price on 2012-Dec-14
That's because the "press" variable is being decreased while the player is moving (in total 16 counts) hence the "press" count needs to be more than 16. (1)
My code already makes the character stop until the key is released. You haven't actually improved or understood the code at all. (2)
1. That makes sense. I tested it out by changing 16 to 8 and 20 to 10, and it still worked.
2. I understand what a program is doing when compiled and run, and when I used the code on my end, the square moved constantly (but 16 at a time) without those tweaks, but paused with them. There might be some differences in how our compilers work.
EDIT: Okay, I tried it again with my tweaks commented out, and now it works properly anyway. Not sure if something changed on my system, or I just wasn't paying attention. Regardless, it's nice to know this can at least be done.
Quote from: erico on 2012-Dec-11
There you have it:
http://www.glbasic.com/forum/index.php?topic=8791.0
I´m still to give it a try too.
You might want to use the "Show unread posts since last visit." button when you get on this forum to see recent stuff.
oh - wrong game you linked there xD this is my more recent object-based platformer. I'll try to upload it again, think it got lost...
Okay - attached is my project I mentioned before. I think it does what you are looking to do! Feel free to take what you'd like from it :)
[attachment deleted by admin]
Quote from: Darmakwolf on 2012-Dec-18
Okay - attached is my project I mentioned before. I think it does what you are looking to do! Feel free to take what you'd like from it :)
It might be a couple days, but I'll download it and try it.
Okay please do! It's one of my... unusual projects... but I think it does what you want!
Quote from: Darmakwolf on 2012-Dec-18
Okay please do! It's one of my... unusual projects... but I think it does what you want!
I should have time to check it out tomorrow or the day after.
Quote from: Lord_TNK on 2012-Dec-18
Quote from: Darmakwolf on 2012-Dec-18
Okay please do! It's one of my... unusual projects... but I think it does what you want!
I should have time to check it out tomorrow or the day after.
did you give 'er a try?
Quote from: Darmakwolf on 2012-Dec-28
Quote from: Lord_TNK on 2012-Dec-18
Quote from: Darmakwolf on 2012-Dec-18
Okay please do! It's one of my... unusual projects... but I think it does what you want!
I should have time to check it out tomorrow or the day after.
did you give 'er a try?
Yeah, I tried it. Just been too busy for a while to really delve into it. Hopefully I'll be able to soon.
you pretty much use the arrow keys to move, and Z to attack.
Quote from: Darmakwolf on 2012-Dec-30
you pretty much use the arrow keys to move, and Z to attack.
Well I meant looking into the code and how it works.