[Dragon]

I've been experimenting with a couple of things, among them very fast firing weapons, large missile swarms, ships with a very high texture count, long-lasting animated effects and intensive Particle spews and noticed an odd behaviour regarding BmpMan and sound cache limits.
Namely, these caches don't seem to be purged untill you exit FS, carrying on between mission replays and different missions. So, even if one playthrought doesn't exceed any limits, after a couple of playthroughts or playing an intensive campaign, bitmaps become borked and a lot of sounds get really quiet. I would prefer that these caches were purged upon progressing to another mission (it shouldn't affect the loading time, since every time a bitmap or a sound is used, it seems to be loaded into a separate slot, no matter if it's already there or not).
That would also come in handy for mods which use a lot of different effects (of varying resolutions), so even if they don't cause that much of a preformance impact, they can overload BmpMan after playing a few missions.

[The E]

Nope. Purging and rebuilding sound and bitmap indices from scratch between missions makes absolutely no sense. While you could do it, it's better to try to fix the issues rather than abandoning it altogether.

Also, if you're using bad assets, problems are expected. Get better assets.

[Dragon]

I was Steve-O's ships, optimized versions definitely helped (that's where the problems first appeared though).
The problem is, after a long period of playing or a very, very intense mission, the BmpMan gets overloaded anyway.
Bad assets were only the fastest way to the problem, a large amount of varying effects can also cause issues, just not as quickly (for instance, halfway throught a medium lenght campaign).

Also, asset problems have nothing to do with sounds getting quiet, which can be caused by, for instance, combining a rapid firing gun with Chief's weapon linking code and a large gun bank, resulting in rates of fire nearing 100 rounds per second in full cycle mode (this wasn't a problem for the projectile limit, since the gun also had a very short lifetime and high muzzle velocity). This means almost 1 sound per frame (when fully linked, it gives 25 sounds per second, which didn't caused too much problems). Firing this gun like that for a while will get you sound problems quickly (although it's a stupid thing to do in most "real" situations).

For a more "earthly" situation when this becomes an issue, try using a new missile warning sound (posted on Mediavps forum a while ago) with some of the BP missions where you get swarmed by Nyxes with Tornadoes.
Of course, this means you're effectively dead, but sounds remain quiet untill you exit FS (including interface sounds).

If purging the cache is not a good idea, maybe the bitmaps and sound should be loaded only once, then get reused. This should completey nullify any sound problems, since there are ussualy only about 250 different sounds in game (interface and gameplay). Some mods can use a bit more than 300 (due to things like Bithin' Betty, or large variety of weapons).
I don't know if it's a good idea from a programming standpoint though.

[Zacam]

You mean like the Launcher flags that specifically cache sound and bitmaps between missions?

[The E]

No. He's talking about memory corruption with high engine loads.

Now, Dragon, we need a test case. We cannot just take an error report like the one you posted here on faith, as there could be any number of things going wrong that have nothing to do with the engine. So if you could just post that, it would be much appreciated. In the end, what you are talking about are symptoms, not the cause.

[Dragon]

I'll try to do it, but be advised, it isn't that easy to reproduce.
First, it doesn't always happen and requires specific conditions to happen. It sometimes takes a long time to happen.
I know an easy way to overload the sound cache (not to mention a really fun one, I love the sound of that gun ), but overloadig BmpMan cache is another thing.
Last time I got it was when playing WiH Beta with none of the models optimized, around the third playthrought of Aristeia textures got corrupt. It almost never happened on a single playthrought of a single mission, no matter how bad the assets were.
I'll try to give the autcannon some kind of really long effect for both impacts and bitmaps, maybe that would be enough.

[Iss Mneur]

Hard to reproduce is FSO's MO.  Its what we do.  Afterall, the engine works on most systems, most of the time, any bugs that we encounter (that we don't introduce ourselves ) are always edge cases.

I agree with The_E.  Dragon, the solutions that you are proposing, are exactly how the engine currently works.  When bmpman loads bmps it first searches for the name of the file to load.  SoundMan does something similar in that the manager doesn't search the cache, but engine loads the sounds by number and if the number is already loaded it just uses the one that already exists. Also, soundman uses a dynamic cache so there is no strict upper limit.

They both by default dump the contents of the caches on mission shutdown.  BmpMan has the -cache_bitmaps flag that disables this behaviour to speed loading times.  Soundman has -snd_preload to load all sounds at mission start-up rather than loading as needed.

I would also suggest that you try and cause this bug with a debug build, to see if the debug build provides more information.  Please post the debug log from any runs that exhibit your issues.

Regarding sounds, try reproducing the issue with -no_3d_sound as the issue may be that we are actually leaking OpenAL resources or overloading your sound card.

Other possible sources of the issues, could be caused be some part of the code not using the bmpman or the soundman. There could be bugs in the managers, especially as you approach the limits (edge conditions are always fun ).  For that matter it could be your sound or videocard driver that has the bug as well, which is why we need to have some reproduce-able method of causing both bugs.

I would like to reiterate, its not that we don't believe you, but the solutions that you propose to the symptoms that you list already exist.  They don't solve the root cause.  Remember Battuta's blood soaked bug hunting saga, and the root cause of that one.

[Dragon]

Thanks Iss Mneur.
Disabling -cache_bitmaps may get rid of the problems with textures getting borked after a lot of playthroughts, while sounds may indeed be the case of overloading my sound card (integrated into the motherboard, but actually pretty good) or something OpenAL related.
I'll try disabling -cache_bitmaps and check if it helps and for sounds, I'll run the autocannon throught the debug build and try -no_3d_ sound flag (I also think that it might be caused by some kind of volume optimization in the new sound code, since it seems to depend slightly on volume of the "overwhelming" sound and it doesn't disable other sounds, just quiets them down).
Also, if getting rid of -cache_bitmaps helps with texture corruption, this should go into the flag documentation.

[Dragon]

Tried getting rid of -cache_bitmaps, it indeed helped.
BTW, how many slots in BmpMan .ani and .eff files take?
I'm almost certain that .eff take up as many slots as there are frames, is that also the case for .ani, or do they take only one slot?

[The E]

Both ani and eff use as many slots as there are frames in the animation.

[Dragon]

Does interface (especially CBAnis and briefing icons) counts for the same BmpMan limit as the mission effects?
If so, that would mean that a lot of these 5000 slots get taken up by interfact and CBs, so in fact, mission would have about 4000, or even 3500 slots if there's a really fancy CB with a lot of different anis (I've seen CB anis with 100 or more frames) and a lenghty briefing.

[The E]

It would mean that, if the game was stupid.

What happens is that whenever the game changes modes (going from one screen to the next etc), all assets used in the previous mode get unloaded, unless the game is told not to do that. There's a hard limit of 4750 different bitmaps loaded at any given time, and it is really, really hard to hit a point where you run out of slots.

Unless, of course, you deliberately try to do something incredibly moronic.

[Dragon]

I'm now starting to suspect that my problems don't have anything to do with BmpMan or SoundMan limits.
I've recently got a problem with sounds when testing my latest addition to Mediavps.
Although basic tables were unchanged from retail, the mod adds an insane amount of particles (as in, two spewers on every Tempest), so this may not be a problem with engine limitations, but with my sound system and available memory (strangely, this ran comepletely smoothly, or at least I didn't noticed the slowdown).
I'll have to do some more testing, get proper debug logs (BTW, which options in debug.cfg I should enable to get logs with only the data that might be important?) and make a retail-based mod that would allow reproducing the sound issue with the least modifications possible.

[Iss Mneur]

I'm now starting to suspect that my problems don't have anything to do with BmpMan or SoundMan limits.
I've recently got a problem with sounds when testing my latest addition to Mediavps.
Although basic tables were unchanged from retail, the mod adds an insane amount of particles (as in, two spewers on every Tempest), so this may not be a problem with engine limitations, but with my sound system and available memory (strangely, this ran comepletely smoothly, or at least I didn't noticed the slowdown).
I'll have to do some more testing, get proper debug logs (BTW, which options in debug.cfg I should enable to get logs with only the data that might be important?) and make a retail-based mod that would allow reproducing the sound issue with the least modifications possible.

The biggest one would be -Parse the rest are not too big of deal.