Title: Melee "lockup" (possibly sound/MixSDL related?) Post by: Daniel on January 30, 2003, 03:10:13 am Just today I noticed a bug in my cvs compile of uqm. When playing in melee mode, the game sometimes gets stuck after I destroy one of the computer's ships. I don't mean "stuck" in the sense of "hangs": the engine keeps running and my ship can still fly around, but the computer never chooses a new ship. While the game is in this state, no sounds play (eg, weapon fire sounds).
On one occasion (I had destroyed a green ur-quan with a green ur-quan and the game stuck as described above), I tried deliberately destroying my ship by ramming it into the planet. As soon as I did, the computer chose a ship -- however, I did not get the opportunity to choose a ship, and I had to quit out of the melee manually. I didn't see any obviously incriminating messages on stdout/stderr after I quit. I am compiling on debian unstable, from CVS of a few days ago (I can't seem to compile the current code -- there's some sort of a build system problem) I didn't see this before MixSDL was introduced into the tree, which makes me think it may be related. Daniel Title: Re: Melee "lockup" (possibly sound/MixSDL related? Post by: Daniel on January 30, 2003, 03:35:56 am I just got this to trigger again, and I got a message on stderr this time:
StreamDecoderTaskFunc(): buffer underrun when playing blackurq/bladitty.mod, source 5 (repeated a whole bunch of times) This time, in case it turns out to matter, the computer blew up my Syreen with a Marauder. Daniel Title: CVS updating and MixSDL problem Post by: Novus on January 30, 2003, 02:03:53 pm Quote I am compiling on debian unstable, from CVS of a few days ago (I can't seem to compile the current code -- there's some sort of a build system problem) I didn't see this before MixSDL was introduced into the tree, which makes me think it may be related. Daniel If you're updating with CVS, remember that CVS by default does not download new directories when updating. The MixSDL directory is not downloaded if you do "cvs up"; you have to do "cvs up -d" instead. Title: Re: CVS updating and MixSDL problem Post by: Daniel on January 30, 2003, 09:53:11 pm Quote If you're updating with CVS, remember that CVS by default does not download new directories when updating. The MixSDL directory is not downloaded if you do "cvs up"; you have to do "cvs up -d" instead. As I may have mentioned, I built uqm with MixSDL, so I don't think that's the problem ;-) What I was seeing looked like a Makefile bug: gcc was being called with no .c file as an argument, so it (rightly) complained about not having any input file. Anyway, it seems that the problem has been fixed in CVS (a cvs update a moment ago made my tree buildable again) Daniel Title: Re: Melee "lockup" (possibly sound/MixSDL related? Post by: Daniel on January 30, 2003, 10:10:13 pm Just a note about the problem which triggered this thread. It just happened again, and I noticed that this time, the music actually stopped before the ships were destroyed. In the terminal I started the program from, I got another "buffer underrun" message, repeated over and over.
So it looks like no-one has fixed this in CVS yet (what I was trying to check earlier when it wouldn't build) Daniel Title: Re: Melee "lockup" (possibly sound/MixSDL related? Post by: Daniel on February 01, 2003, 04:53:01 am I have now been able to reproduce this in the normal single-player game. The sound cut out for no obvious reason and I started getting continuous "buffer underrun" messages for whatever background music was supposed to be playing. When I encountered an alien in hyperspace, the game crashed trying to play "lbm/redalert.mod".
Daniel Title: Re: Melee "lockup" (possibly sound/MixSDL related? Post by: PhracturedBlue on February 02, 2003, 07:34:48 pm It certainly sounds like a bug in the sound code.
Unfortunately, we changed two things at the same time (added MixSDL and rewrote the streaming code) This is more likely a problem with sound-streaming, but will likely prove hard to debug, since (a) I haven't been able to replicate it, and (b) it isn't actually crashing the game most of the time...and likely once the game crashes, it is too late to figure out why. My recomendation would be to run the game (with a 'debug' compile) though gdb, and then, when it crashes, you can provide a back-trace 'bt') Or if you find a way to make it crash reliably, that would help too. There was one change made about 10 hrs ago dealing with a memory-corruption issue, which might help tho, so you can retry CVS one more time. |