#exult@irc.freenode.net logs for 14 Mar 2010 (GMT)
Archive Today Yesterday Tomorrow
Exult homepage
[00:15:16] --> shazza has joined #exult
[00:19:26] --> Colourless has joined #exult
[00:19:26] --- ChanServ gives channel operator status to Colourless
[00:23:31] --> shazza` has joined #exult
[00:32:23] <Marzo> Hi Colourless
[00:33:11] <Marzo> I have a bug report for you, whose solution has eluded me for several hours already
[00:34:53] <Marzo> It affects the MT32Emu midi driver -- and apparently, only it is affected
[00:35:43] <Marzo> (but there may be a possibility that Timidity is also affected, I don't know -- would ahve to install Timidity and recompile to be sure)
[00:37:14] <Marzo> Basically, if I start Exult with the midi audio driver set to MT32Emu, Exult will hang forever at LowLevelMidiDriver::loadTimbreLibrary
[00:37:24] <Marzo> Specifically, line 11886
[00:37:34] <Marzo> s/11886/1186/
[00:38:17] <Marzo> However, if I start in any other midi driver I tried thus far, then switch to MT32Emu, everything works fine
[00:47:55] <Marzo> I *think* it may be because MT32Emu uses initSoftwareSynth instead of initThreadedSynth, but I am not sure
[01:18:46] <Colourless> hm
[01:18:53] <Colourless> i'll look into it
[02:11:55] <Colourless> ok i know what the problem with the code it
[02:11:57] <Colourless> *is
[02:36:32] <Colourless> its a threading deadlock
[02:53:03] <Marzo> One thing I found that seemed to 'fix' the issue -- probably by screwing up something else -- was to always call initThreadedSynth in lines 199-200, also calling initSoftwareSynth if isSampleProducer
[02:53:38] <Marzo> Then call destroyThreadedSynth instead of destroySoftwareSynth in line 225
[02:53:47] <Marzo> (in all cases, in LowLevelMidiDriver.cpp)
[02:54:18] <Marzo> It is a quick hack, yes; with untold side effects which I haven't tried to figure out yet, as there is probably a better solution
[03:04:49] <Marzo> Out of curiosity (and owing in part due to the fact that I couldn't find it) -- where exactly are the threads created for SoftwareSynth? I know they exist because GDB says they are being created, but haven't found out where they are created yet
[03:11:59] <-- shazza has left IRC ()
[03:11:59] <-- shazza` has left IRC ()
[03:12:00] <Colourless> SDL is creating them
[03:14:11] <Marzo> Hm; this definitely means then that there is no thread being created for software synth audio
[03:16:12] <Marzo> With the 'hack' I posted about earlier (always calling initThreadedSynth), GDB reports the creation of 3 threads (and one destroyed) before Exult tries to open the midi driver; that last thread is not created in the clean branch code, though
[03:17:48] <Marzo> The odd thing is that the main trunk works, and there is no change in this code
[03:18:56] <Colourless> committed fix for the problem
[03:19:00] <Colourless> well committing
[03:19:13] <Colourless> done
[03:20:38] <Marzo> Compiling...
[03:22:48] <Marzo> Working perfectly
[03:23:53] <Colourless> putting the mt32 roms in the application bundle has some strange side effects
[03:24:06] <Marzo> Now all that remains for MT32 & MT32Emu is to skip loading all the unnecessary timbres and patches
[03:24:23] <Marzo> I committed a possible fix for that
[03:24:30] <Colourless> mt32 emu writes out cached waveform data into the dir where the roms are
[03:24:40] <Marzo> Hm. That is bad
[03:24:51] <Marzo> (so no, I didn't commit a fix for that)
[03:25:20] <Colourless> shoudl edit mt32 emu itself to look in the bundle path for its files, rather than set its base path to it
[03:25:29] <Colourless> should be reasonably easy to fix i think
[03:25:44] <Marzo> Yes, I was doing a quick hack that ended up not working
[03:26:02] <Marzo> Will do it the right way now...
[03:32:16] --> Malignant_Manor has joined #exult
[03:42:28] * Colourless scratches head
[03:43:09] <Colourless> sometimes... only sometimes, exult is crashing because ExultDataSource mouse_data(MAINSHP_FLX, PATCH_MAINSHP, 19); is failing to load anything
[03:44:36] <Marzo> That is odd
[03:46:03] <Colourless> hmm.
[03:46:23] <Colourless> something is causing U7FileManager::file_list to become corrupted
[03:47:07] <Marzo> That is probably my code :-)
[03:47:38] <Colourless> entry 4 in the list this
[03:47:39] <Colourless> ({name=0x06256ed8 "ýýýý««««««««îþîþ" index=-1 ownstr=false },0x061f48c0 {_file={...} })
[03:50:57] <Colourless> my guess, a string is being deleted or something when its in the file_list
[03:51:04] <Marzo> This is probably some misbehaved call to a U7object or U7multiobject that passes a c_str()
[03:51:24] <Marzo> Let me check
[03:54:06] <Marzo> Ah, found them
[03:54:18] <Marzo> Recent mistakes, even
[03:55:29] <Marzo> They are both in audio/Midi.cc: lines 171 and 173
[03:56:05] <Marzo> the correct form would be to pass the flex strings like `File_spec(flex)`
[03:56:55] <Colourless> that would explain why i wasn't getting crashes when using oggs :)
[03:57:23] <Marzo> (I should have known better than to make this mistake, considering I wrote the File_spec class and explicitly disallowed implicit conversion from strings because it caused a similar issue)
[03:57:49] <Marzo> I will finish up the path settings in MT32Emu and commit
[03:57:57] <Colourless> ok thanks
[04:03:52] --> julien- has joined #exult
[04:04:11] <-- julien has left IRC (Ping timeout: 265 seconds)
[04:19:28] --> matt_o has joined #exult
[04:23:07] <-- jvlee has left #exult
[04:25:34] <Marzo> Committed to head, merging to no-SDL branch now
[04:25:43] <Colourless> ok
[04:26:24] <Marzo> And it should be in the branch too now
[04:26:25] --> jvlee has joined #exult
[04:26:57] <Colourless> coolies
[04:29:37] <Colourless> what you'd done looks good
[04:31:15] <Marzo> Whoever it was that added those property overrides for file open/close deserves some praise; it does exactly what is needed
[04:54:26] <Colourless> hhm
[04:54:55] <Colourless> setup_data_dir looks a littlr broken.
[04:55:19] <Colourless> the value of the data_path arguement is never used
[04:55:39] <Colourless> the data_path argument being the value of "config/disk/data_path" in exult.cfg
[04:56:06] <Colourless> looks like line 784 of utils.cc should probably be
[04:56:10] <Colourless> add_system_path("<DATA>", data_path);
[04:56:53] <Colourless> at the moment that code is attempting to use the current dir as the datapath which will almost certainly never be true
[04:57:44] <Marzo> That is correct: line 784 *and* line 788 should both be data_path instead of data
[04:58:54] <Marzo> It was working in the end if you didn't have anything in the cfg, which is where all of the testing went
[04:59:03] <Marzo> Nice catch :-)
[04:59:24] <Colourless> trying to run multiple copies of exult with a single cfg and data dir
[04:59:30] <Colourless> not working :-)
[05:00:11] <Marzo> Hehe
[05:02:55] <Marzo> Fix committed to main trunk, should be in the branch shortly too
[05:05:22] <Colourless> thanks
[05:06:42] <Marzo> If you have a Mac, and are using an app bundle, you can also try putting the BG and SI static dirs in a subdir of (bundle)/Content/Resources/data (IIRC) and setting the appropriate <static_path> in Exult.cfg to <BUNDLE>/subdirname
[05:08:57] <Marzo> (we won't be distributing any such bundles, of course, but it can still be useful for putting in iPhones and other things)
[05:09:27] <Marzo> (not that I think Exult *runs* on an iPhone...)
[05:14:59] <Malignant_Manor> Exult seems to crash in the game menus when clicking while the speech is going on (trunk and branch).
[05:19:27] <Marzo> Can you give a sure-fire way to reproduce it?
[05:22:15] <Malignant_Manor> I can repeat it each time, if I wait until the speech starts in the intro and then click. This is in XP.
[05:24:23] <Marzo> In Ubuntu, there is no crash
[05:24:33] <Marzo> In XP, it will take me a couple of hours to test
[05:24:45] <Marzo> So I will leave for after I sleep
[05:26:36] <Marzo> (by the way, I did some benchmarking -- starting from clean svn, my Ubuntu box configures, compiles and cleans Exult, ES and tools 7 times in the time my Windows box takes to compile once)
[05:28:50] <Marzo> In any event, I am off to bed -- good night
[05:29:51] <Malignant_Manor> good night
[05:35:32] <-- Marzo has left IRC (Ping timeout: 265 seconds)
[06:00:28] <Colourless> i don't get any crashes
[06:00:53] <Colourless> sure it isn't the crash marzo fixed a few hours ago?
[06:10:22] <Malignant_Manor> This is current svn. There seems to be a loop that is causing it in bggame.cc
[06:10:25] <Malignant_Manor> while (time<1040)
[06:17:12] <Malignant_Manor> Here's a quick path to get to the loop. http://pastebin.com/RRFZFk1e
[06:19:32] <Malignant_Manor> I guess I didn't have mixer up to date. The trunk crashing was up to date.
[06:20:17] <Malignant_Manor> No mixer is crashing still too.
[06:20:42] <Malignant_Manor> Unless it it something I need to compile from scratch.
[06:22:04] <Malignant_Manor> It is with midi though. Ogg didn't crash.
[06:23:17] <Malignant_Manor> I'm cleaning and compiling again. I'll be able to tell if it still happens in about 15 minutes.
[06:38:13] <Malignant_Manor> Confirmed it again
[06:41:44] <-- matt_o has left IRC (Remote host closed the connection)