• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Couple of question on the limits of GMS

Zuljaras

Member
Hello everyone!!!

So I have Googled for some time and I would love for someone to answer me those questions about the limits of Game Maker:

1. How many objects can a game have. By how many I mean unique objects in the resource tree NOT in the room. I know that the objects in the room are dependant on the code in them and the current machine. I read somewhere that only 100 000 objects are allowed in GMS before they start overlapping their IDs. I thought that the IDs are for instances not objects.

2. Is there a limit of how much lines of code could one sheet have?

The first question is more important for me.
 

Sabnock

Member
1. you think you need more than 100,000 objects? you can have many instances of the same object.
2. i know of no limit. i believe it is just a text file.
 

Zuljaras

Member
1. you think you need more than 100,000 objects? you can have many instances of the same object.
2. i know of no limit. i believe it is just a text file.
Yeah I know that I can have many instances. But is the limitation something to worry about if you make more open world game (HUGE game) with many unique objects that use many effects as objects.

Did anyone ever reached the limit?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
I would expect that whomever said of 1 meant that instance IDs start at 1 million (not 100K), thus you are probably only allowed that many objects, but that's far more objects than you could add - I don't think I've ever seen a game with more than 3 thousand, and even that was because the author was more comfortable with making single-use objects than using instance creation code in room editor.

I don't think there's any hard limit on number of lines of code. There might be a soft limit on number of lines of code in a single script/event due to your machine not being able to handle syntax highlighting logic anymore, but even then this comes maybe at ten thousand lines, and you can use external editors (my own GMEdit, VS Code, Notepad++, etc.) to edit blatantly oversized files
 

Zuljaras

Member
I would expect that whomever said of 1 meant that instance IDs start at 1 million (not 100K), thus you are probably only allowed that many objects, but that's far more objects than you could add - I don't think I've ever seen a game with more than 3 thousand, and even that was because the author was more comfortable with making single-use objects than using instance creation code in room editor.

I don't think there's any hard limit on number of lines of code. There might be a soft limit on number of lines of code in a single script/event due to your machine not being able to handle syntax highlighting logic anymore, but even then this comes maybe at ten thousand lines, and you can use external editors (my own GMEdit, VS Code, Notepad++, etc.) to edit blatantly oversized files
So it is 1 million not 100 000?
I read this posted my moderator here:
"There are no GM:S-side limits regarding particles. Graphic resources (sprites, backgrounds) also have no such limits.

There is one for objects, though, which is 100000 (one hundred thousand)... or if you're pedantic, 100001, because indices start at 0.
Once you have created that many objects, their IDs will start overlapping with instance IDs (which start at 100000). As it is possible that one ID can refer to both instances and objects in particular situations, having more than 100000 objects can lead to unexpected behavior. If your game needs that many objects, though, that limit is not your main problem."

That is why I ask about the limit. Probably I will not reach it but I would love to know.
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
So it is 1 million not 100 000?
I read this posted my moderator here:
"There are no GM:S-side limits regarding particles. Graphic resources (sprites, backgrounds) also have no such limits.

There is one for objects, though, which is 100000 (one hundred thousand)... or if you're pedantic, 100001, because indices start at 0.
Once you have created that many objects, their IDs will start overlapping with instance IDs (which start at 100000). As it is possible that one ID can refer to both instances and objects in particular situations, having more than 100000 objects can lead to unexpected behavior. If your game needs that many objects, though, that limit is not your main problem."

That is why I ask about the limit. Probably I will not reach it but I would love to know.
You can test the number for the specific GM version by doing show_debug_message(id) for an instance and seeing what the base number is. Checking the most recent GMS2 build, it seems to be 100000, but HTML5 used 1000000 for a while (this is what I recalled 1M from).
 

Zuljaras

Member
You can test the number for the specific GM version by doing show_debug_message(id) for an instance and seeing what the base number is. Checking the most recent GMS2 build, it seems to be 100000, but HTML5 used 1000000 for a while (this is what I recalled 1M from).
I am sorry but how exactly to do that? And I mean objects not instances in the room. I want to know how many I can have in my resource tree. I tried this but it does not show me anything so I guess I am doing something wrong.
 

JackTurbo

Member
If anyone is concerned about a limit of objects, that may or may not be 100,000 or more, I think they would be better off;

1. Taking a long long look at their scope and considering if it's realistic

2. Take a look at their coding practices/patterns and see if objects can be consolidated and reused more.
 

Zuljaras

Member
If anyone is concerned about a limit of objects, that may or may not be 100,000 or more, I think they would be better off;

1. Taking a long long look at their scope and considering if it's realistic

2. Take a look at their coding practices/patterns and see if objects can be consolidated and reused more.
That is fine. I just wanted to know if someone had issue with the limit like ever :D
 

TsukaYuriko

☄️
Forum Staff
Moderator
I feel addressed. Quite sure that "moderator" quote is from me. :p

My mention regarding the "limit" here is that instance IDs start at 100000 and object IDs start at 0, and while those two usually won't get in each other's way, there is a special case when you have more than 100000 objects in the resource tree. This is the point where it becomes possible for an object and an instance to have the same numerical ID. That by itself is perfectly fine too and will not cause any inherent problems. However...

Object IDs and instance IDs can sometimes be used in the same context - for example with statements. In this case, it will become impossible to tell apart whether "100000" refers to an instance or object.
It is theoretically possible for instance 100000 as well as instances of object 100000 to be in the room at the same time. Whether "100000" will refer to the single instance or the multiple instances is, as far as I can tell, undocumented and would require an official statement.


So, to answer the question again in an as concise manner as possible:

You can have up to 100000 objects in your resource tree without any possibility of mix-up side effects.
The maximum amount of objects in your resource tree with a possibility of mix-up side effects is not soft-limited. It is at most hardware-limited. The exact limit depends on the data type object indices are stored as. I can't provide the exact limit as I don't have access to anything that documents this.


That aside, I've never seen anyone run into issues because of this. Probably because I've never seen anyone actually create 100000 objects.
 

Zuljaras

Member
I feel addressed. Quite sure that "moderator" quote is from me. :p

My mention regarding the "limit" here is that instance IDs start at 100000 and object IDs start at 0, and while those two usually won't get in each other's way, there is a special case when you have more than 100000 objects in the resource tree. This is the point where it becomes possible for an object and an instance to have the same numerical ID. That by itself is perfectly fine too and will not cause any inherent problems. However...

Object IDs and instance IDs can sometimes be used in the same context - for example with statements. In this case, it will become impossible to tell apart whether "100000" refers to an instance or object.
It is theoretically possible for instance 100000 as well as instances of object 100000 to be in the room at the same time. Whether "100000" will refer to the single instance or the multiple instances is, as far as I can tell, undocumented and would require an official statement.


So, to answer the question again in an as concise manner as possible:

You can have up to 100000 objects in your resource tree without any possibility of mix-up side effects.
The maximum amount of objects in your resource tree with a possibility of mix-up side effects is not soft-limited. It is at most hardware-limited. The exact limit depends on the data type object indices are stored as. I can't provide the exact limit as I don't have access to anything that documents this.


That aside, I've never seen anyone run into issues because of this. Probably because I've never seen anyone actually create 100000 objects.
Yes. It was your post. :) I just did not know about such limits.

As I make my game I like to know I am free to create as much objects as I want. For example for one enemy I like to make the following:
1. One Object for the enemy itself
2. One Object for the death of the enemy.
3. One Object for effects of the enemy like blowing into pieces etc.
4. One Object or two for weapons or projectiles etc.

Some bosses also have at least 30 different Objects.
I know I can manage with less objects but I prefer the freedom of making new ones that will have specific roles.

Anyway come to think of it if I have 200 different unique enemies in the game and each having 20 objects for themselves will be counted as 4000 unique objects. (I am making the example of enemies because those are the objects that are most in any game at least for me! :) )

That is not even coming close to the 100 000 objects.
 
V

visualbug

Guest
interesting topic, what about sprites?

we can have any slowdown if my sprites are fully animated (many number "drawings")?

does anybody reach slowdown on gameplay with a heavy animated sprite like a character?
 

TsukaYuriko

☄️
Forum Staff
Moderator
*grumble grumble* hijacking *more angry squidward noises*

It's reasonably related and a likely follow-up question, so I'll leave it here. :p


The amount of sprites you can have in the resource tree is theoretically unlimited, hardware and data type range limits aside.

Having a truckload of sprites alone will do nothing to performance, as nothing is being done with them at run time.

Having said truckload of sprites loaded into memory may induce a performance hit upon initially loading the sprites into memory, though, freezing the game until the texture page is loaded (this can take less than a frame for a single texture page or longer depending on how many pages are being loaded and how large they are). Sprites, or, to be specific, the texture pages containing them, are not loaded by default and will only be loaded when attempting to draw a sprite on a texture page that is not yet loaded, or when explicitly loaded via sprite_prefetch*.

Drawing sprites contributes to the processing workload, and therefore the amount of computing power it takes to process and render a frame. Therefore, drawing more sprites than the target device is capable of handling will eventually lead to slowdown.

Regarding the "heavy animated sprite" part: How a sprite is animated does not matter, as only a single frame of this animation would be drawn at a time. Only said frame will contribute to the processing workload.

The main concerns are how many draw calls you're performing every step and how many of them use sprites that are located on different texture pages. Drawing a sprite that is not located on the texture page that is currently loaded into VRAM will cause a texture swap. (VRAM is not to be confused with RAM - only one texture page can be loaded into VRAM at a time, but many can be loaded into RAM.)

This swap needs to happen because only texture pages loaded into VRAM can be drawn, and the swapping process stalls the draw pipeline as it can not continue until it is completed, therefore inducing another performance hit. Depending on how many texture swaps occur during a frame, the resulting increase in workload may lead to noticeable slowdown. While a low amount of texture swaps is no reason for concern and, depending on the game and its capacity, is a normal occurrence, excessive texture swapping in high double or triple digits should be avoided at all costs, especially on low-performance platforms.

Another concern is RAM usage - I was going back and forth about this with @kupo15, here and on the old GMC, filter topics by author on both and you're likely to find a gold mine of topics about sprite memory management. The summary is that GMS games are subject to the limitations of 32 bit applications (as of writing), and therefore can only use roughly 2 GB of RAM. This means that it is impossible to keep a theoretically unlimited amount of sprites loaded into memory concurrently, as the amount of available memory is finite.


What's next? "How many sounds can I have in my game"? "How many variables can I have in my game"? "How many times can I hijack this topic before Tsuka blows a fuse"? :p Keep 'em coming and we're just a few steps away from turning this into a collective reference about GMS limitations. :D
 

kupo15

Member
Yep, I haven't hit any issues so far with performance and memory and my game is very ambitious in the resource and resolution department. Even on my work laptop, the game ran fine when I put it down to a lower resolution (application surface resolution)
 
D

Deleted member 13992

Guest
There are smarter ways of creating the illusion of greater object variety. If you have 1000 food items that can be consumed, instead of making 1000 objects, why not create just one? Then have some clever scripting manage the behavior, stats and appearance of the item when it's spawned in the world as an instance. I think this is a much more efficient way.
 

Niels

Member
i want yo use a different object for every blade of grass in my million square kilometre open sandbox world. will i hot a restriction?
You will cripple unreal engine running on a NASA pc doing that:)

Open world AAA games don't actually move the grass sprites/object, they use a displacement shader to make it look like the grass moves, same goes for trees waving in the wind
 
You will cripple unreal engine running on a NASA pc doing that:)

Open world AAA games don't actually move the grass sprites/object, they use a displacement shader to make it look like the grass moves, same goes for trees waving in the wind
I detect a possibilty that @Sabnock was being sarcastic.
 
Top