[z-machine] 1.1 proposal

[David Kinder]

> It's been a long time now since there was any discussion on the 1.1
> proposal, so I thought I might once again bring up my biggest problem with
> the current draft.

Glad someone else is still thinking about it! I've started implementing
draft 7 in Windows Frotz 2002. Fortunately the sound opcodes are at the
end of the spec: I've been working through from the start, and am currently
only up to embedded Unicode strings.

> It's overly complicated to implement and puts all the control in the
> hands of the interpreter, rather than the game writer.

I don't agree with the former: I can see how to implement it in WF2002 and
it doesn't appear complex to me. Not sure about the latter yet.

> I have put up a page explaining a bit more fully my problems, and my
> alternate proposal. The page is at
> http://www.plover.net/~marvin/zspec.html. I would be very grateful for any
> comments on, or problems with, the proposal.

Warning: These are just initial observations, I probably won't have time to
really think about it until the weekend. Hopefully some acknowledgement that
someone else is looking at this is welcome :)

Your objections are, if I've read correctly:

1) If I play a sound, I don't know which other sounds might have stopped.
2) If I try to play music, I don't know whether or not it played, as sounds
   may have used up all available channels.
3) If the same sound is playing more than once, I can't pick one to stop.

I don't follow objection #1, that the game won't know if a sound is to be
stopped when a new sound is played. As I understand it, the game should use
the new @sound_data opcode to determine if a sound is going to be played
successfully. That is, if the channel availability word is zero, you know
that the sound will play and nothing else will be stopped, otherwise the
word contains the sound that will be stopped.

Objection #2 differs from my reading of the spec. It says that music and
sounds are *independent*. From that, it follows that, if the music bit is
set in the header, then it is *always* possible to play at least one MOD
music resource, regardless of whether or not all the channels for sound
effects are in use or not. In that case, music can always be played: at
worst, it will simple interrupt another piece of music, which can be detected
by a call to @sound_data.

Objection #3 is valid, but I'm not convinced it's that important. Some
control is sacrificed, as a price from having the game deal with channel
numbers directly (which is your proposal). I'm not convinced that the extra
control is worth the extra complexity.

I don't follow how your proposed opcode would work at all. In your example
for your new opcode, what if I wanted to get information for playing mono
samples? Then surely set-channel should work for any value 0-7 in your
example? (Or 0-3 for stereo samples)

My gut reaction to your proposal is that I don't like it, principally because
now the game has to juggle all these channels numbers. But that's just an
initial reaction.

David