[z-machine] 1.1 proposal

[David Kinder]

> 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?

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 ...

... 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?

David