GMS 2.3+ Dropping fps

phillipPbor

Member
I'm going back to the community to talk to you about the,

I just followed the part 4 of minecraft game maker tutoriel.

Apparently, the game fps kepted dropping to 0 when ever I move to left or right in a render. Plus as I venture forward, fps decrease a bit more.
 

saffeine

Member
you're going to need to post the code you're using. the name of the tutorial and / or a link won't suffice, we're gonna need to see what's going on.
what code do you have for movement, and what code do you have in place for object generation. additionally, how many objects are being / have been generated? are you unloading any objects out of view?
 

phillipPbor

Member
you're going to need to post the code you're using. the name of the tutorial and / or a link won't suffice, we're gonna need to see what's going on.
what code do you have for movement, and what code do you have in place for object generation. additionally, how many objects are being / have been generated? are you unloading any objects out of view?
Here

GML:
// Script assets have changed
// for v2.3.0 see
// https://help.yoyogames.com/hc/en-us/articles/360005277377
// for more information
function scr_worldgen()
{
var sh, ah, dirt_lvl, stone_lvl, adl, start_rm, end_rm;
sh = choose(368,336,304);
//starting hight
ah = sh

start_rm = argument0;
end_rm = argument0+320;

for(xx = start_rm; xx < end_rm; xx += 16) {
    
//-----plains-----//   

    dirt_lvl = ah + 16*choose(1,2,2,3,3);
    stone_lvl = 960;
    
    instance_create_layer(xx,ah,"Blocks",ob_dirtwgrss_blk);
    
    //dirt level
    
    for(yy = ah; yy < dirt_lvl; yy +=16) {
        instance_create_layer(xx,yy+16,"Blocks",ob_dirt_blk);
        adl = yy
    }
        
    //stone level
    for(yy = adl; yy < adl+32; yy += 16) {
        u = round(random(choose(3)));
        if u = 1 {
                instance_create_layer(xx,yy+32,"Blocks", ob_stone_blk);
        }else{
                instance_create_layer(xx,yy+32,"Blocks", ob_dirt_blk);
        }
    }
    for(yy = adl+32; yy < stone_lvl; yy += 16) {
        instance_create_layer(xx,yy+32,"Blocks", ob_stone_blk);
    }
    ah += 16*round(random(choose(0,0,0,0,1,1)))*choose(1,-1);
    if ah <= 320 {
        ah += 16*round(random(choose(0,1)));
    }
    if ah >= 352 {
        ah += 16*round(random(choose(0,1)))*-1;
    }
}
    return end_rm;
}
 

saffeine

Member
still gonna need to see the movement code, and what your approach is to disabling objects outside of the view. when did it last run smoothly, do you know? any idea what you've changed since then?
according to the description of that video, you're supposed to learn how to avoid lag by getting to the end of the tutorial, so either something was done wrong or you just settled down too soon before optimisation.

likely culprits include:
- not unloading / deactivating instances outside of the view. this will lead to constant lag.
- not staggering terrain generation. this will lead to a LOT of lag in the beginning, but the rest will be fine if step 1 isn't an issue.
- lots of functions / events in general being called in each of your objects. again, will lead to constant lag while everything runs its own code.
 

phillipPbor

Member
still gonna need to see the movement code, and what your approach is to disabling objects outside of the view. when did it last run smoothly, do you know? any idea what you've changed since then?
according to the description of that video, you're supposed to learn how to avoid lag by getting to the end of the tutorial, so either something was done wrong or you just settled down too soon before optimisation.

likely culprits include:
- not unloading / deactivating instances outside of the view. this will lead to constant lag.
- not staggering terrain generation. this will lead to a LOT of lag in the beginning, but the rest will be fine if step 1 isn't an issue.
- lots of functions / events in general being called in each of your objects. again, will lead to constant lag while everything runs its own code.
1605025257550.png

1605025343442.png

here is render view code
and here is momentum code

the player_par is physic based as i wanted the game to be.
 

saffeine

Member
one thing i noticed is that in your render view code, you set render to false and then back to true. this won't functionally do anything, as the only thing between those two states is a script that doesn't utilise the variable.
that's less of an issue though, inside scr_view_player, do you have anything to combat the fact that you have a minimum of approx 270 objects in just the dirt layer alone? that'll cause some pretty massive performance issues.

at the end of render view code, can you try tacking this on?
GML:
instance_deactivate_object( ob_blk_par );
instance_activate_region( camera_get_view_x(0), camera_get_view_y(0), camera_get_view_width(0), camera_get_view_height(0), true );
this isn't the optimal way to use that code, but it'll probably be a decent start. going off the assumed 270+, that's a hell of a lot of draw events at the very least.
do keep in mind though, you may have to change ob_blk_par in that code to whatever the parent of the blocks is if it's any different, i'm just assuming here.
if it works, great. if it doesn't, not so great.

whether it works or not, i would recommend looking into optimisation techniques sooner rather than later. don't slow yourself down too much with learning about them, but it'll benefit you further down the line.
the main thing to keep in mind is that objects are / can be pretty performance-heavy by default, and the less execution you make your pc do at once, the better.
 

phillipPbor

Member
one thing i noticed is that in your render view code, you set render to false and then back to true. this won't functionally do anything, as the only thing between those two states is a script that doesn't utilise the variable.
that's less of an issue though, inside scr_view_player, do you have anything to combat the fact that you have a minimum of approx 270 objects in just the dirt layer alone? that'll cause some pretty massive performance issues.

at the end of render view code, can you try tacking this on?
GML:
instance_deactivate_object( ob_blk_par );
instance_activate_region( camera_get_view_x(0), camera_get_view_y(0), camera_get_view_width(0), camera_get_view_height(0), true );
this isn't the optimal way to use that code, but it'll probably be a decent start. going off the assumed 270+, that's a hell of a lot of draw events at the very least.
do keep in mind though, you may have to change ob_blk_par in that code to whatever the parent of the blocks is if it's any different, i'm just assuming here.
if it works, great. if it doesn't, not so great.

whether it works or not, i would recommend looking into optimisation techniques sooner rather than later. don't slow yourself down too much with learning about them, but it'll benefit you further down the line.
the main thing to keep in mind is that objects are / can be pretty performance-heavy by default, and the less execution you make your pc do at once, the better.
i already tried it and it looks weird.
GIF6.gif
flickering at the end of the blocks. i think the guy who first made game maker minecraft must have somthing to say about the lag.

i am remaking minecrtaft 2D using tutoriels btw.
 
Last edited:

saffeine

Member
yeah don't worry, i got that you were remaking minecraft 2d using tutorials when you said you finished part 4 of the minecraft 2d tutorials heh.

flickering aside, how's the performance? i know it's very strange asking that when the flickering is quite clearly not what you want, but at the very least if it's performing well, then you may be onto something.
do all of the blocks draw themselves, or are they handled by another object? does this only happen at the edge of the screen? can you show me where you put that code exactly, because it's weird that you're getting a result like that.
it's entirely possible that the code i gave you is a little bit off, but without a more hands-on involvement all i can really do for the moment is throw stuff at the wall and see what sticks.

that being said, i'm a little worried that maybe your game is creating instances regardless of where the player is, or is generating under the wrong criteria.
let me scan through the video again and i'll get back to you, one sec.
 
Last edited:

phillipPbor

Member
yeah don't worry, i got that you were remaking minecraft 2d using tutorials when you said you finished part 4 of the minecraft 2d tutorials heh.

flickering aside, how's the performance? i know it's very strange asking that when the flickering is quite clearly not what you want, but at the very least if it's performing well, then you may be onto something.
do all of the blocks draw themselves, or are they handled by another object? does this only happen at the edge of the screen? can you show me where you put that code exactly, because it's weird that you're getting a result like that.
it's entirely possible that the code i gave you is a little bit off, but without a more hands-on involvement all i can really do for the moment is throw stuff at the wall and see what sticks.

that being said, i'm a little worried that maybe your game is creating instances regardless of where the player is, or is generating under the wrong criteria.
let me scan through the video again and i'll get back to you, one sec.

1605031397964.png

note: this is the .
original code i put in scr_render before you gave me the code in the alternative way.
 

saffeine

Member
right, right. you don't have to include mine if you already have that somewhere, so you can remove it again. mine was thrown together on a whim but it does practically the same thing.
yours is actually a better fit than mine because not only did i forget to use view_camera[] in all 4 places, yours also accounts for the extra margin on all sides, so i'd stick with that version.
even when i checked the video you seem to have everything in place that i thought it might be. the only other thing i would mention is that i hope you are actually calling scr_render() at some point, but i imagine you are.

my next guess might be that it's because you're using the physics engine. i think it's performance-heavy, but i don't know enough about GMS' physics engine to say for sure, sorry.
 

phillipPbor

Member
right, right. you don't have to include mine if you already have that somewhere, so you can remove it again. mine was thrown together on a whim but it does practically the same thing.
yours is actually a better fit than mine because not only did i forget to use view_camera[] in all 4 places, yours also accounts for the extra margin on all sides, so i'd stick with that version.
even when i checked the video you seem to have everything in place that i thought it might be. the only other thing i would mention is that i hope you are actually calling scr_render() at some point, but i imagine you are.

my next guess might be that it's because you're using the physics engine. i think it's performance-heavy, but i don't know enough about GMS' physics engine to say for sure, sorry.
It's okay... the happends, I too am stuck with a glitch like that. If anyone have a better situation, then it will hope to be a better one.
I am using physics for player and objects, because I was planning on knock back. so... are you sure there isent any form in the GMS community where you can post the zip file? because i want people to beta test.
 
Last edited:

mikix

Member
Hey. Are you sure that you are not procedurally generating something in the background? Do you have a counter for when the procgen stops?
 
Top