SYMPTOM: load to/from a main menu and a game level increases ram use until you run out of ram, at which stage it crashes. good news is leaks do not increase noticeably or at all during play on same level whether for 1min or 1hr.
TO TEST MEMORY LIMITS: use win7 task manager to monitor commit or peak working set [or ProcessHacker=Pvt. mem or peak working set] while your game runs windowed. from my tests, a 64mb game leaks 20mb each load, and a 230mb game leaks 50mb.
TO FIX: athanatos's idea of 'using iObjectRefresh to load maps from other levels' will work, but for levels with different paths/weapons/waypoints it will get messy and increase load times with too many unused objects, so here's my 2 fixes:
1. [EASY] - add a counter to exitfades, when the amount of loads reaches a limit [say 30 x 50mb loads=1.5gb added to 230mb] warn users to restart the game and force the game to exitfade to windows, which will clear all the ram added. you can also increase 3drad 32bit 2gb limit on 64bit OS to 4gb with the well known '4gb patch' from https://ntcore.com/?page_id=371
2. [ADVANCED] bypass 3drad's level load system completely - there will be NO major ram leaks at all with this method!!!
[edit: deleted overblown and obsolete part, see 2nd post for updated method, but the below steps are still usefull]
-to stop settings dialog each level load you can either: a. compile as maximized [borderless window] b. for fullscreen compiles use iSettingsDialogDisable to disable it when exit main menu to any level, and enable it when exiting the game.
....this may seem like a lot of work, but it's far quicker/easier to implement then learning a new engine/language.
CREDITS: a big thanks to kulu for making us aware of this issue, and to athanatos for keeping me on my toes [i don't accept random statements until i see the hard numbers/stats for myself] more info on this issue is available on their threads:
so i finally got around to implementing the rushed method 2 above, but the solution was WAY simpler [no multi exe/.rup BS needed]:
CMD launching an exe will wait for it to exit before running the next line, this made the game restart over and over. after trying to workaround this, i realized it was better to work with it, and only needed 3 lines of code [plus 2 lines in 3drad]:
for the .bat file: :restart untitled.exe IF EXIST reload.txt (goto restart) ELSE (exit)
in 3drad; -rename/copy reload.txt when going from a level to the menu -delete it before exiting the game
now you have ZERO ram leaks between level loads, only the menu and current level will use ram! and this is not all that can be done with CMD...
Ahhhh the good o'l DOS command prompt to the rescue.
Many years ago, when computers ran from the DOS prompt, some games required using a .bat file to load them so some drivers could be loaded into extended memory, to allow more of the base 640MB to be used for the game.
Many years ago, when computers ran from the DOS prompt, some games required using a .bat file to allow more of the base 640MB to be used
your memory of memory is terrible! 640mb did not even exist in geek's dreams back then - it was only 1/1000th of that: 640kB.
@NicusorN5 if 3 lines of CMD code is so 'awful' to you, i'm sure the same reloading could be done making a GUI based launcher, but that would likely be 100's of lines of code for the same result, just in a prettier format.
still, you should not forget what a kB is, if you make a file and it is in bytes/kB/Mb/Gb or even terabytes, it's helpful to know the differences, as many simple files such as text configs still use kB, and if you had a config file that was in Mb, then you should worry, as it wil take an age to read/write. it's actually a feat they even made games back then in kB - try that today in 3drad and see how you go...
@thelurker , still, you should not forget what a kB is, if you make a file and it is in bytes/kB/Mb/Gb or even terabytes, it's helpful to know the differences, as many simple files such as text configs still use kB, and if you had a config file that was in Mb, then you should worry, as it wil take an age to read/write. it's actually a feat they even made games back then in kB - try that today in 3drad and see how you go...
yeh, if you run out of ram, stuff is run from the hdd instead, so while ssd may be faster than hdd, it will not be able to stream the game assets at the speeds required, and is still way slower than ram, so it's best not to let your game run out of ram in the 1st place, which was the whole point of this thread.
as with any game engine, load times increase with many small files, so 1024 x 10kb files = 10mb [such as multiple text objects] will take longer than bigger pre-rendered text sprites of 16 x 1mb files = 16mb. [see - this is why we must remember what a kb is :-P]
what's to stop that in 3drad? i use 32 frame sprite sheets for anims like explosions/billboards, etc. can also use texture atlases if you don't need to normal map them, if you do, i just combine 2 textures in to one and flip them while texture painting the model, if it's not tiled you can even combine 4 to 1, or more if you don't mind manually aligning the middle ones.