• 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!
  • 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.

Windows What are the exact limits on system memory? (compiled game)

badwrong

Member
I've been trying to search for this answer, but mostly get answers on older versions of GM. Most of those answers say less than 2 gigs of system memory and if you need more resources then stuff like sprite_load() can be used.
Is this still all true to GMS2? Say I have 5 gigs of sprites, but of course only need to load maybe 1gig at a time into VRAM with prefetch commands, will GMS2 actually deal with what is in system RAM to allow for this? Or is the only answer still sprite_load()? Given GMS2 produces a 32bit program, it has limits sure... at a single given time. Plus there is "large address aware", which I can't find out if it is being used or not.

I also realize sprite_load() makes new texture pages for each sprite, so to actually use it efficiently I would have to pack sprites onto texture pages and define the UV's, etc. Which ya know, GM does for me at compile time... so I'm hoping there is a better method if those sorta memory limits still exist?
 
S

Sybok

Guest
The ~2GB limit still applies for Windows builds, because of it still being a 32 bit application.

Generally the other operating systems should be ok now, because I believe they are all now 64 bit builds that GMS2 generates.

So it's probably just Windows desktop builds that are still stuck in the dark ages.
 

badwrong

Member
Dang. So its not smart enough to simply go, "hey we only need 1 gig of memory right now, lets use that" Instead it has to load 100% of the sprites on disk?

I'm not a fan of having to pack a texture page, use sprite_add, define the UV's, etc. Cause that's one of the most important things GM already does, and it seems like the only solution is to essentially replicate that if you wanna have a large install size. Like say I have a cutscene for the game's ending, and it uses a large amount of sprites... that data is only going to be loaded like 1% of the time the player will ever be using the game. Something seems off about that.

Unless there is a way to tell GM "hey don't load these texture pages right now". Maybe I'm dumb, but that sounds very simple.

Ya its stuck in the dark ages... but even as a 32bit application, the option to just not load every damn thing at once into system memory sounds like a better option.
 

Ricardo

Member
GMS2 is good for a lot of things, except projects which requires large amounts of assets (even if the project itself isn't technically advanced).
The engine won't load the texture pages into VRAM until any of its sprites are needed (or prefetched), but they'll be preloaded into RAM regardless, meaning sprite_add is still the only way of dealing with the issue as far as I'm aware.
There's an asset in the Marketplace that uses sprite_add but handle its own texture pages to save resources. That's probably the closest you'll get from solving the dilemma - although it is still not ideal.
 
Top