Hi Christoph, The context is sound.c. Let me rephrase:
In some parts of the code, there are calls to the sound_command() via gamestate->sound_server->command(). In most others, a call to sound_command() only is made, rather than through the game state pointer. Why? sound_suspend() and sound_resume() are never called because their functions are performed by sound_command() and everything just calls that with a param of SOUND_COMMAND_SUSPEND_SOUND or SOUND_COMMAND_RESUME_SOUND. So why are they there? Similarly for sound_save(), sound_restore(), _sound_transmit_text_expect_anwer () which is the only function that uses the previous two. _sound_expect_answer () is never called at all. I think it's good that sound_command() is a sort of interface to passing on things to the sound server though. I hope this is clearer. Cheers, Alex. > Hi, > > > On Sat, 6 Oct 2001, Alexander R Angas wrote: > > > I'm getting close to getting this event SS working but have been a bit too > > busy to do much on it lately, sorry! > > No need to apologize- we're all working on it in our spare time only. > > > I was just having a look at sound.c and wondered why this was used and not > > everything done in soundserver.c? Why isn't s->sound_server->command() and > > its similar functions used for everything? Why do sound_command() and the > > other sound_XXX() functions need to be there (in sound.c) instead of calling > > everything through the sound server? > > They don't need to be there, they just happen to be. > > While the origins of this code are, in fact, historical, there are reasons > for this arrangement- after all, sound_command() does a bit more than > just pass on its parameters in a format that is more convenient for > the average sound server structure to handle: For commands that expect > a response, it waits and delivers the response to the caller (IIRC only > the sound server test function does that), and for 'load song' commands, > it retreives the songs in question and passes them on to the sound server. > > It could certainly be argued that this functionality could also be > provided in separate helper functions. > > > It just seems like double-handling and > > illogical to not have the sound server do everything instead of having bits > > of it split off. > > Duplicating the functionality present in sound.c in every sound server > does not make much sense to me, so I believe that this is not what you > mean. > I assume that what you are suggesting is that the functionality invoked in > sound_command() should be split into smaller functions that would then be > called from sound server implementations, rather than the other way > around: > > s->sound_server->command(STOP_SONG, handle, 0); > .... > packet = snd_encode_packet(STOP_SONG, handle, 0); > .... > packet.a := STOP_SONG; packet.b = handle; packet.c =0; > return packet; > .... > write(fd, packet); > .... > > rather than > > > sound_command(s, STOP_SONG, handle, 0) > .... > packet.a := STOP_SONG; packet.b = handle; packet.c =0; > s->sound_server->command(packet); > .... > write(fd, packet); > > > (the 'get voices' and 'send song' commands would probably be the > only ones called from a separate helper function then). > > Considering that your particular implementation does not care about packet > encoding, unlike the SDL and Unix sound servers, I think I can now > understand why you fail to see the point in this and would agree that it > makes sense to put this part of the sound_command function in a helper > function. The operations to get the number of voices (which also acts as a > test for whether the sound server works at all) would still have to be > taken care of, of course. > > Is this what you were aiming at? > > llap, > Christoph > >
