[z-machine] 1.1 proposal

[David Fillmore]

On Sun, 3 Aug 2003, David Kinder wrote:

> > You know what, you're right. I'd forgotten about the @sound_data opcode.
> > However, there's another part to this, which is thatif I want to play
> > several sound, the current system only tells me what will happen when I
> > play the next sound, so I could be halfway through playing four sounds
> > before realising that I'll only be able to actually play two of them,
> > before they start interrupting each other. By this time, it's too late to
> > do anything. My system, on the other hand, allows me to check before hand
> > how many sounds I can play.
>
> Fair enough. Okay, based on this, as I understand it, your objections are:
>
> 1) You can't tell how many sounds you're going to be able to play until
>    you've actually started playing them, and
> 2) If a sound is playing more than once, you can't pick which one to stop.
>
> In practice, I'm not sure how much of a problem 1) is going to be. Can a game
> really do anything meaningfully different other than play as many sounds as
> the interpreter allows?

Yes. It can, for instance, play two background sounds (like, say, an
air conditioner and distant traffic) if enough channels are available, or
no background sounds at all. I don't want the sound effect of a fridge
opening to cut out the background sound of the air conditioner. That's
ugly. If I know before hand how many can play, I can just not play the
background sounds if there aren't enough channels.

I'm writing up a small demo which uses my system, and will hopefully show
why it's useful to have prior knowledge of this stuff.

> A response to this (one you made, in fact) is that interfaces should let the
> game have as much control as possible, which can be hidden by a library. I
> have to say I'm not keen on that: Interfaces should provide as much as is
> useful, and no more: more makes interpreter authors' lives harder. Of course,
> the trick is getting the "useful" bit right ...

I truly believe my system is simpler to the interpreter author, actually.
There's no checking between different 'types' of sound, no setting aside
different channels for different type, no checking the resource numbers of
already playing sounds to figure out which to stop. You just figure out
how many sound you can play on startup, and fail to branch if the channel
picked is too large (and sounds only interrupt other sounds on the same
channel).

> ... which leads me on to the other bit: your proposed solution. As a
> theoretical example, suppose we've got an interpreter that can play a limited
> number of sounds, perhaps because it just usees the sound hardware directly.
> Let's ignore music for now, too. Suppose this interpreter can play two stereo
> samples simultaneously, or four mono samples, or one stereo and two mono
> samples. How does this fit with your proposed solution? In this case, I can't
> see how many channels your proposed opcode might indicate. 2? 4?

Two. It's the highest number of sounds the interpeter can guarantee will
play at once. Sure, in theory the interpeter can play four mono samples,
but in practice, when in tries to play four stero samples, Bad Things will
happen. So, we only allow two channels.

This may seem restrictive, but the only alternative is to have the number
of available channels change depending on what samples are currently
playing, which is the sort of complexity I'm trying to avoid.

--
Fillmore