• 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!

SOLVED dynamic resources in a function

Roa

Member
Okay, so this is absolutely breaking my brain.

if I have a script

GML:
function DoThing(){

var buffer=create_buffer(64,buffer_fixed,1);
return buffer;
}
How the heck would you delete the dynamic resource on return without leaving a memory leak? Does the Var attribute auto mark the buffer for cleanup, or do I still gotta bin it myself? Does it bin itself if called in a function? And if not, how can you do this when the thing you want to return and exit the script with is the resource itself? You can't very well call cleanup after...


The only solution I can come up with is make run a function to make the struct, that in turn runs the function inside the struct, run a return, then call function to delete the struct and its dynamic resources...

But that's stupid.

Not even sure that would work on second thought...
 
Last edited:

NightFrost

Member
Yes the variable gets cleaned up as it is marked local with the var. However the variable is not the buffer but a reference to it, and you're sending the reference to whatever catches it at the other end of the function call. Meaning the buffer remains accessible as you still have a reference until the time you use buffer_delete() on it.
 
The only solution I can come up with is make run a function to make the struct, that in turn runs the function inside the struct, run a return, then call function to delete the struct and its dynamic resources...

But that's stupid.
That's not stupid; and yes, it is the solution.

If a script was to delete dynamic resources in a local variable, it would be either A) impossible to return them, since local vars are limited to the function, or B) delete the resource in the local var and return a copy, which would require the above solution anyway.
 

Roa

Member
That's not stupid; and yes, it is the solution.

If a script was to delete dynamic resources in a local variable, it would be either A) impossible to return them, since local vars are limited to the function, or B) delete the resource in the local var and return a copy, which would require the above solution anyway.
It wouldn't be impossible to return as it would be returned before the script ends lol What language
deletes temps and locals before return??
The solution is a mess, not even sure it works

GML:
buff=DoThing();

function DoThing(){
    var struct= new struct();
    var buff=struct.buff;
    struct.delete();
    return buff;
    }

function struct constructor(){
    buff=buffer_create(64,buffer_fixed,1);
   
    delete = function(){
    if buffer_exists(buff){buffer_destroy(buff)};
    }
}
 

Roa

Member
Wow, NVM, I'm smarter than this... lmao

the buffer index never changes ,and It doesn't matter what variable you store it in. it's just copied an index and doesn't live in the variable itself. Infact, you don't even need to store it in a variable technically. You can just give it a number of an index, They all point the same.


GML:
buff=buffer_create(64,buffer_fixed,1);
var buff2=buff;

buffer_delete(buff2);

if buffer_exists(buff) show_debug_message("buffer still lives")
else
show_debug_message("you stopped hell from freezing over")
console:you stopped hell from freezing over

this is perfectly legal :bash:

And yes, the original way in mind is definitely stupid, especially considering this would be a problem before the introduction of structs. I knew there had to be SOMETHING more common sense than what I was doing here

@nacho_chicken you kicked the lightbulb on in my head though.
 
Last edited:

Neptune

Member
Anything capable of causing a memory leak, never actually lives inside of a variable, it's always just an index! (officially called a pointer?)
At least as far as I've learned.
 
Last edited:
Top