just a thought... use C++ for your scripting allocations/deallocation and playing sound files. I have not tried it but I bet you could use ent_morph to change a sound to a small sprite etc. that could make it use less memory.

Well, JCL eventually posted a very vague response in the "Ask Conitec" forum. I'm afraid he just doesn't want to draw much attention to what a serious problem this is. So, I've done my own tests and here's what I've found--none of it is very encouraging:

There are two problems with 3DGS's 9lack of) memory management: sound and bitmaps. We really need to be able to control when these two elements are loaded into and removed from system RAM. At the very least, Conitec should make very clear that any game made with 3DGS needs to be VERY light on soundfx and bitmaps.

Sound
ANY time you create a "sound," sound music1 = <music1.ogg>; it is allocated to system RAM. Then when you actually play it, it's loaded in AGAIN--into acknex.exe. You can never clear the FIRST loading of the sound file, but you can clear the SECOND loading of it by playing another small sound file. Ent_morph doesn't seem to work for that.

You can work around this problem by using media_play to stream your music files off the hard-drive. This gives you a performance lag, and it also makes your install very messy because media_play isn't smart enough to look in a folder, let alone a resource.

However, media_play isn't a very effective solution for soundFX, so if you want to give a bunch of unique sounds to a bunch of different charcters across numerous levels, you're going to use a TON of RAM.

Bitmaps
ANY time you declare a bitmap, bmap Picture1 = <picture1.pcx>;, it is loaded into system RAM and will NEVER come out. You can purge it out of the video memory, but it's going to hog up system memory until you exit. This means that if you use a bunch of cool panels ANYWHERE in the game for any reason, you're going to have to pay for them, in system RAM, forever, always, no matter what. It's also loaded in to system RAM a SECOND time when it's displayed. Bmap_purge is an effective tool for getting the SECOND copy of the bmap out of RAM.

At least this is what my own tests have shown. I REALLY REALLY hope that someone will tell me I'm wrong.

Here's a little more data about my tests:
Level: Empty room, default texture, one light, and a Position
acknex.exe RAM usage: 11MB Total RAM usage: 55MB

Add a huge .ogg file (4.3 minutes)
acknex.exe RAM usage: 55MB Total RAM usage: 104MB

Play the .ogg file
acknex.exe RAM usage: 104MB Total RAM usage: 163?MB

OR--instead of the .ogg file, add one huge texture (2048x2048)
acknex.exe RAM usage: 23MB Total RAM usage: 68MB
(.pcx used about 4MB less ram than 24-bit .tga)

Quote:

---

I'm afraid he just doesn't want to draw much attention to what a serious problem this is.

---

id have to assume you correct on this although i shouldnt assume

i was afraid what i heard at garage games to be true
and reason why this engine is not well suited for larger project and or games
a huge whole in gs discovered indeed

i like play ut2004 mod rpg/invasion which has 90+ maps and more content then you can shake a stick at but after every map change so does the memory on the task list

if gs is really hadling mem in this way larger games just wont be possible because
it would load every piece of content from all the 90 maps and never free it
until exit
ut2004 rpg/invasions would probably need 4gig ram usin gs, lol


it should only load content from the loaded map then free that mem when exiting that map and loadin the new lvl, this would be ok

Quote:

---

Quote:
--------------------------------------------------------------------------------

I'm afraid he just doesn't want to draw much attention to what a serious problem this is.


--------------------------------------------------------------------------------


id have to assume you correct on this although i shouldnt assume

---

I shouldn't assume either, and I hope I'm wrong and there's a great solution. That's just what I'm AFRAID of

Quote:

---

it should only load content from the loaded map then free that mem when exiting that map and loadin the new lvl, this would be ok

---

Actually, that's exactly what it tries to do. That is, it clears out whatever's in the Level.wmb file. So theoretically you could move from one gigantic level to the next with no problems.

However, there are nearly always substantial files that are extraneous to the Level.wmb. For instance, all the "sound" fx and music files and all the "bmap" files--from every level in the entire game. Additionally, from my own tests, there are some substantial problems with even clearing out the Level.wmb from RAM. However, since there are really no documentation or diagnostic tools whatsoever for tracking down what's sucking up all the system RAM, it's really hard to know what's still stuck in there.