1. Hey! Guest! The 36th GMC Jam will take place between February 27th, 12:00 UTC - March 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice
  2. NOTICE: We will be applying a Xenforo update on Tuesday 25th of February. This means that from approximately 10:00 to 14:00 BST the forums will be offline (or possibly longer). Sorry for the inconvenience! Official Announcement here.

GML Local Vars and One collision checking script performance ?

Discussion in 'Programming' started by ragingdemonz, Jan 23, 2020.

  1. ragingdemonz

    ragingdemonz Member

    Joined:
    Jun 28, 2016
    Posts:
    295
    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.
     
  2. relic1882

    relic1882 Member

    Joined:
    Apr 5, 2018
    Posts:
    32
    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.
     
  3. YellowAfterlife

    YellowAfterlife ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ Forum Staff Moderator

    Joined:
    Apr 21, 2016
    Posts:
    2,507
    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.
     
  4. TheouAegis

    TheouAegis Member

    Joined:
    Jul 3, 2016
    Posts:
    7,449
    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?"
     
  5. ragingdemonz

    ragingdemonz Member

    Joined:
    Jun 28, 2016
    Posts:
    295
    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.
     
    Last edited: Jan 23, 2020

Share This Page