Hi,
> > And it seems to work there for you...
> But the loop isn't set to -1 the first time.
Same here.
> > No, I don't have a client object either, and it works fine. The calling script
> > is probably checking doorSound explicitly.
>
> Hmm. This is interesting.
> I don't have this code at all getting executed here...
>
> 2B54: [B] callk IsObject[6] 02 -- acc=0001 (0xaab2; the sound handle)
> 2B57: [W] not -- acc=0000
> 2B58: [W] bnt 0001 [2b59] ; (1) whoah- the jump target addresses are wrong!
> 2B5C: [B] lsp 01
> 2B5E: [W] push0
> 2B5F: [B] &rest 02
> 2B61: [B] lat 02
> 2B63: [W] send 04 doorSound::check[FUNCT]()
> 419D: [B] pToa 12 (signal)
> 419F: [W] bnt 0019 [41b8]
> 41A2: [W] push1
> 41A3: [B] pTos 16 (client)
> 41A5: [B] callk IsObject[6] 02 Kernel params: (0000)
> 41A8: [W] bnt 0008 [41b0]
> 41B3: [B] pToa 12 (signal)
> 41B5: [B] aTop 14 (prevSignal)
(1): The jump target address is relative to the pc value /after/ execution,
so the bnt here jumps over the next command rather than right inside itself.
Committing fix now.
> what's on the stack when you call doorSound::check[FUNCT]() ?
--- First call (door opening):
Call stack (current base: 0):
0:[ffffffff] SQ3::play()
obj@11be pc=4a2b sp=7c08 fp=7c08
1:[0] SQ3::doit()
obj@11be pc=0926 sp=7c0e fp=7c0c
2:[1] Game::doit()
obj@11be pc=4b6a sp=7c12 fp=7c12
3:[2] sounds::eachElementDo(0088)
obj@493e pc=2d03 sp=7c1e fp=7c18
4:[3] doorSound::check()
obj@aabc pc=463d sp=7c22 fp=7c22
> stack 5
[sp-000a] = b40e
[sp-0008] = 0000
[sp-0006] = aabc
[sp-0004] = 0088
[sp-0002] = 0000
--- Door closing: Sound cue 9:
Call stack is identical
> stack 5
[sp-000a] = b40e
[sp-0008] = b3e6
[sp-0006] = aabc
[sp-0004] = 0088
[sp-0002] = 0000
--- Door closing: after loop cue
Same as sound cue 9.
> > I haven't seen this one in your trace, but this is the place where
> > the door sound is actually "finished": When the "loop" signal reaches
> > the object, the signal property is set to 0xffff, so the 'eq' after
> > (1) matches, and DoSound(STOP_ALL) is invoked. I haven't checked what
> This isn't happening for me, because the door sound never "finishes" --
> it's looping, after all. :)
Yes, but the finish signal should be sent when DoSound(STOP_ALL) is issued.
/If/ it is issued...
> > happens then, but I'd guess that doorSound gets the "stopped" message
> > from the sound server, and the game continues as soon as soon as
> > it realizes that doorSound has been stopped.
>
> Yes, this is what happens when I disable the loop.
On my box, the doorSound::check script enforces this by explicitly instructing
the sound server to stop the sound effect...
> > This is how it works on my system with my version of SQ3. Please go
> > on checking where you left off- the "loop" signal (0xffff) should come
> > next...
>
> The 'loop' signal seems to be getting lost, from what I can tell:
> > snk
>
> Kernel CHECK: Animate[b](90b8, 0001)
> FSCI: process_sound_events(ksound.c L105): Received absolute cue 9 for aab2
> FSCI: process_sound_events(ksound.c L67): Received loop signal (-1) for aab2
> pc=3a2b acc=0456 o=0456 fp=69be sp=69c2
> prev=3c sbase=6994 globls=23fa &restmod=0
> Step #363011
> 3A2B: [B] callk IsObject[6] 02
> Kernel params: (0000)
> > heapobj 0xaab2
> Object doorSound
> Species=000a, Superclass=4250
> Local variables @ 0xacb0
> Variable selectors:
> species[0000] = 000a
> superClass[0001] = 4250
> -info-[0002] = 0000
> name[0017] = aca2
> state[0020] = 0002
> number[002b] = 0005
> priority[003f] = 0000
> loop[0006] = ffff
> handle[002c] = 0000
> signal[0011] = 0009
> prevSignal[0081] = 0009
> client[002d] = 0000
> owner[0082] = 0000
Are you sure doorSound::check wasn't called in between?
> So 'loop' is getting set correctly, but 'signal' has the value of the
> previous signal.
If you answered 'yes' to my last question, then I agree. In case you need
any helpful suggestions, try to check whether both events were received
during the same call of process_sound_events(), and try to assert that their
write operations wrote the numbers we wanted them to write.
> Time to find out why.
Good luck!
llap,
Christoph
-- Attached file included as plaintext by Listar --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEARECAAYFAjqFou4ACgkQg4EAPSSqEf+scACdEEAHxjAtC50EzVdw5eATNdNG
VAQAnR3wP1QawGFAhORA6brerSiu1bno
=iZ42
-----END PGP SIGNATURE-----
