GML Local Vars and One collision checking script performance ?

[ragingdemonz]

I have an idea in my head which i'm sure many others have already thought of it. I've been using GMS2 for a while now and i'm still in the habit of Pre GMS 1.4 days.

However now that the step event is one gigantic text editor. I was wondering the effect it might have on local variables and collision checking. For instance at the start of the code if i were to make a local var called

onground = collision_checking_script() //Returns if touching floor or not

and just did a gigantic

//All Actions related to Collision detection go here
if onground
{
Action 1
Action 2
....nth action
}

would that technically boost my performance? Or would it roughly be the same since it has to check all the other actions as well?

just a thought before i go moving this this model of workflow.

 

[relic1882]

The main reason I write scripts is to better organize my code and not have to write the same code multiple times. There no performance difference whether you call a script or just have the code because your right about it having to go through all the code anyway. The benefit of the script is being able to call on it from anywhere and reuse rather than pasting that code in multiple places.

 

[YellowAfterlife]

Caching the values and not running checks again certainly helps - you can use profiler to see just how much. If it's for something that's a singular object (e.g. player), the difference will be minor and you can do what suits you better.

 

[TheouAegis]

You should never be doing multiple collision checks unless required for something. ...You also shouldn't be doing repeated variable checks, but that's such a fast operation that it's forgivable. Compare the common pixel perfect collision code with speed O(n+1) to tile collisions with speed O(1). The pixel perfect code gets slower and slower the higher your speed because it performs a collision check for each pixel you could move, whereas the tile collision only performs 1-3 checks regardless of speed.

onground = collision_checking_script()

This is still technically too slow. If you are in an idle state, that line is practically redundant. The only time it would be sensible is if the ground could disappear on its own, but even then the ground object or system controller (for collapsing tiles) could just as easily tell the player to go to it la falling state. With a running state, the line is practical, but logically it'd be used to change to the falling state.

In short, my biggest complaint with code like this is it asks, "Am I on the ground", which begs the question, "Why wouldn't you be on the ground?"

 

[ragingdemonz]

You should never be doing multiple collision checks unless required for something. ...You also shouldn't be doing repeated variable checks, but that's such a fast operation that it's forgivable. Compare the common pixel perfect collision code with speed O(n+1) to tile collisions with speed O(1). The pixel perfect code gets slower and slower the higher your speed because it performs a collision check for each pixel you could move, whereas the tile collision only performs 1-3 checks regardless of speed.



This is still technically too slow. If you are in an idle state, that line is practically redundant. The only time it would be sensible is if the ground could disappear on its own, but even then the ground object or system controller (for collapsing tiles) could just as easily tell the player to go to it la falling state. With a running state, the line is practical, but logically it'd be used to change to the falling state.

In short, my biggest complaint with code like this is it asks, "Am I on the ground", which begs the question, "Why wouldn't you be on the ground?"

Well because there are many reasons in my game the player may not be on the ground he could be attacking in the air , falling down, ran off a ledge , etc. The reason i bought this up is because i was doing checks every other action i needed. So i wanted to see if i can improve and optimize the code a bit more and possibly save a bit more resources.

I felt this method would beat doing ...

if place_meeting(x,y+1)
{
do this
}

if place_meeting(x,y+1) && this sprite
{
do this
}


since you're still calling the place the place_meeting function every step. rather than just

var on_ground = place_meeting_scr //Checks if player is colliding with anything

if on_ground{do this}
if on_ground and !this {do this}

you're only technically calling place_meeting once i could be wrong though but it just makes much more sense since the code is within the same editor, unlike before in gms1.4 where you have to seperate code snippets



and what @YellowAfterlife was mentioning.
you can see how quickly collision checking will take a toll on the game, since my game is a bit larger in scale, has a lot of different features than the average platformer, so i want to find the best way to do the collision check so it's not being done multiple times over within the code snippet since it's already done prior and stored into a local var which can be used throughout the rest of the code.