Tutorials & Guides / [LOCKED] Mapbank Save file and Memory usage

Years of Service
User Offline
Joined: 20th Aug 2007
Posted: 12th Apr 2019 18:10 Edited at: 11th Jun 2019 01:15
*Disclaimer: Additional data can be saved in your mapbank / fpm based on changes the end user makes.

1. Plan your game/map ahead of time. Get an idea of scope, limits and Theme.
2. Test and prototype ideas and textures via test maps, never in a main level build.
3. Navigate to Files/terrainbank/style.txt and assign your terrain style here before starting a build.
Large scenes can be achieved with serious design structure and pre-planing, comparing to other engines based on 64bit have larger address space and then more content can be achieved.


* Loading Game Guru - Save Default Map, No change/edits = 41kb save file

* Test Game / Tab options, change Terrain type in test - Save Map = 774kb can bump your map file size up (keep this in mind)

* Importing Texture via UI (Ebe or Terrain)- Save Map = 53,490kb (using a 256kb Texture)


Login to view attachments
Len the man
Years of Service
User Offline
Joined: 12th Jun 2015
Posted: 12th Apr 2019 20:11 Edited at: 12th Apr 2019 20:12
Thanks for all the great work on this subject matter Defy...

I wish Lee would make GG 64 bit or maybe make an alternative version of GG that is 64 bit... He could simply call it "Game Guru Diamond Edition" or GG deluxe edition.
GameGuru Master
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 12th Apr 2019 20:41
I don’t see any linear relationship between map file size and memory consumption.

GG uses large address array allowing access to more than 2gb of ram even though a 32bit app.

Video ram is dependant on graphics card - often 2 gb.

The map bank file contains indexes to entities for the map and a terrain data file alongside a few other texture and data files sometimes needed but not always.

Load time is determined mostly by the number of entities on the map and the textures associated with those entities. Initial loads will take longer as AI obstacles are calculated but these are saved for future use.

Breaking the video ram cap of the graphics card will cause stuttering as the card moves textures in and out of memory. Textures that are used often (called a lot via draw calls) will be cached so keeping a critical eye on texture size is vital to maintaining smooth running. Make sure that entities that use the same texture are all sourced in the same entity folder as these won’t be loaded twice they will be reused once loaded.

Entities and associated structures and data including scripts need system ram. This can run upto 3gb without issue (assuming the pc has at least 8gb ram). Usually it is texture memory that is exhausted first.

Once/if FPS drops below 20-25 then animation and scripts will start to exhibit issues. If this happens reduce overheads that impact FPS (not caused by memory usage) such as post processing (depth or motion blur or disable completely by moving bloom slider to zero), shadows, light rays.

Once FPS recovers, animation and scripts will too.

If most of the textures (for entities) are used in all levels then don’t set standalonefreememory.. to 1. Only use this if levels use mostly different textures.

There is a very slow memory leak that does consume a few kb of ram sporadically but often during game play. I haven’t found the cause of this yet.

Just relaying my testing results


Login to post a reply

Server time is: 2021-05-09 05:30:52
Your offset time is: 2021-05-09 05:30:52