Re: (WIP) Finisterrae mod
Posted: Tue Sep 29, 2015 12:18 am
The first warning sign that your mod+saving is using too much memory is if you save in the dungeon and it breaks the keyboard controls. You'll know this when you see it. After that comes texture corruption and straight-up crashes.
The biggest concerns for memory usage in-game are textures (because images are big), followed by models (also big but textures generally use a far greater proportion of memory), followed by sounds, followed by everything else. The memory usage from objects and components simply existing becomes significant in large enough dungeons, too (it's part of the reason Eye of the Atlantis still doesn't work, even now that it uses about the same amount of texture data as Isle of Nex).
The concerns for memory usage when saving are objects without minimalSaveState and their components, followed by objects with minimalSaveState. Components on objects without minimalSaveState have everything about their state saved; name, class, offset, rotation, connectors, whether it's enabled, all the other component properties, etc. And the object without minimalSaveState itself also has all its state information saved; world position, world rotation, etc.
Objects with minimalSaveState only have their name, id, x, y, facing, elevation, level saved, and are simply respawned at that position according to their definition when the game is loaded. It adds up when you have tens of thousands of them (it's what the object merger is for, although you should avoid using that if you possibly can), but they use overwhelmingly less space than full save state objects. Of course, this also means that you should never make any changes to minimalSaveState objects or their components (INCLUDING ENABLING/DISABLING THEM IN THE EDITOR) outside of GameObject:setPosition() (but NOT GameObject:setWorldPosition()), GameObject:destroy(), and GameObject:destroyDelayed(), because any changes other than completely destroying the object or changing its x/y/facing/elevation/level will completely disappear as soon as the game is saved and reloaded, which is not something you want.
The biggest concerns for memory usage in-game are textures (because images are big), followed by models (also big but textures generally use a far greater proportion of memory), followed by sounds, followed by everything else. The memory usage from objects and components simply existing becomes significant in large enough dungeons, too (it's part of the reason Eye of the Atlantis still doesn't work, even now that it uses about the same amount of texture data as Isle of Nex).
The concerns for memory usage when saving are objects without minimalSaveState and their components, followed by objects with minimalSaveState. Components on objects without minimalSaveState have everything about their state saved; name, class, offset, rotation, connectors, whether it's enabled, all the other component properties, etc. And the object without minimalSaveState itself also has all its state information saved; world position, world rotation, etc.
Objects with minimalSaveState only have their name, id, x, y, facing, elevation, level saved, and are simply respawned at that position according to their definition when the game is loaded. It adds up when you have tens of thousands of them (it's what the object merger is for, although you should avoid using that if you possibly can), but they use overwhelmingly less space than full save state objects. Of course, this also means that you should never make any changes to minimalSaveState objects or their components (INCLUDING ENABLING/DISABLING THEM IN THE EDITOR) outside of GameObject:setPosition() (but NOT GameObject:setWorldPosition()), GameObject:destroy(), and GameObject:destroyDelayed(), because any changes other than completely destroying the object or changing its x/y/facing/elevation/level will completely disappear as soon as the game is saved and reloaded, which is not something you want.
only way this would affect it is if saving actually had a memory leak, which i've tested and am pretty sure it doesn't. you can save 100000000 times in a row and it won't claim any more memory than saving once will. (of course, if there's not enough memory available to save safely, then getting a crash or memory corruption is more likely the more times you try saving, but that's just because you're doing more trials, not because successive saves are more likely to cause problems).Azel wrote:how often the player clicks that Save button
). I have 28 levels, but some are rather "lights" (few assets) and others have multiples elevations, so I doubt that the number of levels can be really significant in this mod.
