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

Legacy GM Lists of Arrays and Deactivation of Persistent Instances

T

tomsaram

Guest
Hi,

So I have this dynamic data structure (say a list) of arrays in my game. And for whatever reason the accessors cannot stack on each other:
Code:
myVar = myDS[| listIndex][arrayIndex]; // does not work
I have to instead use this alternative strategy to access the data:
Code:
//strategy 1
var myArray;
myArray = myDS[| listIndex];
myVar = myArray[arrayIndex];
myArray = 0;
Or use some kind of script trick:
Code:
//strategy 2
///fetchElement(array, index)
return argument0[argument1];

//somewhere outside of the script
myVar = fetchElement(myDS[| listIndex], arrayIndex);
Well my problem with strategy 1 is that it makes a copy of the array, which is obviously not the most efficient thing to do. Strategy 2 seems promising, but I am rather skeptical about it, because if something as simple as this would work, then I don't see why the accessors cannot stack in the first place.

So this is why I am considering to replace my arrays by instances, which are deactivated and is basically a vessel for the data. This allows for a much clearer syntax (methink):
Code:
//strategy 3 - instances
myVar = myDS[| listIndex].data[arrayIndex];
myOtherVar = myDS[| listIndex].otherData; // data does not need to be an array
So here is my first question: is any one of the three strategies significantly better (or worse) than the other two? Or are they equally pathetic, and there is a correct way to go by unbeknownst to me?

Lets say I use the instance strategy, and the instances need to be persistent. Since they are deactivated, they need to be activated before the room changes:
Code:
//This needs to be done
//whenever room changes
for (i = 0; i < ds_list_size(myDS), i++){
    instance_activate_object(myDS[| i]);
}
room_goto(otherRoom);
This looks reasonable at the first glance, by turns out to be problematic. This means that each and every objects / scripts that calls room_goto() would need this structure, and myDS is neither global nor local to the instance calling, there can even be more than one such data structures, which makes this structure very ugly.

Is there an elegant way to do this? I have already tried the room_end event, which does not work.

Any help or insight would be much appreciated.

P.S. I am using GMS 1.4, but to by best knowledge, GMS 2 has more or less the same behavior. I have only read through the manual so I may be very mistaken.
 

Simon Gust

Member
can't you just add a "@" in the array brackets with this method?
Code:
//strategy 1
var myArray = myDS[| listIndex];
myVar = myArray[@ arrayIndex];
myArray = 0;
AFAIK, only the refrence of the array is copied.

The method with the instances sure is cool, but as you stated, they have to be activated between rooms which can cause stutter.

There are alternatives, like using list of buffers or list of bitmasks*.
though with any data structure, you'll most likely not be able to stack them on one line regardeless.

*not a data structure
 
Also, for the record, arrays are only copied when you modify them. You can have as many references as you want to an array and so long as you're only reading from them, they will all point to the original memory space, so in that case, using the accessor isn't strictly needed.
 
Top