[Jzip-devel] V6 thoughts for the future...

[Jason C P. <jp...@ch...>]

Hi,

This is probably ahead of it's time, but I thought I'd through it 
out.  There's a bit of history to go with it.

The V6 Screen Model is well defined... in at least two different 
ways.  Much discussion on the Z-Machine list about how to standardize 
this took place.  While this was going on Graham proposed V9 (V8 + 
new stuff) and falling off of this came V10 (V6 + minor changes + 
V9).  Nothing came of this later discussion, probably because of 
Glk/Glux.  Anyhow, the V6 issue was never standardized.  What follows 
is my proposal for a header extension based on the V6 discussions, 
and then the few changes I proposed for V10.  (I'm going to get a 
reputation for being long winded here, aren't I?)  I just want to 
bring it up now, because if everything goes correctly and we have a 
wonderful WxJzip+V6 this is going to come up.  

All these ideas were designed around not breaking what already 
exists.

[-------------------------------------------------------------------]
Some Proposal or Other About V6 Machine Capabilities
Take 4
Draft 1
Jason C. Penney



After much thought and discussion this time around I've thrown out 
the new machine number and gone for the header extension, probably 
using Word 4.  I've also tried to handle some of the issues mentioned 
in Section 11 of the Blorb Spec (1.0).  When reading this, remember 
that I'm just trying to draft up a proposal. If an idea is crap, 
let's fix it.  


Proposed format of header extension
-----------------------------------

Hex	Contents
===	========
 0	Extension honored?
 1	Supports music?
 2	Multiple sound support?
 3	Full font style combination support?
 4	Supports 3-OP @set_colour?
 5	Provides Amiga text pallette?
 6	Each window has own colour pair?
 7	Supports multiple text colours?
 8
 9
 A
 B
 C
 D
 E


Proposed information in header extension
----------------------------------------

* Extension honored?

This bit should be set if the interpreter honors the extension by 
filling out the rest of the header extension.  If it is not set then 
game files should rely on the interpreter number to signify what 
features are available.  


* Supports music?

This bit should be set if the interpreter can play music.
(see Blorb Spec, 11)


* Multiple sound support?

This bit should be set if the interpreter can play multiple sounds at
once.  If this is so, the interpreter should support the following
extended syntax for @sound_effect.

	@sound_effect number 3

This should stop the sound 'number' if it was currently playing.  If 
this bit is not set, then the interpreter follows what is currently 
in the ZSpec.  

* Full font style combination support?

If this bit is set the interpreter should follow the "Ideal" model 
set out by the ZSpec, "all text styles should be available for each 
font (for instance, Courier bold should be obtainable) except that 
font 3 need only be available in Roman and Reverse Video".  If the 
interpreter is unable to fully comply with this the bit should be 
left unset, and game authors should take this to mean that they can't 
count on anything in this respect (which is how it is currently).  

[NOTE: the above set of info would probably be useful for any V5/V8
games that wish to use sound as well]

* Supports 3-OP @set_colour?

This bit should be set if the interpreter supports the 3-OP version 
of @set_colour.  

* Provides Amiga text pallette?

This bit should be set if the interpreter provides the Amiga V6 text
pallette (i.e. colours 10-12).  

* Each window has own colour pair?

This bit should be set if the interpreter allows each window to have 
its own distinct colour pair.  If so @erase_window should use the 
windows background colour when erasing.  If not @erase_window will 
use the background colour stored in the header.  

* Supports multiple text colours?

this bit should be set if the interpreter allows multiple text 
colours to be displayed on screen.  If it is not set @set_colour 
should change all text visible on the screen (as the Amiga 
interpreter does now).  


[NOTE:  That leaves 7 bits.  Maybe 2 or 3 could be used to signify 
the colour depth the interpreter provides in some way.]  

What Dos Frotz would need to do to support this.
===============================================
(provided as an example, being that it is the interpreter I have the
most experience with)

For Frotz to support this with no changes to the current screen 
models it provides it would have to check if the header extension is 
present, and if so it should do the following:  

In MCGA mode:
	Set bits 0,3,4,6 and 7

In Amiga mode:
	Set bits 0,3,4, and 5

[NOTE: I'm 99% certain it should set bit 3...]
[------------------------------------------------------------------]

A bit less relevant maybe, but here was what this became in V10.  It 
does show how the primary idea was to throw out the Amiga model.

From:           	"Jason C Penney" <jp...@ch...>
To:             	Z-Machine Mailing List <z-m...@gm...>
Date sent:      	Tue, 19 Jan 1999 20:30:42 -0500
Subject:        	[z-machine] V10 proposals...
Send reply to:  	Jason C Penney <jp...@ch...>
Priority:       	normal

Hello again,

 First I'd like to address Gunther's point about the different 
machine modes.  The discussions about this before all pretty much 
boiled down the the following 

Long ago Andrew Plotkin asked:

> Now, if we ignore that one display mode [Amiga Mode] -- with its
> two-color limit, etc -- can we write to the Z-Spec and not worry
> about machine numbers any more?  

And I replied:

> More or less, everything becomes peachy.  

Now on with the show

Minor additions to V6 I'd like to see in V10 as a result of all the 
hashing about that went on before...


1)	Bit 6 of 'flags 1' is undefined in V4+

 Define it to be a 'Full font style combination support?' flag. 

 If this bit is set the interpreter should follow the "Ideal" model 	
 set	out by the ZSpec, "all text styles should be available for each 
 font (for instance, Courier bold should be obtainable) except that 	
 font 3 need only be available in Roman and Reverse Video".  If the 	
 interpreter is unable to fully comply with this the bit should be 	
 left unset, and game authors should take this to mean that they 	
 can't count on anything in this respect (which is how it is 		
 currently).   

2)	add a bit to 'flags 2'.  If the game wants to use music it should 	
 
 set this bit, the interpreter should clear it if it can't play 		
 music.  (If proposal 4 is adopted, this should tie in with it, if 	
 not it still stands on it's own to say that files identified as 	
 music in a blorb file can still be played by the interpreter)  (see 
 Blorb Spec, 11)

3)	extend @sound_effect:

   @sound_effect n 3 with n > 0
   ...stops sound_effect #n only

   @sound_effect 0 3
   ...stops all sound effects 

 This would allow multiple sound effects (if the interpreter 		
 supports this there would need to be a way to signal the this as 	
 well, maybe another header bit).

4)	Add a separate opcode for music (@sound_music?)

 It would be the same, or very similar to @sound_effect, but 		
 allows the music system of the 	interpreter to work independently 	
 of the sound effect system.  (interpreters need only support 		
 this opcode if they set the 'can play music flag', otherwise they 	
 should just treat it as a nop or something, I think.)    

That's about it,
Jay

[--------------------------------------------------------------]

And again... that's about it.  Thanks for reading
Jay


----
Jason C Penney (jp...@ch...)  Xarton Dragon -=<UDIC>=-
<http://www.chelmsford.com/home/jpenney/>
"A straight line may be the shortest distance between two 
points, but it is by no means the most interesting." --The Doctor