Exult Forum

First of all, a big thank you to everyone who put in a lot of hard work in re-creating this fantastic game!

I have been playing through SI+SS using the 1.4 22/06 snapshot and apart from occasional seemingly random crashes, I have had no problems. Unfortunately, the game has now begun to exhibit predictable crashes which is causing real problems. There are now areas of the game where I just cannot go without an immediate crash to desktop. The stones puzzle room in the Temple of Logic, the Inn near Monitor, the Monitor town hall; all cause an immediate CTD. I have just retrieved Gwenno´s body and have returned to the mainland to find rampaging goblins.

There is no useful message in stdout or stderr. I tried the 22/07 snapshot, but the same problem exists. Is my saved game stuffed? Is there anything else I can try?

Thought I better give a better explanation of my progress. The Banes have just been freed and have destroyed the three cities.

It seems that nearly everywhere I go now the game will crash. If I reload, it will always crash in the same place again... Damn.

Could you submit a bug report with your savegame, with a brief description of what to do to get a crash? I'm hoping we can use that to find and fix the problem.

Thanks for the response. How do I submit a bug report; via SourceForge? Also, which files are required? Do you need the contents of the GAMEDATA directory, or only the *.sav files?

Um, so I read the sticky... Duh. The question about which files are required still stands though

only the sav file. Thanks

FYI, the snapshot from 2007-07-23 00:38 seems to have fixed the problem! Kudos people

I haven't had a single random crash since this point release either. No need to save every two minutes now...

I must be unlucky. It tends to crash a lot for me when around water. It freeze for a couple seconds, windows says it's virtual memory is low, then it crashes.

However, this is not from regular play of SI, this is when the terrain has been modified by Studio so that could play a big part of it.

Likewise. There appears to be a memory leak or something. If I watch task manager (Windows Vista, dual core Opteron, 2GB) and I go near water, the game rushes from around it's normal 600MB memory to 1.6GB in about 30 seconds.

The game usually starts to hang, and then eventually it will just poof or I have to end task it.

This is quite possibly related to a problem I've just noticed since starting a game with the latest snapshot. Coastline hogs the processor something fierce. The longer you stay near it the worse it gets. Pretty much ruins ocean travel. I assume it has something to do with the algorithm that syncs the surf animation (esp. since river shores, which don't have that animation, don't cause any trouble), which I don't recall older versions doing.

How do you know it's not related to coastal sound effects?

I experienced similar memory leaks around coasts (virtual memory usage slowly but constantly increases), but only when having the sound pack installed and activated within the game. No more problems once SFX options disabled in Audio Options. Not the desired result, but at least it's working

Thanks for the report. We need to look at what's happening with sound-effects. I'm assuming this is a fairly recent bug.

Hmm. I didn't realize the sound effects were linked to the little coast tiles. I do know that pausing the game and deleting all visible coast via CTRL-d fixed the problem. I think I assumed it was a graphical issue since I know you synced the surf animation fairly recently. It's truly obnoxious to have to do that every time I approach water, though.

[...]since I know you synced the surf animation fairly recently

"Re-synched" would be a more accurate term, as it was synched before I tinkered with the animation code.

a few clarifications to my statements:

- no memory leak when SFX options disabled (OK, that was also clear above
- BG, BG+Keyring, SI, SI+Fixes may all trigger the leak.
- pressing ESC stops the leak as long as the gump is open, even while the sound effects continue
- the memory leaks quickly (when I run it withour brakes, i.e. full speed on my laptop, not the low power consumption mode).
- not all coastlines trigger the leak. Sometimes I can walk on beaches without any leak until I come to an area with heavy drain. The instantly and always reproducable effect I have at the entrance of the pirate cave ("parrot location" west of Serpent's Hold). Most of the time horizontal (west-east) beaches seem to cause leaks, but not always. And also, e.g. the beach directly northwest of the Shrine of Justice will cause a leak until you go into the northwesternmost part of the beach (wet your legs :p)

Tested with the newest (today's) snapshot.

BTW: perhaps the problem is related to the below (but still leaks no matter which wavlist version I use)
The soundpacks for BG (jmsfx.zip) and SI (jmsfxsi.zip) have two different flx files (jmsfx.flx and jmsisfx.flx), but the two different "wavlist" files have the *same* name, so the second one installed will overwrite the first one.

the wavlist is not used by Exult. It is only considered as a help for those that take apart the packs and want to know the names of the files used. You can safely delete the wavlist file.

I see the problem, but maybe Marzo should take a look so that I don't break what he was working on.

(Technical: play_sound_effect is getting called repeatedly with repeat == -1, which means the same sound is getting repeated indefinitely and its buffers aren't freed. I notice that in 'animate.h', repeat is getting set to -1 for certain conditions, but I don't understand why.)

(Technical: play_sound_effect is getting called repeatedly with repeat == -1, which means the same sound is getting repeated indefinitely and its buffers aren't freed. I notice that in 'animate.h', repeat is getting set to -1 for certain conditions, but I don't understand why.)

From a quick test, that doesn't seem to be the problem; setting animate.cc:85 to ignore repeat (incidentally, the only place where it is used... maybe it should be removed entirely), the memory leak still happens. Besides, play_sound_effect is only ever called if the object is not already playing a sound effect.

On another point, it seems that sfx work fine without setting repeat to -1. I *think* that I had kept it based on the old code, but it doesn't seem needed anymore.

Hm. Looking further, it seems that the caching system in Audio::play_wave_sfx is inadequate for multi-track playing of a given sfx and will have to be redone. I will do it over the next weekend, unless someone else wants to do it first

"Besides, play_sound_effect is only ever called if the object is not already playing a sound effect."

Yes, I didn't notice that part. Still, it looked like it was getting called repeatedly with 'repeat' set, so that the mixer was getting more and more streams to mix if you just stood there. But I need to get a better understanding of the audio code.

But I need to get a better understanding of the audio code.

You and me both Everything I wrote barely needed an actual understanding of the audio code -- which is kind of the problem here, as it turned out that portions of it weren't meant for the things I *did* write. The cache code I mentioned was meant for a single object playing any given SFX, not for multiple independent objects playing the same SFX.

OK, the leak is fixed. I have just committed the fix to CVS.

It turns out that the problem had two causes:
1) the old cache system duplicated the sfx data for a given sfx each time it was played;
2) the default number of mixer channels (eight) wasn't up to the task; it would prevent channels from being played, but the memory taken by the SFX object wan't being released if the mixer failed to find a free channel.

Improving the cache system to take care of (1) fixed the memory leak; but so did increasing the # of mixer channels to a high number. But I took the comprehensive fix: I increased the number of mixer channels to 32, added code to re-claim memory from SFX if there was no channel available for play *and* wrote a much improved sfx cache. The new cache code is much more efficient than the older, and saves ~5MB of memory -- possibly more in other sets of conditions which I didn't test -- compared to using the other fixes alone Since it seems to be an all-around win, I can't help but wonder what will go wrong next...

yuo = awesome

Thanks, Marzo!