On Fri, Feb 09, 2001 at 12:09:27PM +0100, Christoph Reichenbach wrote:
> > Fixed the "hang" while waiting for the pod to shut down in SQ1.
> > The game was setting the loop count of the sfx to "-1", which was being
> > interpreted as "loop forever". I believe that this is really "play
> > once", as many one-off sfx in sq1 and other games show up with a loop
> > count of "-1".
>
> Are you sure you're not just missing a sound cue somewhere? I used to be
> pretty sure about loop==-1 meaning "loop forever", and missing sound cues
> definitely is the reason for SQ3 and QG1 sometimes (!) failing on
> slowed-down systems.
Well, it would have to be a LOT of missing sound queues. :)
(it's a simple fix anyway, so un-fixing it is trivial)..
Here's my rationale:
When you're moseying around inside the grabber in sq3, there are sounds
that play when you go forward or backwards. Namely the hum of the motor
(presumably a note-on, nothing else), and a recuring beep every second.
(I think I should hook my mt32 up to my dos box and have a look-see
on the midi traffic...)
Basically, one event gets sent for the "start hum", and one event is
sent for EACH beep.
So if it's loosing sound events, it's not loosing 'em in the sound
server code. I'll add some more debugging output to the sound.c
(and kernel.c) code to have it report every sound event that gets
through, but my gut feeling is that it's never sending any STOP_HANDLE
events at all.
- Pizza
--
Solomon Peachy pizzaATfucktheusers.org
I ain't broke, but I'm badly bent. ICQ# 1318344
Patience comes to those who wait.
...It's not "Beanbag Love", it's a "Transanimate Relationship"...
