Legacy GM [SOLVED]Why do I have to call THIS every step?

Spam1985

Member
Hi all. Hoping you can clear up something for me. My player object has variables for storing control inputs:
Code:
    key_right = keyboard_check(ord("D"));
    key_left = -keyboard_check(ord("A"));
    key_up = -keyboard_check(ord("W"));
    key_down = keyboard_check(ord("S"));
    key_jump = keyboard_check_pressed(vk_space);
    key_shoot = mouse_check_button(1);
    key_use_item = mouse_check_button(3);
Now I'd have thought just putting this in the create event would be fine, but no. I have to call this every step, otherwise the player does not respond to inputs and just shoots frequently!
I call these variables in the step event like this: if key_up do this or if key_shoot do this etc...
I mean, I've set these variables in the create event and they can't be changed. It's like he just forgets his variables?

Could anyone clear this up for me?
 
In the Create Event you're just initializing the variables, as it runs only once. In the Step Event you're actually updating their values, as it runs every step.
So, if you don't put it the Step Event you're actually checking the value held when the variables were initialized in the Create Event.
Hope that makes sense.
 

Slyddar

Member
When a key is pressed GM records the keyboard_check as a 1, when it's not being pressed it's recorded as a 0. You need to check it every step to see if it's being pressed or not for that step.
If you don't want to add it in the create you can use a local variable in the step only:
Code:
var key_right = keyboard_check(ord("D"));
It means it gets initialised for that one event each step, but if you do this, you won't be able to use the result in any other event as a local variable is deleted at the end of that event.
 

DukeSoft

Member
Yes - you're not binding events (like in Javascript) - you're setting a variable to a number.

You need to poll every step (frame) to see what buttons are pressed - the functions just return 0 or 1 based on if the keyboard button is pressed the very step that this code runs.

EDIT:

This works though;
Create:
Code:
key_right_binding = ord("D")
Step:
Code:
is_key_right_pressed = keyboard_check(key_right_binding);
 
Let's put it more visually.

Create Event:
Code:
right = keyboard_check(vk_right);
This turns into:
Code:
right = 0;
Now, right is set to 0. That's all. It's not 'set' to checking the key. It's set to the value that the key check function returns, which is 0 (unless you happened to be pressing the key when the instance was created, then it would be 1, but it's 0 for this example). Now, if you don't add it to the Step Event, right will always be 0 for the rest of the instances life. That's one of the things a function can do, it simply returns a value. It doesn't magically keep checking itself. It just returns a number. So you need the Step Event check so that when you DO inevitably press right, the variable gets updated to 1.
 

Spam1985

Member
OK guys, thanks for clearing that up for me. I've been trying to optimise and seeing what I can remove from the step event.

Case closed. Thanks again.
 
Optimise your draw pipeline first, that is what takes by far the most processing time. Remove as many draw_rectangle, draw_circle, etc calls as possible. Draw_sprite is the fastest of the basic draw calls, if I'm remembering correctly. You can optimise further by using vbuffers and primitives, etc. If you're drawing more than one thing that doesn't change, draw it to a surface once and then just draw the surface (rebuilding it as necessary, because as we know surfaces are volatile and can be deleted at any time). Even if the things you're drawing change, if they don't change super often, you can do the same thing and just update the surface whenever the 'thing' happens that makes the draw need to change. Variable setting is such a minor event that it's very rarely worth it to optimise things like that, same as loops. There's far bigger fish to fry in optimisation.
 

Spam1985

Member
Thanks, Towel. I changed the way my wall objects work the other day so that I can stretch them in the room editor and they will draw repeating tiles according to their size. Don't know if it's efficient but it means more tiles, fewer objects.

I don't think I can use surfaces because the depths for the walls/tiles are based on y and z positions
(maybe for the floor though). My main problem with this is that sometimes tiles can overlap in the same space.
 
Last edited:
Top