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

GameGuru Master
Years of Service
User Offline
Joined: 20th Aug 2007
Location: Aus
Posted: 12th Apr 2019 18:10 Edited at: 12th Apr 2019 18:29
*Disclaimer: This Information is suggestion based only and designed for Novice and Pro users.


Game Guru being a 32 bit Application has a standard address space of 2gb Memory on 64bit windows.
Due to modern hardware, such as faster GPU's. Thanks to the help of Granada proved that more efficient speed
reduces Memory usage in game, saving around 0.4 Gb usage cost.
However, creating a game on a more efficient PC doesn't create the same experience for other End Users.
In some cases worse, not allowing head room for additional memory usage. Example: Loading the next level.
This means to be more playable, games need to be more streamlined, cut back in design, or built in an efficient manner.

Memory 4096 MB vs 4096 MB
Memory Speed 1752 MHz vs 1250 MHz
Memory Bus 128 Bit vs 512 Bit


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.

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. Unless GG is moved to 64bit, attention to your MapBank File size is important.
The lower the File size, the faster the load times. This also applies to Running Scripts and Detail in design on screen.

START MARKER: Placed / Assigned Gun, first on map is a suggestion to help eliminate sound delay.
DYNAMIC/SCRIPT: Group Physics and Script based Entities in your design structure.


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

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

* 50AI Stock Soldiers + Some static pillars and zones - Save Map = 43kb

* Test Game / Tab options, change Terrain type - Save Map = 774kb

* Multiple Test Game Terrain changes, adds additional data after selection - Save Map = 863Kb

* Load your selected Terrain Texture Theme on boot, via = Files/Terrainbank/style.txt (Folder name) - Save Map = 41Kb


After several tests pushing a save Map File past 200,000Kb would result in reaching engine memory address space.
This is however a guide, as mentioned above a more efficient PC map be able to handle single/multiple higher save file sizes.
As seen in video example, Stutter, fps reading changes, some AI non responsive, missing entities, such as guns.
(Possible reason for missing files on standalone builds) - Suggest a fresh Load of Game Guru before Standalone build.

Second example showing high frames, until too many functions are being processed, creating stalls until the next calculation.
This is not caused by Memory cap, or Gpu usage flooding into shared memory.
Pipeline stall creating wait states can have performance issues. Function call/ if conditions.
Functions need to execute, bouncing from physics to graphics create stalls waiting to handle the next function.
Based on the information, Individual objects are then spread all over memory, update code cycling physics, graphics and logic.


* System Memory @ 3.0Gb / Then @ 3.4Gb on Start screen (0.4Gb usage on load)

* Level 1: 50AI Stock Soldiers + static pillars and zones @ 3.5Gb Memory usage. (dumping dynamic data)

* Loading screen @ 3.7Gb Memory usage.

* Level 2: 50AI Stock Soldiers + static pillars, zones and terrain modify @ 3.5Gb Memory usage. (dumping dynamic data)

* Level 3: New Terrain texture change on 3rd Level via in Test Game / Tab change and save.
50AI Stock Soldiers + static pillars, zones and terrain modify @ 3.6Gb Memory usage. (dumping dynamic data)

* Second time running the Test game showed Memory going down @3.4Gb up to a cap of 3.6Gb.

* Replacing the 3rd Level with a New Map using Terrain Load in, Not change via Test game. Loaded the 3rd Level @ 3.5Gb

* Removing the Trigger Zones (dumping dynamic data) Stacked the Memory @ 0.1Gb per level load up to 3.8Gb

* Using standalonefreememorybetweenlevels=1 would spike memory on second play through @0.4Gb = 0.8Gb usage over 0.2Gb

* Keep an eye on Map Bank Save file size during your build process.
* EBE will also stack the Imported Texture data as Terrain, more changes more data saved to the file.
* Rename saves to suit adjustments made than may alter your outcome.
* Reduce where possible, this includes active scripts planned for your level.
* Consider End Users of your Game, if intended for public.
* Using Destroy() where possible, focus on dynamics and script usage.
* Anything you do in the Editor UI may be saved as data in your Map save file.

Below is the example shot , shown in the Newsletter. Due to minimal entity usage, Texture imports and adjustments
are saved in the Map file save as shown after all other media is removed and deleted.

https://forum.game-guru.com/thread/218003 - Optimization

Suggested reads:
https://forum.game-guru.com/thread/219206 - Lighting
https://forum.game-guru.com/thread/219642 - Fps change in game
https://forum.game-guru.com/thread/219648 - Thread on design
https://forum.game-guru.com/thread/219808 - Interesting thread example of Lua causing issues.


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: 2019-04-19 13:30:44
Your offset time is: 2019-04-19 13:30:44