GameMaker Please for the love of god remove the array limit!

[Shadowblitz16]

hey I just recently found out that gml arrays can't go up to 65535 which makes my combo system very limited

can the devs please remove this? like maybe next update?
I am trying to make a system which uses combos which are basically a array of objects that can be used in a tilemap array.
however in zelda classic these range to 0-65535 to allow a vast amount combos.

please change it to be at least this amount thankyou.

 

[Stubbjax]

I'm fairly sure there hasn't been a limit to 1D arrays for a while now.

 

[Shadowblitz16]

well it gave me an error that it couldn't be greator then 32000 or something like that so there is in fact a array limit

 

[orange451]

You could always use 2 arrays, and depending on the index value, choose which array you want to use.

 

[FrostyCat]

well it gave me an error that it couldn't be greator then 32000 or something like that so there is in fact a array limit

This didn't give me any errors on 1.4.1763:

for (var i = 69999; i >= 0; i--) {
  array[i] = i*2;
}
show_debug_message(array[69876]);

Your version of GM has to be pretty old for that error to still come up, don't count on YoYo getting involved with that.

 

[Stubbjax]

What version of GM are you using? This code compiles and runs fine for me.

for (var i = 0; i < 80000; i++)
  array[i] = i;

 

[Shadowblitz16]

well its gms 2.0 umm lets see..

IDE Version: 2.0.5.77
Runtime Version: 2.0.5.49

it could be that they are 2d arrays so something like..
[65535, 16]

This is what I get...

___________________________________________
############################################################################################
FATAL ERROR in
action number 1
of Create Event
for object Game:

Array index must be < 32000
 at gml_Script_comboset_init (line 9) -        _comboset[i, CP_X]        = 0;
############################################################################################
--------------------------------------------------------------------------------------------
stack frame is
gml_Script_comboset_init (line 9)
called from - gml_Object_Game_Create_0 (line 8) - comboset = comboset_init();

 

[Stubbjax]

There is a limit on 2D arrays, but surely you don't actually need 1,024,000,000 (~1 billion) individual blocks of data? Best thing to do in that situation, if you really do need to store that much data, is to group the data into chunks. So instead of storing a single value per index, you would store several values for each index.

 

[Shadowblitz16]

oh like an array in a array instead of just a 2d array?

I was experimenting with that but I couldn't find a way to reference the values.
I tried doing..

var text = array[0][0];

 

[TheouAegis]

If you want an FFFFxN array, then just make N arrays of size FFFF.

 

[John Andrews]

If you want an FFFFxN array, then just make N arrays of size FFFF.

Such geniuse

 

[Shadowblitz16]

@TheouAegis the problem is that each of those array incidences are combos that hold data.
so it wouldn't make sense to to that.

 

[TheouAegis]

FFFF x N combos? I don't remember ZC being that expansive. The SNES Zeldas wouldn't even hold that much data. FFFF combos I can see, FFFF x N combos seems ludicrous.

if you mean each combo has N associated values, that is what you'd need N arrays for. I do agree, if you can just as easily make multiple maxed out arrays, then there should be no reason why you couldn't make one giant 2D array of the same size. But with the limitation that is there, the only alternative is to make multiple arrays.

 

[FrostyCat]

Do you really need it filled all the way to 65535? I'd bet most of those cells are empty, in which case the sensible thing to do is a sparse array implemented as a map. Something just screams you've messed up your data model.

 

[Shadowblitz16]

@TheouAegis ZC did support around FFFF combos at once. however I don't know how they where actually handled codewise.

@FrostyCat it would be for future proofing purposes but ya I don't think I've seen a ZC quest that uses all of them. but if you think of all the tiles from all the games and all the types there are I wouldn't be surprised if you could fill it up. although I don't think someone would put that much time into it.

@Mike is it possible this array limit could be handled so each index is represented by a Qword or at least a Dword??

EDIT: Does anybody know if a 1d array [65535] holding a 1d array [16] will get past this array limit?

 

[ChristopherD]

I'm approaching this problem as a long time non-game developer (only recently started to learn GameMaker Studio 2)
So, from my point of view the original question is not complete enough to offer a full recommendation of approach.
You keep referring to a "combo system" like its a natural thing, but I've never heard this term before.

Please give a concrete example of the data you're storing and how you're using it, with code.

• What kind of "combo" would you be using?
• You're storing a 2D array, so what does the first index represent in your "combo" and what does the second index represent?
• Are you filling the array entirely?
• What kind of data are you storing in the array?

Old-school hardware had to do the best they could with limited resources, but you don't have those same limitations. So comparing your array with old Zelda's array doesn't make much sense. Perhaps the developers would have done something differently if they had had a little bit more RAM or a little bit more ROM space. Likely they shoved everything into a single giant array because they had no choice.

Think about the data you have, then design a system that is best for that data. Don't try to force your data into some pattern that you saw in a game you like for a completely different type of hardware. That would be my main advice.

So, maybe we can help you design a better method for storing/retrieving your "combos."

 

[TheouAegis]

Old-school hardware had to do the best they could with limited resources, but you don't have those same limitations. So comparing your array with old Zelda's array doesn't make much sense. Perhaps the developers would have done something differently if they had had a little bit more RAM or a little bit more ROM space. Likely they shoved everything into a single giant array because they had no choice.

He's not talking about the Zelda games, he's talking about a game engine based around the Zelda games. Zelda Classic was like RPG Maker (or like Game Maker but without the heavy coding). So RAM wasn't an issue for them.

What kind of "combo" would you be using?

A combo in Zelda Classic is, for all intents and purposes, an object in Game Maker terms. Although they are essentially treated like tiles, they function like objects. If you don't assign any flagged values to a tile, it's an empty combo. If you assign the Pushable Trap flag, it can be pushed one direction. If you assign the Pushable Block flag, it can be pushed indefinitely. If you assign the Spike flag, it will damage the player when touched. And so on.


It's been a long, long time since I messed with ZC, but from what I recall, each combo had a limited number of functions assigned to it. So your array would consist of various bitwise values. While you'd still need multiple arrays (due to the number of options available), it'd only be 2 or 3 FFFF-sized arrays and the value of each index would be used with lookup tables or some such thing.

 

[bml]

He's not talking about the Zelda games, he's talking about a game engine based around the Zelda games. Zelda Classic was like RPG Maker (or like Game Maker but without the heavy coding). So RAM wasn't an issue for them.

I thought this was about the NES Zelda Classic? They did have memory constraints.

My understanding is that a combo is basically an integer with bits set that represents a single terrain square on a map. It includes: tile, collision data and various options. The various options include: is it trap, is it an enemy, can the block be pushed, is it a secret tile, is it a trigger, animation details, what kind of item is it, is it a chest, a door up, a door down, etc... The details change based on rules so a dungeon combo might be different that a surface combo.

To @ChristopherD 's point: My first thought was along the same lines. There isn't anything in Zelda Classic that can't be done in GMS from a game mechanics perspective. Trying to represent it with a specific implementation might not be the best choice. Combos are very limited and difficult to work with so unless you're trying to use specific combo editors or pre-existing combos, I'm not sure what advantage they offer. I once used PEEK/POKE on my Commodore 64, but I wouldn't try to re-implement them in GSM.

 

[jo-thijs]

@Shadowblitz16, I'm using the same version as you and this code gave me no trouble:

for(var i = 1000000; i >= 0; i--)
    a[i] = i;
show_message(a[1000000]);

var a = [[1, 2, 3], [4, 5, 6], [7, 8, 9]];
var b = a[1]
show_message(b[1]);

EDIT:
You can also create a script n which you input an arbitrary amount of indices and the script iteratively takes the value at the first given index and repeats the process on that array.

 

[Mike]

okay... first. GML variables are pretty large, so that array will be much larger than you thing. On a 2D array it's limited to 32000 as the index being passed around is an INT, and so can only store 2 16bit indexes in there. This is historical and won't change. 1D arrays are only memory limited I believe. if you still want that, then use a ds_grid, then use the accessor mygrid[# x,y] and it'll be just like an array, but they have no size limits - other than memory.

Second. Personally, for something this big I'd use a buffer. They have proper "types" so you can adjust the size to better fit what your trying to store. They aren't as fast, but you're memory foot print will be much, much lower.

 

[TheouAegis]

http://www.zeldaclassic.com/wiki/index.php/Combo_Type
http://www.zeldaclassic.com/wiki/index.php/Combo_Flag
http://www.zeldaclassic.com/wiki/index.php/Secret_Combo
http://www.zeldaclassic.com/wiki/index.php/Freeform_Combo


Unless they changed it, the whole setup was very global in nature. In other words, if you set a flag for something to be torchable with the Blue Torch, there was a global value you needed to set to tell the game what was to happen in that screen when something has been burnt. There were a lot of limiting factors, which is one reason I only dabbled with it but eventually moved away from ZC. It's still a fun little app to play around with, though.

 

[Shadowblitz16]

sorry I didn't know that you guys replied here.
anyways combos I would basically use for just map objects. I would want to allow the user to define his\her own types and attach scripts to them.
anyways I think the problem with the arrays is that I was using 2d arrays instead of a 1d array inside a 1d array. but a ds grid would probably do the trick.

however another problem that comes up is storing graphics (tiles) in a array or list since surfaces can't be saved and are probably not optimized enough for it.

 

[TheouAegis]

Might have to just save the graphics as sandboxed resources. You'd have one surface for when the user edits a tile. You'd have another surface for the full tile set. You'd draw the edited tile surface onto the tileset surface, then when the user clicks SAVE you'd save the tileset surface as a PNG file. The tiles themselves are just 0, 1, 2, 3,4, 5, and so on. The tricky part isn't the tiles, it's letting the player place multiple tiles in the room at once. The tiles in the room would still be 0, 1, 2, 3,4, whatever, but you'd have to define the "selection array" and transfer that array to the room data.

 

[Shadowblitz16]

well I was testing out 2d arrays (ds_grids) and I'm not sure if they are going to work I need to be able to access the by a 1d index and reference the combo_table data so I don't need to update the combo_map data manually.

 

[MilesThatch]

well I was testing out 2d arrays (ds_grids) and I'm not sure if they are going to work I need to be able to access the by a 1d index and reference the combo_table data so I don't need to update the combo_map data manually.

ds_lists are basically 1D arrays, ds_grids are basically 2D arrays. Ever since I've discovered the ds (data structures) I've pretty much stopped using arrays. They behave pretty much the same except data structures are waaaaaay more flexible in how you can toss around, add, subtract and generally handle the data. All the difference there is - is that you create the data structure like this:

my_data = ds_grid_create(w, h);

or for 1D

my_list = ds_list_create();

Now you can just use the variable that you stored your data structure for index in functions that retrieve and store data in the data structures.

ds_grid_get(my_data, x, y);

or for 1D

ds_list_find_value(my_list, pos);

Plus ds grids and lists can be dynamically expanded and shrunk unlike arrays... i (I think arrays are not dynamically expandable, you can only set them up a fixed size in the create event)

just don't forget to destroy the data structures when you close the application or generally don't need to use them any more in your game. They are like particles and surfaces, they need to be destroyed, otherwise they accumulate in the memory and cause memory leaks, leading to performance issues.

 

[Shadowblitz16]

@MilesThatch yes but there is no way to access grids with a 1D index. in python you could do.. list[0, *] I believe to get a convert it to a 1d list

also I'm not sure why this hasn't been added but you can't declare a list's size on creation so you have to fill it manually.

 

[CMAllen]

First of all, there's no such thing as a 2d data structure (or 3d or 4d). Not really. All data in a computer is stored linearly (ignoring memory fragmentation). It's *ALL* 1-dimensional. A 2nd (or 3rd or 4th) dimension is really just an offset multiplier appended to the first dimension. So a data look-up for array[30,20] is looking at address 30+20*x, where x is the maximum size of that dimension. In other words, you can create n-dimensional arrays in GM already. You just have to handle the other dimensions yourself instead of GM doing it behind the scenes (which likely involves additional processing overhead due to the interpretative nature of GML).

Second you might want to look into buffers. Buffers are arbitrarily sized 1d data structures and are 1-byte addressable in size (as opposed to all other data formats used by GM which are 4 bytes each, possibly 8 bytes). Furthermore, you can then use bitwise operations on each byte, allowing you to store a virtually unlimited number of possible property booleans or 'flags' as they're usually called (which, by the way, is what you're talking about -- they're properties, not 'combos'). However, as others are trying to point out, how many different properties are you trying to assign to objects? Because if you're trying to assign 80k different properties to every object, you're going to run into serious memory bloat issues. Take a step back a moment and think about what it is you're trying to accomplish. Chances are, you're vastly over-complicating things that can be accomplished by far simpler means.

 

[Shadowblitz16]

@CMAllen
they may be 1d data structures but you cannot access a grid with a 1d index.
also combos are not properties... they hold the properties. the combomap is basically references to the combotable.

 

[MilesThatch]

@CMAllen
they may be 1d data structures but you cannot access a grid with a 1d index.
also combos are not properties... they hold the properties. the combomap is basically references to the combotable.

You can't access a 2D array with just one iddex either. I don't understand where the issue is... Bot the 1D array and 1D ds need 1 X coordinate to access the data. It's just that with ds, you also supply the index of the data structure. Same thing with 2D arrat and a ds_grid, you'll need to supply both with an x and y value where the data is stored, it's just that the ds will also need an index of the data structure grid.

Give me an example here.

 

[Shadowblitz16]

I don't know.. I tried a list but the the code gets very messy.
grids are less messy but I can't supply a 1d index when I want to get or set all the properties at once.

It would just be nice if there was an easy way of doing this or at least a tutorial.
yoyo games doesn't want to add an expanded tile option for this sort of thing so I guess I'm out of luck right now.

I am trying to learn c++ right now because once I do I won't be limited to game maker any more.
anyways this topic can be closed. I don't even know if I still have my source around when I created this topic.

 

[Mike]

@CMAllen
they may be 1d data structures but you cannot access a grid with a 1d index.
also combos are not properties... they hold the properties. the combomap is basically references to the combotable.

You mean like....

grid = ds_grid_create(SIZE,1);
var a = grid[# index,0];

Not exactly complicated
I do this all the time for structures, using an ENUM for the 1st parameter, and 0 for the second.

If you need a "size" for each row, then just make the first entry a size and increment it as you add stuff.

 

[TheouAegis]

Well combos are restricted to 1 type each. ZC 2.5 only has 99 combo types, which is simply 7 bits of data. You can safely work with 63 bits (I think Studio is stable with 64), so that means you have 56 (or 57) bits to work with for anything else, such as flags. That's a lot of flags.

The combo flags were numbered because there were a limited number of flags. But it's also important to keep in mind that the flags only applied to combos already in the room. So in that regard, the flags could be restricted to a variable-size array simply holding the coordinates of the combo and the flag assigned to that combo. I think in GMS2 you may be able to actually do this just with the tiles themselves, but someone like Mike would have to go into details about that since I haven't had the attention span to mess with GMS2 yet. But if you have FFFF tiles, then this probably wouldn't be an option.

The combos themselves hold very little data. 99% of all the data is inside the program itself, not the combos.

Of course this was all assuming you wanted to stick pretty close to ZC.

 

[Shadowblitz16]

Thankyou @TheouAegis
I was wondering something about internal tiles though..
is it possible in gamemaker to store an array of pixeldata?

so tilesbank with a size of 65536 and single tiles with a size of 256?
this would make palette swapping much easier since I would be using index color to access the colors from my palette and current colorset

 

[TheouAegis]

I think it'd have to be 256 sheets of 256 tiles each, which is entirely possible. Nothing says you have to use one single tile set (it's just more texture swaps, possibly) and if your tile set got too big anyway, it'd be resized and distorted.

Or maybe I misunderstood what you meant about tilesbank and single tiles.

When you say array of pixel data, do you mean the RGBA values themselves - or rather, the indices for each pixel's color in a palette? Possssssssibly, although you'd be better off just storing everything into buffers (for memory management).

 

[Shadowblitz16]

I mean't indices for each pick's color in the palette

I was just wondering if gamemaker could handle something like that.
also it would be tile[65536, 256] but would be stored in separate arrays or just a grid so I don't pass the array limit.

 

[TheouAegis]

I don't think... you can do that with GM's tile system. Maybe GM2 will improve things down the road if they haven't started already. Working with palettes is a bit of a pain...

 

[lolslayer]

Use buffers

 

[Shadowblitz16]

@TheouAegis
I meant as my own custom zc tiles not gm tiles.

@lolslayer why? buffers don't have a way of accessing an index. it uses bytes so it would be much harder to store my pixel indices inside of one instead of just doing a array, list, or grid

 

[TheouAegis]

The indexing of the buffer would be algorithmic. If you want "tile" 54, you'd jump to position 54 in the buffer (or 54<<1 if it's u16 buffer type).

Still can't think of how to handle tile pallets in this situation, but it's always something I think about at least once a month when my mind wanders...