kupo15
Member
EDIT: Through the responses I learned there are other ways to create texture pages and do what I'm looking for so my main ask at the bottom has been resolved. Now just need to find one that integrates well with GM. This post now serves as a great resource of info regarding memory and other info found in the comments.
Hey everyone, I know I've posted quite a bit about this topic before and have gotten some answers regarding it. I wanted to post again with some new inquiries of my thoughts on this topic because this is probably the most important thing to creating big games.
Especially since 1.4 is being phased out of support next year I think understanding this topic is very important for those big projects like mine that are still in 1.4 and are hesitant to move over to Studio 2 bc of its size. I have a big question to YOYO games at the very end of this!
Sorry for the post being so large, I think its also a great comprehensive guide to memory in GM for those that don't know how it works.
Here is my understanding of it and I'm interested in feedback to my thoughts, if I'm wrong or not.
Overview
Memory
Big games require a lot of assets which take up memory and if you load everything at startup, you will run out of memory and your game won't work. This is why there are loading screens so that you swap in and out of memory the assets you need at one time.
Great! That means I can put as much stuff into GM and swap out what I need, right? Not exactly!
VRAM vs RAM
There are two things that make up memory, Vram and Ram. VRAM is the amount of memory your Graphics Card is using and RAM is the amount of memory the program/engine is using. They both have their own limits of how much memory/assets they can hold at one time!
Ex. If your program can hold 2GB of memory at one time but your Graphics Card can only hold 1GB of memory, that means your game can only use 1GB of memory at one time for your card. Other users Graphics Cards may be able to hold 2GB of memory so for them, they can run games that use up to 2GB of memory at one time.
So all I need to do is have a Graphics Card that holds 8GB and I can use more memory at one time, right!? No you can't for two reasons:
-Not everyone has cards that amazing so you are limiting your audience of your game to those people
-If your game engine can't hold 8GB of memory, then you can't fully use the 8GB your card can handle
GM:S Memory Limit
The memory limit for GM:S is about 1.7GB so you can't have more than this in your game at one time otherwise it will crash. This is a hard limit because GM:S is a 32bit program. If it were 64bit that number would be higher.
Not only can you not use more than 1.7GB at one time in the game, you can't have more than 1.7GB in your entire game engine period! This means that any resource you add directly into the resource tree will be eating up memory from the 1.7GB of game engine RAM. And no, you can't uncheck "load textures at start" to get around this. That only prevents your VRAM from being loaded up on startup
Man, I need more than 1.7GB for my game...I'm doomed because GM is only a 32bit program!
Good news is no you aren't! There are actually TWO loading mechanics GM has for memory management!
Here is a diagram showing the flow of memory limits
One is VRAM loading which was mentioned previous. VRAM is what gets drawn to your screen because its faster than normal RAM. GM pulls the assets you need to display from the game engine ram into the VRAM and uses that to draw to the screen.
The second type is External Loading into the Game Engine via sprite_add, sound_add etc! Here is where you can overcome GM:S's 1.7GB storage limit. Now the size of your HD is the limit to how much resources you can have in your game. In consoles, this limit was found in the size of the game disc.
However! Even though you can have 100s of GB of resources in your game (obviously not recommended) you still can only design your game around GM's 1.7GB RAM limit. The hard drive is just a big bin to store all unused resources until you want to pull them into Game Maker's Engine RAM.
So I don't need GM to be 64bit to make big games?
No not really. All you need to do is make sure no section of your game needs more than 1.7GB of memory at one time then you can make it as big as you want! (or as big as as much HD space you want to require) The 32bit program is only a limitation for you if you require more than 1.7GB to be used at one time which if you manage your resources well most likely won't really be problematic.
But wait, I thought we aren't supposed to use sprite_add anymore because they are bad and obsolete?
That is somewhat true, they are obsolete and are far inferior to putting your sprites directly into the IDE because you lose out on GM's amazing texture packing tool which is designed to use as little system memory as possible with sprites. Sprite_add also creates one texture page for each sprite (and subimage?) you add. So instead of having a small number of texture pages GM can pull things from, it will have to swap between the 100s of pages created using the sprite_add function.
Tips and Tricks
But that doesn't mean external loading is inherently bad and can still be used!
Audio
As far as I know, audio external loading doesn't suffer like sprite external loading does. If you put ALL your sound files directly into the IDE, all of those files will take away from the 1.7GB system limit. But chances are you don't need every sound file ready at all times so lots of sound files are unnecessarily using up valuable ram. Using sound_add functions helps to free up this space
Textures
If your resources are very high quality and big, chances are texture pages optimization aren't really going to help you minimize page swaps anyway so GM's built in texture packing isn't really that useful for you in this regard. Minimizing these swaps is important to game performance but it really is much more important for mobile games.
While its important to minimize swaps, desktops can handle more swaps without a performance hit. Texture page optimization will be important for reducing load times however.
Smart Texture external Loading
Backgrounds are the easiest texture resources to externally load while missing out on the built in texture packing tool. Menu backgrounds for example fill the whole screen and don't need to be in system ram all the time. They are perfect for the sprite_add functions because its also not that important for them to be packed tightly with game sprites and its ok that they can have their own texture page.
Game sprites (character animations, gfx etc..) is the only really tricky issue and is something that GM doesn't help you with if you want to go external with them. You can replicate the benefits of GM's built in texture packing tool with the sprite_add function but it would be a real pain. To do this you would need to:
-Load all your sprites directly into the IDE
-Go to the GGS and "preview" your texture pages
-This creates all the texture pages the game uses and you can use those massive cluster images as your sprite_add files
-The trick then is to figure out how to use sprite_draw_part on that massive jumbled image to draw the sprites you need for your animations
This is what GM does behind the scenes when your sprites are directly in the IDE. This is the updated sprite_add function that GM desperately needs! A sprite_add function that behaves exactly how it does when sprites are put directly into the IDE.
With this function the only true limitation will be your HD space and the 1.7GB of use at one time and memory limit worries will be almost non-existent. I believe this improved external loading is planned for GMS2 at some point which is great!
MY PLEA TO YOYO GAMES
Will this be coming to the GMS1 before support for 1.4 is discontinued next year? If it will not, is it possible that you can at least improve the Texture Preview feature in the GGS? In addition to creating the texture pages for us to use, can it also create a text file that includes all the data we need to easily reference the subimages in these texture pages we need for draw_sprite_part? GM must already do this under the hood and having access to it would make creating our own true external loading system much easier
Thanks!
Hey everyone, I know I've posted quite a bit about this topic before and have gotten some answers regarding it. I wanted to post again with some new inquiries of my thoughts on this topic because this is probably the most important thing to creating big games.
Especially since 1.4 is being phased out of support next year I think understanding this topic is very important for those big projects like mine that are still in 1.4 and are hesitant to move over to Studio 2 bc of its size. I have a big question to YOYO games at the very end of this!
Sorry for the post being so large, I think its also a great comprehensive guide to memory in GM for those that don't know how it works.
Here is my understanding of it and I'm interested in feedback to my thoughts, if I'm wrong or not.
Overview
Memory
Big games require a lot of assets which take up memory and if you load everything at startup, you will run out of memory and your game won't work. This is why there are loading screens so that you swap in and out of memory the assets you need at one time.
Great! That means I can put as much stuff into GM and swap out what I need, right? Not exactly!
VRAM vs RAM
There are two things that make up memory, Vram and Ram. VRAM is the amount of memory your Graphics Card is using and RAM is the amount of memory the program/engine is using. They both have their own limits of how much memory/assets they can hold at one time!
Ex. If your program can hold 2GB of memory at one time but your Graphics Card can only hold 1GB of memory, that means your game can only use 1GB of memory at one time for your card. Other users Graphics Cards may be able to hold 2GB of memory so for them, they can run games that use up to 2GB of memory at one time.
So all I need to do is have a Graphics Card that holds 8GB and I can use more memory at one time, right!? No you can't for two reasons:
-Not everyone has cards that amazing so you are limiting your audience of your game to those people
-If your game engine can't hold 8GB of memory, then you can't fully use the 8GB your card can handle
GM:S Memory Limit
The memory limit for GM:S is about 1.7GB so you can't have more than this in your game at one time otherwise it will crash. This is a hard limit because GM:S is a 32bit program. If it were 64bit that number would be higher.
Not only can you not use more than 1.7GB at one time in the game, you can't have more than 1.7GB in your entire game engine period! This means that any resource you add directly into the resource tree will be eating up memory from the 1.7GB of game engine RAM. And no, you can't uncheck "load textures at start" to get around this. That only prevents your VRAM from being loaded up on startup
Man, I need more than 1.7GB for my game...I'm doomed because GM is only a 32bit program!
Good news is no you aren't! There are actually TWO loading mechanics GM has for memory management!
Here is a diagram showing the flow of memory limits
One is VRAM loading which was mentioned previous. VRAM is what gets drawn to your screen because its faster than normal RAM. GM pulls the assets you need to display from the game engine ram into the VRAM and uses that to draw to the screen.
The second type is External Loading into the Game Engine via sprite_add, sound_add etc! Here is where you can overcome GM:S's 1.7GB storage limit. Now the size of your HD is the limit to how much resources you can have in your game. In consoles, this limit was found in the size of the game disc.
However! Even though you can have 100s of GB of resources in your game (obviously not recommended) you still can only design your game around GM's 1.7GB RAM limit. The hard drive is just a big bin to store all unused resources until you want to pull them into Game Maker's Engine RAM.
So I don't need GM to be 64bit to make big games?
No not really. All you need to do is make sure no section of your game needs more than 1.7GB of memory at one time then you can make it as big as you want! (or as big as as much HD space you want to require) The 32bit program is only a limitation for you if you require more than 1.7GB to be used at one time which if you manage your resources well most likely won't really be problematic.
But wait, I thought we aren't supposed to use sprite_add anymore because they are bad and obsolete?
That is somewhat true, they are obsolete and are far inferior to putting your sprites directly into the IDE because you lose out on GM's amazing texture packing tool which is designed to use as little system memory as possible with sprites. Sprite_add also creates one texture page for each sprite (and subimage?) you add. So instead of having a small number of texture pages GM can pull things from, it will have to swap between the 100s of pages created using the sprite_add function.
Tips and Tricks
But that doesn't mean external loading is inherently bad and can still be used!
Audio
As far as I know, audio external loading doesn't suffer like sprite external loading does. If you put ALL your sound files directly into the IDE, all of those files will take away from the 1.7GB system limit. But chances are you don't need every sound file ready at all times so lots of sound files are unnecessarily using up valuable ram. Using sound_add functions helps to free up this space
Textures
If your resources are very high quality and big, chances are texture pages optimization aren't really going to help you minimize page swaps anyway so GM's built in texture packing isn't really that useful for you in this regard. Minimizing these swaps is important to game performance but it really is much more important for mobile games.
While its important to minimize swaps, desktops can handle more swaps without a performance hit. Texture page optimization will be important for reducing load times however.
Smart Texture external Loading
Backgrounds are the easiest texture resources to externally load while missing out on the built in texture packing tool. Menu backgrounds for example fill the whole screen and don't need to be in system ram all the time. They are perfect for the sprite_add functions because its also not that important for them to be packed tightly with game sprites and its ok that they can have their own texture page.
Game sprites (character animations, gfx etc..) is the only really tricky issue and is something that GM doesn't help you with if you want to go external with them. You can replicate the benefits of GM's built in texture packing tool with the sprite_add function but it would be a real pain. To do this you would need to:
-Load all your sprites directly into the IDE
-Go to the GGS and "preview" your texture pages
-This creates all the texture pages the game uses and you can use those massive cluster images as your sprite_add files
-The trick then is to figure out how to use sprite_draw_part on that massive jumbled image to draw the sprites you need for your animations
This is what GM does behind the scenes when your sprites are directly in the IDE. This is the updated sprite_add function that GM desperately needs! A sprite_add function that behaves exactly how it does when sprites are put directly into the IDE.
With this function the only true limitation will be your HD space and the 1.7GB of use at one time and memory limit worries will be almost non-existent. I believe this improved external loading is planned for GMS2 at some point which is great!
MY PLEA TO YOYO GAMES
Will this be coming to the GMS1 before support for 1.4 is discontinued next year? If it will not, is it possible that you can at least improve the Texture Preview feature in the GGS? In addition to creating the texture pages for us to use, can it also create a text file that includes all the data we need to easily reference the subimages in these texture pages we need for draw_sprite_part? GM must already do this under the hood and having access to it would make creating our own true external loading system much easier
Thanks!
Last edited: