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:

[end of page 1] - https://classdev.net/page/thread/1JR6pG_ywd8r0Gyo/rock-climber-new-project

https://classdev.net/page/thread/1L2eo5_tYTgdCXpY/major-memory-leak-when-loading-projects-in-3d-rad

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.

Sounds like an awful workaround, but what can you expect from 3D Rad? Anyone want to modify 3D Rad by reverse en- *door breaks behind me*

yes , give me the source code
I would love to play with it in visual studio

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.

Have fun looking at "decompiled" code that is full of gibberish.

(The code in the picture is just "C pseudocode" generated by IDA. I still can't understand more than 30 % of it.

Nope, it's not a memory issue, it's simply a typo.
Now that it's been years and years MB and GB has been the norm for memory references .

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...

Ok MOM thanks for that update.......

no problem at all, precious daughter - next time don't forget what a kB is, i don't want to remind you again!

to sum up: current and previous ram sizes of last 2 decades are irrelevant to current file sizes, which are still commonly in kB, so the mighty kB is not obsolete just yet.

I did an experinment a couple days ago. Stability increases when you run the game from c:/  drive. Maybe its because my c drive is ssd , but maybe not.

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.

Okay.....cool. will look out for that as well.

Not only that, take into consideration asset streaming and load times.

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]

But in proper game engines, you'd use sprite sheets to reduce the number of draw calls as much as possible.

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.