• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GMS2 IDE Resources with Blank Room (Game Memory)

kupo15

Member
This sounds like a really silly question but it came up on another topic and no one knew for sure so I thought it would be good to get its own topic. Sorry I've made numerous memory related threads! >.<

There are some clear differences between GMS 1.x and 2.
-1.x IDE is 32bit vs 2.x IDE is 64bit
-1.x had a "load textures on demand" in GGS 2.x does this automatically (t-ground default is exempt from this)

My question is simple, does merely using GMS2 and putting resources in the IDE automatically use up game RAM or do you only use RAM when you call resources?

Example: If I put 600GB of resources in the IDE (music,sprites not using the default tpage etc) and compile the game with only a blank room, can I accurately say that this game's minimum memory requirement is 512mb of ram?

I would hope this is the case otherwise simply using the program limits your game even with proper prefetching and flushing. That would be silly which is why this sounds like a silly question lol

**Side note: Was the 2GB a hard limit for 1.x because the IDE was 32bit but its not as hard in GMS2 because the IDE is 64bit?

sorry @Nocturne :p
 
M

maratae

Guest
Well, first of all, I believe music should be streamed from the disk, and not put on the memory.
Objects use ram when created, but I belive it gets freed when they're deleted. An empty object has a bunch of doubles from the built-in variables.
Other than that, apart from the stuff you can create and destroy like sound emitters and particle systems and such, I don't know how to have some sort of memory management with GMS.
I'd check the debugger for the ram usage.
Also I'm here to read the replies.
Cheers
 

kupo15

Member
Well, first of all, I believe music should be streamed from the disk, and not put on the memory.
Right, music but now sfx. Still though the question is "is simply putting sounds in the IDE cause ram usage in the game even if its an empty game or is ram used up when you call the music in the game?"

And I'm not talking about objects, ds, particles etc...that only uses memory when created. However, sprites and sounds are technically already created within the IDE, I want to know if they take up memory in the game simply by being in the IDE. Prefetching sprites I believe only copies sprite memory from RAM into VRAM which implies that sprites are already taking up memory even while not in use. Hopefully this isn't the case and prefetching sprites copies those tex pages into both RAM and VRAM and flushing sprites removes them from both RAM and VRAM.

@Mike

Can this be moved to the 2.0 Technical Discussion Boards @Nocturne? I think its more appropriate there.
 

Mike

nobody important
GMC Elder
Any audio that is streamed is not in memory, only sections (a buffer) of it is. Any that isn't streamed is completely contained in memory.
Sound effects tend to be WAV files and they reside in memory. only "streamed" sounds are done via a small buffer

Prefetching sprites simply uploads the texture onto the card so it's ready to use, otherwise the game may stall if there are a lot going up in a single game frame. Sprites are held on texture pages in PNGs format until needed (compressed) I believe.

This doesn't need to be moved, it's not that complicated - and it's useful for others to see.
 

kupo15

Member
Thanks for the reply

Any that isn't streamed is completely contained in memory.
So the only way for nonstreamed audio not in use to not waste memory is to externally load them via included files and not in the Sound Resource Tree?

Sprites are held on texture pages in PNGs format until needed (compressed) I believe.
So merely having sprites in the IDE when compiled automatically uses memory in the game even when its not used? But when its not used (flushed or on startup not in the default tgroup) its compressed so that it uses less memory?

Prefetching sprites simply uploads the texture onto the card so it's ready to use
Does this mean that say I have 600GB of sprites memory loaded in the Sprite Resource Tree and I compile a game with only a blank room, someone with only 512mb ram can't run the game even though none of that 600GBs are being used?
 
Last edited:

Mike

nobody important
GMC Elder
The WAD file is load into memory. If its 600Mbs....then that's in memory - this is basically your game.. Streamed/compressed audio is not in this wad. WAV files that are not streamed are in this wad.
 
M

maratae

Guest
The WAD file is load into memory. If its 600Mbs....then that's in memory - this is basically your game.. Streamed/compressed audio is not in this wad. WAV files that are not streamed are in this wad.
It's 600GB. Not Mb
I'm curious to see how that works out.
 

rIKmAN

Member
When did you ever see a game that was 600GB? Let alone a 2D one....?
I might be misunderstanding things, but I remember Russell in another thread confirming that everything isn't loaded into memory at startup with GMS2, in the way that it was in GMS1. It caused problems especially with large games on mobile.

Are you talking about something different or have I got my wires crossed?
 
M

maratae

Guest
Memory management is a thing in game development, (as well as in any other kind of development.) Nevertheless, programs like GMS plus modern machines make it easy not to care so much about it - but it is there.
But still, there's optimization. All this should be means to an end. Do you need your game to be 600GB to achieve what you need?
I know we're probably speaking hypothetically, but odds are GMS and whatever ram you have will do for most 2D games.
(Also, texture pages are loaded as needed.)
I'm confused about this conversation.
 

Mike

nobody important
GMC Elder
Actual Textures aren't created at startup the way the used to - as that burnt memory, but all source images are in memory.

And you can dynamically load images from included files if you need to, especially large backgrounds etc.

We do plan to allow multiple wads at some point - like level wads, to ease memory further.
 
M

maratae

Guest
Actual Textures aren't created at startup the way the used to - as that burnt memory, but all source images are in memory.

And you can dynamically load images from included files if you need to, especially large backgrounds etc.

We do plan to allow multiple wads at some point - like level wads, to ease memory further.
Weren't the texture pages for some platforms only? Like it didn't matter too much on desktop since they were all loaded on start?
(Also, out of curiosity: I'm working on a game for almost an year now.
It's using 1 texture page and burning about 14 whole MBs of ram. )
 

Mike

nobody important
GMC Elder
Yes, but it's now all consistent. They are all load on demand now, meaning if you have 600Mbs of textures, we don't try to create them all right at the start.
 

rIKmAN

Member
Actual Textures aren't created at startup the way the used to - as that burnt memory, but all source images are in memory.
So the texture pages are created / loaded as needed, but all the individual images from the IDE are loaded into memory at startup?
 

Mike

nobody important
GMC Elder
Image PNGs are part of the WAD. The wad is loaded into memory and kept there. When a texture is needed, the PNG is unpacked, and the texture created. When you flush them, the texture is disposed. The PNG remains in memory
 

rIKmAN

Member
Image PNGs are part of the WAD. The wad is loaded into memory and kept there. When a texture is needed, the PNG is unpacked, and the texture created. When you flush them, the texture is disposed. The PNG remains in memory
Ah I see, I've never really thought about too deeply as I've personally not had any issues with it yet.

I just assumed that during compile all the individual PNGs were arranged onto texture pages, then the individual PNGs discarded (not included in the build) and just the texture pages were included and loaded / called as needed.

Is it quicker to keep recreating the same textures over and over from the PNGs than just using the originally built texture?
I'm sure there is a reason but it seems an odd way to do it.
 

kupo15

Member
haha glad I made this topic as there seemed to be a bit of confusion! :p

It's 600GB. Not Mb
I'm curious to see how that works out.
When did you ever see a game that was 600GB? Let alone a 2D one....?
Never and I never intended on doing so haha I merely stated a ridiculous number like 600GB to make a point to come to the conclusion which is....(below)

The WAD file is load into memory. If its 600Mbs....then that's in memory - this is basically your game.. Streamed/compressed audio is not in this wad. WAV files that are not streamed are in this wad.
Image PNGs are part of the WAD. The wad is loaded into memory and kept there. When a texture is needed, the PNG is unpacked, and the texture created. When you flush them, the texture is disposed. The PNG remains in memory
Ok I see, this info confirms my suspicion. So when you compile the game, all the resources in the IDE are put in the wad file and do in fact take up memory inside the game even if there is no game (minus streamed music). Despite a game with an empty room using no resources, if there is 600GB of memory hosted by the IDE Resource Tree, the game will require 600GB of RAM to even run because of the wad file.

I guess this means currently the only way to truly manage and limit the amount of ram you use is purely through external loading via included files.

So in short:
If your game is large and requires 4GB of resources which is hosted in the IDE, its impossible for you to design a game in which the minimum requirement to run the game is 512mb purely because you chose to use the IDE to host your resources instead of included files.

We do plan to allow multiple wads at some point - like level wads, to ease memory further.
This sounds great and is exactly what I wanted to know, thank you!

Does this mean that when you add this multiple wad functionality, we will have true external loading capabilities via the IDE Resource tree that act like included files? This would essentially remove the need to use included files for external loading but in the meantime we have to use the included files to achieve true memory management

Do you know when this might get implemented? I would love to see this on the roadmap! If its going to be within the next 2 years then I can breathe easy and can safely continue having the IDE host my game resources. Otherwise, I'll have to build an external loading solution using included files.

Memory management is a thing in game development, (as well as in any other kind of development.) Nevertheless, programs like GMS plus modern machines make it easy not to care so much about it - but it is there.
But still, there's optimization. All this should be means to an end. Do you need your game to be 600GB to achieve what you need?
I know we're probably speaking hypothetically, but odds are GMS and whatever ram you have will do for most 2D games.
(Also, texture pages are loaded as needed.)
I'm confused about this conversation.
No I don't lol Was just making an extreme example. I'm pretty sure I will be needing more than 4GB of RAM for my entire game (this is just a guess) but I don't need more than 1GB of RAM at one time. With the current way GMS is set up, it would seem that if I want to reap the benefits and convenience of having the resource tree host my game resources, then my users would be required to have at least 4GB of free memory despite the game being designed to only require 1GB. I don't want to require users to need 6GB of memory to run my game if I only ever use at most 1GB at a time

This is a serious limitation for people like me who are trying to create big AAA quality games and make it accessible to lower end machines. Luckily I'm 2-3 years away from finishing it so hopefully the multiple wad functionality gets implemented before then.

On a related note, Hyper light drifter required 4GB of memory but only required 512mb of VRAM. If GMS supported multiple wad files, then I suspect that HLD would only require 512mb of both RAM and VRAM
 
M

maratae

Guest
This is a serious limitation for people like me who are trying to create big AAA quality games and make it accessible to lower end machines.
What? Why? Event HLD isn't AAA. What are you trying to pull here?
 

kupo15

Member
What? Why? Event HLD isn't AAA. What are you trying to pull here?
What are you talking about? I'm not trying to pull anything! I was giving HLD a compliment, I think its a pretty good AAA quality game built in GM. You can make a AAA quality game that works on low end machines if you are able to manage resources properly. HLD only needs 512mb of video ram to run which is fine for low end machines. My suspicion is that it also needs 4GB of memory because the entire game is stored in memory even though you only use up to 512mb at a time.

For Example, if HLD wanted to make their game twice as big that means their users would need 8GB memory for the game even though they still only require 512mb which would make it less accessible purely because they wanted to expand the scope of their game

upload_2017-11-4_16-21-12.png
 
Last edited:

rIKmAN

Member
What are you talking about? I'm not trying to pull anything! I was giving HLD a compliment, I think its a pretty good AAA quality game built in GM.
As good a game as HLD is (and while it may be considered to have better gameplay than some AAA games) - it's not a AAA title.

I think you are misunderstanding the definition of what a "AAA game" is.
An AAA game (usually pronounced "triple A game") is an informal classification used for video games with the highest development budgets and levels of promotion. AAA game development is associated with high economic risk, with high levels of sales required to obtain profitability.
 

kupo15

Member
As good a game as HLD is (and while it may be considered to have better gameplay than some AAA games) - it's not a AAA title.

I think you are misunderstanding the definition of what a "AAA game" is.
Fair enough, I didn't realize AAA needed to have the big budget behind it to be considered AAA. I guess I usually associate AAA as games that are made with really high quality and high production value, something that looks like a major developing company would make but it doesn't necessarily have to be big budget. The same way some people refer to indie games as a certain type of game.

I'll have to be aware of that next time to avoid confusion.
 

CMAllen

Member
What are you talking about? I'm not trying to pull anything! I was giving HLD a compliment, I think its a pretty good AAA quality game built in GM. You can make a AAA quality game that works on low end machines if you are able to manage resources properly. HLD only needs 512mb of video ram to run which is fine for low end machines. My suspicion is that it also needs 4GB of memory because the entire game is stored in memory even though you only use up to 512mb at a time.

For Example, if HLD wanted to make their game twice as big that means their users would need 8GB memory for the game even though they still only require 512mb which would make it less accessible purely because they wanted to expand the scope of their game

View attachment 14011
Yup. Because GM condenses all the assets the user creates into a single file, all of that data has to be loaded as a single file. And considering how minimalist HLD is (compared to your average AAA title, mind you), the fact that it needs 4gb of ram is indicative of the limitations of cramming all the game data together into a single file instead of loading and unloading assets as the game needs them. To put it into perspective, Mass Effect 3 had a minimum requirement of 1gb of ram, 2gb suggested, while the game itself was 15gb of total data (to the 2gb HLD requires). More to the point, they could have combined the entire ME trilogy into a single game, and while its disk space usage would probably be around 40gb, it would still only need 1-2gb of ram to run. If HLD were to triple in size and scope, it would need upwards of 12gb of ram to run. That limitation alone would kill its potential audience size. In fact, that 4gb ram requirement already puts some stringent limitations on what systems can run it.

You can make great, polished, fun games with GM. But proper memory and asset management is not something GM does well out of the box. Worse, the user has to bypass most of GM's normal systems and create the requisite code to do proper memory and asset management themselves, or buy an extension to do that for them.
 

kupo15

Member
Yup. Because GM condenses all the assets the user creates into a single file, all of that data has to be loaded as a single file. And considering how minimalist HLD is (compared to your average AAA title, mind you), the fact that it needs 4gb of ram is indicative of the limitations of cramming all the game data together into a single file instead of loading and unloading assets as the game needs them. To put it into perspective, Mass Effect 3 had a minimum requirement of 1gb of ram, 2gb suggested, while the game itself was 15gb of total data (to the 2gb HLD requires). More to the point, they could have combined the entire ME trilogy into a single game, and while its disk space usage would probably be around 40gb, it would still only need 1-2gb of ram to run. If HLD were to triple in size and scope, it would need upwards of 12gb of ram to run. That limitation alone would kill its potential audience size. In fact, that 4gb ram requirement already puts some stringent limitations on what systems can run it.

You can make great, polished, fun games with GM. But proper memory and asset management is not something GM does well out of the box. Worse, the user has to bypass most of GM's normal systems and create the requisite code to do proper memory and asset management themselves, or buy an extension to do that for them.
Yes exactly this! I couldn't have said it more eloquently and is exactly what I was trying to say. Thanks for making up for my lack of communication skills :D

I'm hopeful from what Mike said that when they have multiple wad loading we will be able to do the ME way of loading. Hopefully we get it within 2 years haha!

Thanks @Mike for taking the time to address the concerns in this thread!
 
Top