gms2 limit

olr0493

Member
Hi, it's my first post, so I don't know how to do it.

My question is about the limits of gms2 regarding the number of sprites and sounds, I have searched about he theme and there are a lot of contradictory posts, some people say that it is possible and others say that the game would freeze at the beginning.

the doubt is this, it would be possible to create in gm2 a game that has hundreds of texture pages, hundreds of sounds and has an exaggerated weight like 600 GB? I have currently been working for 2 years on a game that I estimate will weigh 3 to 4 GB and will have 300 texture pages .
I am worried that it will progress in my project only to see it crash due to memory limitation
 

FoxyOfJungle

Kazan Games
I don't see why you should worry about that, as it is impossible for your project to reach 600 GB, only if you work your whole life on it until GMS 2 stops working.
Keep working on your project that there will be no resource limit, if the game gets heavy, just the computer that will have to have hardware that supports it (if you use shaders for example), which is something different.
The only limit that could be would be that GMS 2 can only use a certain amount of RAM, but I am not reminded if it is 2 GB or 4 GB, but anyway, it is a matter of management, as GTA V can use on average 2 GB. ¯\_(ツ)_/¯
 

olr0493

Member
Thanks for answering ^^ my concern comes because many people say that if a game reaches 4gb of files in total they will block the game, because gm2 loads all the files/textue pages/sounds at the beginning in the ram, I do not know if it is true, but many say it.
 

Joe Ellis

Member
It does load everything into ram at the start by default, but you can set it up so it doesn't, then you just tell it to load what it needs for each level it's on. If you look up in the manual about texture handling you'll be able to work out a system for this. I'm not sure if the sounds are the same though.
 

Sybok

Member
Thanks for answering ^^ my concern comes because many people say that if a game reaches 4gb of files in total they will block the game, because gm2 loads all the files/textue pages/sounds at the beginning in the ram, I do not know if it is true, but many say it.
It's not a case of 'they will block the game'. It's a case of 32 bit limitation on the target.

Many of the export targets support 64 bit now.
 

Joe Ellis

Member
I know that it's completely possible to have a game with 600gb of data and only load what's needed at the time which will be about 2gb.
It's just you might have to spend a bit of time working out a system to handle all this. But in terms of generally programming a whole game, this is a pretty high level thing (like a guy polishing a german sports car after it's been engineered and built to perfection)
 

olr0493

Member
I know that it's completely possible to have a game with 600gb of data and only load what's needed at the time which will be about 2gb.
It's just you might have to spend a bit of time working out a system to handle all this. But in terms of generally programming a whole game, this is a pretty high level thing (like a guy polishing a german sports car after it's been engineered and built to perfection)
I see, is that in another post several people did tests and discovered that game maker loads everything at once to memory, I should not worry about memory ? , my game will hardly reach 4 GB in weight, and I already have organized the texture pages

It's not a case of 'they will block the game'. It's a case of 32 bit limitation on the target.

Many of the export targets support 64 bit now.
So it's not the size, it's the export ?
 
Last edited:

TsukaYuriko

🌠
Forum Staff
Moderator
It's the architecture of the export's target. 32 bit processes can allocate up to roughly 2 GB in your RAM. You can look up which exports are 32 bit only here: https://help.yoyogames.com/hc/en-us/articles/227860547-GMS2-Required-SDKs

Games on those target platforms will crash upon starting if you attempt to load more than 2 GB into RAM. Whether you're doing this doesn't depend on the file size of any of your resources, but on how many you are loading at the same time as well as their size in RAM (which is not equal to the size on disk). That part is entirely up to you, GM games only take up a couple of MB in RAM by default for an empty project.
 

olr0493

Member
It's the architecture of the export's target. 32 bit processes can allocate up to roughly 2 GB in your RAM. You can look up which exports are 32 bit only here: https://help.yoyogames.com/hc/en-us/articles/227860547-GMS2-Required-SDKs

Games on those target platforms will crash upon starting if you attempt to load more than 2 GB into RAM. Whether you're doing this doesn't depend on the file size of any of your resources, but on how many you are loading at the same time as well as their size in RAM (which is not equal to the size on disk). That part is entirely up to you, GM games only take up a couple of MB in RAM by default for an empty project.
I recently found a post, in which someone tried a game with many files and an empty room, in the end he said that gms2 always loads all the files at the beginning, so if a game reaches a size like 4 or 5 gigabytes, the ram would make it crash, managed my texture pages, I can avoid that?
 

TsukaYuriko

🌠
Forum Staff
Moderator
All sprites and audio resources are loaded at the start of the game.

This specifically means resources in the asset browser, not included files which are then dynamically loaded at run time.
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
If a game like Forager (3000+ sprites, iirc) or Hyperlight Drifter (200+ texture pages, iirc) or Swords of Ditto (no idea how many resources but the sprites are incredibly high quality and there are a LOT of them!) don't reach hardware limits and are made with older versions of GM then I think you'll be okay... Reaching the limits of hardware using GM is actually pretty hard, and probably down to poor texture page and audio group management rather than too many assets. ;)
 

Yal

🐧 *penguin noises*
GMC Elder
You can see resource usage when running the game in Debug Mode, so keeping an eye on those statistics and making sure the game doesn't reach 2GB memory usage during normal play (and if it does, fixing it) should be a good first step. You might also want to keep an eye on the VRAM usage / texture swap step time utility ratio, to keep track of whether you've found a good balance between smaller texture pages but not having too many texture pages (constant swapping degrades performance).
 

FoxyOfJungle

Kazan Games
If a game like Forager (3000+ sprites, iirc) or Hyperlight Drifter (200+ texture pages, iirc) or Swords of Ditto (no idea how many resources but the sprites are incredibly high quality and there are a LOT of them!) don't reach hardware limits and are made with older versions of GM then I think you'll be okay... Reaching the limits of hardware using GM is actually pretty hard, and probably down to poor texture page and audio group management rather than too many assets. ;)
This is not very difficult, it's not that hard to leave heavy hardware in the Game Maker, a simple memory leak can crash the DirectX and make the game stop working, or load external files without stopping... In the old version of Game Maker (8.1), 10,000 objects made the game stop working.
The current GMS 2 can handle objects better than the old version, I tested it in practice, so it is not currently a problem... (all based on my experience only)
 
If a game like Forager (3000+ sprites, iirc) or Hyperlight Drifter (200+ texture pages, iirc) or Swords of Ditto (no idea how many resources but the sprites are incredibly high quality and there are a LOT of them!) don't reach hardware limits and are made with older versions of GM then I think you'll be okay... Reaching the limits of hardware using GM is actually pretty hard, and probably down to poor texture page and audio group management rather than too many assets. ;)
Exactly. I've been building a game for a while now, and at one point my game had insane lag in rooms with over a 1000 instances.
It's easy to think at such a point, that it's Game Maker that's "limited", considering there are games like Hyrule Warriors and the likes, with 1000's and 1000's of enemies in full HD 3D quality.
However, it's not Game Maker to blame, it's the code I wrote.
I figured out quickly that having 1000's of instances run 100's of lines of code each, with some lines being collision checks and draw calls, caused the lag.
Good luck trying to send millions of lines of processor heavy calculations to your processor and graphics card, every. single. frame.
It won't work (no matter the engine).

I realized the engine doesn't matter all that much for 2D games. 3D is well... lot's of choice there too.
I concluded that:

If your code is inefficient, it doesnt matter if you are making a 2D game in Game Maker or a 3D game in the latest Unreal engine:
your game will suffer. Sure, some engines will handle certain things better and faster, and certain types of games are better programmed
in certain types of engine, but still.

Even the "best" engines depend on the skill and efficiency of the person coding.
The Forager example is such a good one. Also, Forager is probably nowhere near the limits of what Game Maker can handle.

I came to the realization that whenever I hit limits, it's probably not the limits of the engine,
but rather the limits of my skills. At which point I take time to learn new things and new ways of doing something more efficient.
 

TsukaYuriko

🌠
Forum Staff
Moderator
This is not very difficult, it's not that hard to leave heavy hardware in the Game Maker, a simple memory leak can crash the DirectX and make the game stop working, or load external files without stopping... In the old version of Game Maker (8.1), 10,000 objects made the game stop working.
The current GMS 2 can handle objects better than the old version, I tested it in practice, so it is not currently a problem... (all based on my experience only)
Driving into a tree is also not very difficult... does that mean the car isn't safe to use on the road? ;)
 

Ricardo

Member
One thing that bothers me a lot in the assets VS RAM topic in GMS2 is the fact that sprite_add doesn't work asynchronously for local assets. Am I the only one getting nuts because of that?
It'll be so amazing to be able to load things on the fly without blocking the main thread.
 

rIKmAN

Member
One thing that bothers me a lot in the assets VS RAM topic in GMS2 is the fact that sprite_add doesn't work asynchronously for local assets. Am I the only one getting nuts because of that?
It'll be so amazing to be able to load things on the fly without blocking the main thread.
kraifpatrik wrote a multithreading system called YYC-Overwrite, I haven't used it so I'm not sure if it allows loading assets on another thread or not, but might be worth you looking into it.
 

olr0493

Member
You can see resource usage when running the game in Debug Mode, so keeping an eye on those statistics and making sure the game doesn't reach 2GB memory usage during normal play (and if it does, fixing it) should be a good first step. You might also want to keep an eye on the VRAM usage / texture swap step time utility ratio, to keep track of whether you've found a good balance between smaller texture pages but not having too many texture pages (constant swapping degrades performance).
currently my game consumes 600 mb of ram and has a constant change of 40 to 50 texture swaps,what is the maximum texture swaps recommended for a pc game?
 

TsukaYuriko

🌠
Forum Staff
Moderator
Less than how many are required to make your game's FPS dip below the target.

As in, that depends entirely on your target device's hardware.
 

kburkhart84

Firehammer Games
currently my game consumes 600 mb of ram and has a constant change of 40 to 50 texture swaps,what is the maximum texture swaps recommended for a pc game?
Quick thought...do you mean swapping texture pages to draw with, or actually having to constantly upload that many texture pages to VRAM each frame. The first one is not nearly as bad as the second. The first one makes perfect sense actually, although very possibly could be optimized by using the texture page system properly. The second one, if you are having to send that many texture pages to VRAM each frame, I would have to guess you have something wrong, like you are flushing VRAM each frame or something.
 

olr0493

Member
Quick thought...do you mean swapping texture pages to draw with, or actually having to constantly upload that many texture pages to VRAM each frame. The first one is not nearly as bad as the second. The first one makes perfect sense actually, although very possibly could be optimized by using the texture page system properly. The second one, if you are having to send that many texture pages to VRAM each frame, I would have to guess you have something wrong, like you are flushing VRAM each frame or something.
s fotos-2.png
I mean the number swapping texture pages to draw
I have optimized the pages as best I could and in very extreme cases it reaches a maximum of 120/130
 

kburkhart84

Firehammer Games
View attachment 34353
I mean the number swapping texture pages to draw
I have optimized the pages as best I could and in very extreme cases it reaches a maximum of 120/130
That picture doesn't really tell me anything, no label on it, and I'm not all that familiar with the debugger to just know off the top of my head. But there is a difference between swapping textures that are already in VRAM for each draw, and actually having to change what textures are in VRAM by uploading new ones due to running out of VRAM. Do you know which one that '200' is referring to? If it is the first one, then you are probably fine(and I'm guessing that's the case seeing 247fps. If it were somehow the second one, you would need to make sure you have good enough min requirements to have enough VRAM.

About optimizing the texture pages...it isn't just about how many there are. It is about only having the ones you need. You can have texture groups for different things and only load what you need. One group for example would have anything you need at all times, the player, GUI graphics, things like that. Another group could have graphics for each level that are unique, which would include unique enemies if you have any. Then, between levels, you can flush the VRAM out and only load in what you need, saving VRAM usage and allowing you to work with less VRAM since you aren't loading in every single graphic texture page.
 
Top