• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

game_end?

TsukaYuriko

☄️
Forum Staff
Moderator
Call taskkill on the game process via an extension?

If you tell us what you need this for, we may be able to provide better suggestions.
 

Neptune

Member
Alright, hmm..
The game hangs (and doesnt recover) on exit when people have played for 5+ hours (when RAM occupancy is at its highest usually).
 

Neptune

Member
Well it's like 800mb at the start, and then there are many things the player can do to raise it, either by direct action with the world, or simply entering and leaving rooms they havnt been to before (causing more save data to be accumulated).

There's also the engine-side memory leak with strings that I can't replace with my own leak-free system, because it's too slow for larger data.
I honestly don't know how high... Maybe 1 to 2 gigs.

Which doesnt seem high enough to be the culprit 🤔
 

TsukaYuriko

☄️
Forum Staff
Moderator
Is your game using the 32 bit or 64 bit runtime? A bit less than 2 GB is your limit on the 32 bit one. If your game's exit code (e.g. Game End or Room End events, anything else that gets called when you quit the game) somehow increases the memory usage past this point, that'll have unexpectable consequences.

On the subject of that, what is your game's exit code?
 

Neptune

Member
Oh actually! I do have one game_end event, which writes a text file saving your options/settings and some other misc information.
Are you thinking that could do it?

It's pretty small, but here is that:
GML:
function save_main()
{
    global.DS_main_map[? "version_number"] =                global.version_number;
    global.DS_main_map[? "build_number"] =                    global.build_number;

    //MISC MAIN DATA
    //=============================================================================================
   
        global.DS_main_map[? "main_seconds"] =                global.main_seconds;
        global.DS_main_map[? "gp_first_options"] =            global.gp_first_options;
        global.DS_main_map[? "DS_option"] =                    scr_grid_write(global.DS_option);
        global.DS_main_map[? "DS_binding"] =                scr_grid_write(global.DS_binding);
   
    //=============================================================================================


    var save_data = ds_map_write(global.DS_main_map);
    var file_name = "main.data";
    if file_exists(file_name) {file_delete(file_name);}

    var file = file_text_open_write(file_name);

        file_text_write_string(file,save_data);
   
    file_text_close(file);

}
[EDIT] Perhaps I should do this a few frames before game_end() is called, and just skip the event entirely...
 

Vusur

Member
Are you freeing all your grids and custom grid manipulations at the end? Are you sure it's properly? If I remember correctly, you were heavily using grids, maps, nesting and stuff and encountered already a leakage problem (?).
If freeing DS is made wrong and the accumelated data got quite big in there, the garbage collecter will be on fire.
 

TsukaYuriko

☄️
Forum Staff
Moderator
Yup, I meant the likes of code that runs after game_end. :)

I see a couple of things in there that will allocate new memory. I mean not just the space a new reference to a map, but actual new data. For example:
GML:
scr_grid_write
This is not a default function, so I can't know exactly what this does. Sounds like it converts data from one format to another format, though, so new data.

GML:
ds_map_write
This will create new data, and probably have it take up more space than the original. In my experience, it roughly triples it.

If, for example, the data you're saving here takes up 250 MB in memory (largely exaggerated, I hope) and your game resources take up 1 GB, then this single line will blow up the 250 MB usage to 1 GB. On a 32 bit runtime, this may immediately crash your game, especially if you're converting data structure data around as strings anywhere else (which, if I correctly remember your other topics, you are, or were doing at some point) because that'll explode that data's memory usage in a similar way.

Since you're using the 64 bit one, that's not the case. Total memory usage is still limited by the player's hardware, though. So even if the 2 GB limit is not a general concern, you're still blowing up the memory usage at the end of the game. I can't tell you exactly by how much, but you can measure that if you're curious to see how much of an impact it really has (if this is save data that grows in size the more people play the game, make sure to test with an endgame save file).


Alternatively, is there any other code that runs after game_end?
 

Neptune

Member
@Vusur I definitely am careful during a session, but I should be able to just let all active memory dump on game_end() (without manually calling ds_*_destroy on everything)

@TsukaYuriko The script is just an alternative to ds_grid_write that is slower, but doesnt have leak issues and reduces the file size.


I will move that bit of game_end code before the event, and maybe run an instance deactivation before that too and see if any improvement!
Thanks for the info~
 
Top