Legacy GM Best way to structure this data?

[whale_cancer]

Hello!

In my map editor, I create a number of buttons out of background resources. These buttons are then used to set what the current brush is. This all works like a charm, but in order to do this I need to use an array for each and every background in order to hold the sprite_indexes created during this process. Thus, I have a chunk of code to initialize it that looks like this:

for (r = 0; r < 10; r += 1)
{
    for (c = 0; c < 9; c += 1)
    {
        tileSprites00[c,r] = 0;
        tileSprites01[c,r] = 0;
        tileSprites02[c,r] = 0;
        tileSprites03[c,r] = 0;
        tileSprites04[c,r] = 0;
        tileSprites05[c,r] = 0;
        tileSprites06[c,r] = 0;
        tileSprites07[c,r] = 0;
    } 
}

I am going to need to make 7 more sets just like this in order to hold all my resources.

Is there a way to have some sort of array of arrays hold this information? So I don't end up having to define and handle 64 arrays?

Edit: One huge array in order to store ALL the sprite_indexes has been ruled out, as I believe it would end up making referencing those indexes harder. I may try it if there are no other solutions.

Edit2: To restate the issue, I would ideally like to be able to reference my data by a 2d array which itself points to another 2d array without having to manually define all 64 arrays. Is this possible?

 

[Mercerenies]

Ostensibly, yes. There's nothing stopping arrays from holding other arrays. In C or a C-like language, you could reference elements with array_name[x][y][z]. Unfortunately, GM does not allow nested array references like this, meaning that while you can store arrays within one another, accessing them is a bit of a pain.

var inner = array_name[x];
var inner1 = inner[y];
var inner2 = inner1[z];

And storing things is even more of a pain.

var inner = array_name[x];
var inner1 = inner[y];
inner1[z] = new_value;
inner[y] = inner1;
array_name[x] = inner;

You can hide away a lot of these details by putting the read/write code in a script and using [@x] to access array indices (since that does some sort of semantic-change to get references, not copies). GM is really weird about how it handles call semantics with arrays. For this reason, my honest recommendation is to reconsider making one big 2D array, as you mentioned in your edit. It will make the indexing more complicated, but with the current state of GML, it's probably honestly the least painful solution.

 

[whale_cancer]

Post.

I feared that this was the case. I will leave this one as unsolved for now, just to see if there are any other ideas out there, while I get started on a bloody giant 2d array.