I think I understand now. So, since I’m using my laptop’s default GPU without dedicated RAM, the task manager’s memory usage seems like a decent source of information. (My Game don’t use the dedicated nvidia GPU by default)
This brings me back to my first observations: x86 build has different memory management than x64 and my game has always used a lot of memory. I just wasn’t aware.
Some people have told me that 1GB of RAM isn’t a big deal. It seems crazy for someone like me who played on hadware with 512 kB…
Yes because textures indeed technically go into the RAM when running an Intel IGP…
No because the Intel driver actually virtualize fake GPU vRAM and textures are not visible in the process information (but in dedicated “vRAM” just like a discret GPU; and that amount is removed from your PC RAM pool).
1GB isn’t necessarily a big deal, it depends on what you’re doing with it (but out of the blue it sure sounds like a lot; what typically takes a lot of CPU RAM are sound effects).
Yes, but again. Who cares. Your RAM requirements, even with that extra gig will be waaaaay below the RAM modern computers have. Hell, even phones come with 8 gigs for some reason.
Considering only modern computers isn’t representative of the actual player diversity. The reality is that there is a silent majority of potato hardware out there, even more when considering mobiles. For instance, if your game uses 1GB of RAM instead of 512MB, you’d close yourself out of 67% of the mobile market (based on google’s own device database). That’s 2 thirds of possible players that will never be able to play your game.
It’s not because our twitter echo chamber makes us believe that everyone has an RTX 3080 that everyone does. Steam hardware survey says that people with a 3080 or better are less than 2% of all players. While 50%+ of players have hardware that is at best equivalent to a GT 1030.
I’m not saying that you must optimize your games (early optimization can be counter-productive, unless that makes you have fun), but that you should at least be aware of how many players you’re missing so that you can make your decisions.
I’d say that, as long as you’re prototyping or not considering a commercial release, it’s likely best to not care about that. But if you ever switch to targeting a commercial release, you might want to do a safe check and assess if it’s worth spending some time on refactoring stuff.
And to be fair, making memory optimized games with C# isn’t trivial. It’s a language that is by-design very prone to allocations without you knowing about it. Writing memory-efficient C# involves quite the language knowledge and having a coding style that is counter-intuitive (and would likely make any teacher or enterprise dev scream). So don’t blame yourself for that.
My 2 cents to optimize your games:
Try to only load textures/sounds that your current scene need, and unload assets when not required anymore.
Try to pool objects that you create dynamically during gameplay to avoid garbage (e.g. particles, projectiles, enemies…).
Try solving your design issues with something else than Texture2D.GetData().
Try to stop using plain text files (xml/json) for your game data.
Try to not use System.Linq.
Try to not use the new keyword on classes inside your Update/Draw loops.
I can relate ! My “best” GFX card is a GT 1030. I develop on a 7y old entry level laptop with a GTX 850M…
Thanks for those tips.
Try to only load textures/sounds that your current scene need, and unload assets when not required anymore.
==> I tried this and realised that I have way too many spritesheets. So I try to reduce the number but sticking under 2048 x 2048
Try to stop using plain text files (xml/json) for your game data.
==> My game 100% rely on json (asset atlas, game handbook, jobs, skills, etc…) Any tips ? Custom MGCB importer ?
Try to not use the new keyword on classes inside your Update/Draw loops.
==> NEW QUEST ADDED TO MY NEVERENDING TODO LIST !!
I have additional questions :
Many of my objects shares the same spritesheet, I’m tempterd to use static declaration. Is it a bad idea ?
I get each sprite rectangle from my atlas in the draw loop. Should I to this in the update loop instead ?
Then why the hell did you at any point even consider compressed sizes?
==> Not sure to understand. Looks like I’m wrong since the begining.
Or whether texture is square two resolution.
==> Power of 2 resolution is only for compressed texture ? Ok, check.
If you want raw data you get data.
==> Not sure to understand.
Also if you want to use lower bitdepth you definitely can, create textures with different surface format and encode/decode as you see fit.
==> Like in the MGCB ? Already tried, poor rendering. I more looking for a a way to optimise color pallet before converting to xnb to keep a good aspect. Maybe a graphic tool I can use with command line ?
I am traveling atm so I will address just an important part:
Look at surface formats when creating textures, there are formats that are lighter than 4 x 8 bits. If you create own texture loader then you can create textures with surfaces that will occupy less VRAM if it will satisfy your color pallet. For example it could go as low as 1 channel of 8 bits and then use look up table texture to colorize. Or you could use classic 4x8 but pack 2-4 different sheets into it (2 if you want alpha, more if alpha can be binary).
Personally I believe in current age it really aint much of an issue, but if you dont want to use GPU friendly compression and you want to take as little as VRAM as possible there are options mentioned above.
Still using 32bit colors.
Still building x64 exe
Now using async loading
Now using a static atlas
Common assets are loaded during start, basic memory usage is 230 MB RAM according to taskmanager.
On demande assets are loaded before each screen
On demande assets are disposed before or after a battle
Keeping an acceptable 370 to 450 MB ram usage instead of more than 1GB by only loaging used assets.
Subject is closed for me.
Many thanks for your help and precious advises.
