Please test this in all the interpreters you can! Hopefully both tests
will return 3. But posts the results whatever they are.
Although if Glk can't display all unicode characters either then it
should return 0...
The main thing I want is consistency. I had thought about using a
private use character because it would be obscure and unlikely to
occur in normal zcode files, but then it would be weird to check if a
terp can print 'a' too. If all the terps are consistent with their
results for 'a' then we'll use that.
I think I'll stick with 'a'.
What Parchment will do is:
@check_unicode(char):
if char == 'a' return 7
else return 3
(Although it could be nice make it check properly whether it can
actually read an arbitrary character that can be changed if and when
someone reports the bug.)
What a parchment-IO game will do is check if @check_unicode('a') == 7.
Hopefully all other interpreters will return 3, I'd be very surprised
if they do not!
So far so good, this system should allow us to detect whether we are
on Parchment or not. However what about non-Parchment-IO games? Well
hopefully none of them have any reason to check whether 'a' can be
printed. If they do, hopefully they will either check if it returns a
positive value, or check the individual bits. If there are any silly
games which need @check_unicode('a') == 3 exactly, then... well we can
cross that barrier later. We could probably check that the games are
all 2010 or later.
Now why I am suggesting this? It will allow us to test and develop a
more ideal web IO system earlier than if we had to wait for Quixe to
be finished. Quixe would be the ultimate target for this IO system,
though testing it with zcode games will be fun and helpful!
I'm a bit late to this, but can I suggest that if you want to extend
the Z-machine you don't do it by hacking the meaning of
@check_unicode? It would be a lot more elegant to have something in
the header, and this would at least be following in the tradition of
Infocom data files that occasionally use the contents of the header to
change themselves in various ways. The obviuous candidates in the
header for this are
1) The interpreter number field (offset 30 in the header), used to say
what sort of machine the interpreter is running on. Infocom used
values from 1 to 11, and I've never seen any interpreter use anything
outside of this. You could pick a number (e.g. 20) to mean "you're
running under Parchment".
2) The user name field (8 bytes starting at offset 56 in the header).
Used only by a few Infocom test files to change behaviour. The
interpreter could set this to "Parch".
One or both of these seems rather more appealing than hacking
@check_unicode: if you go ahead with "use extra bits of the return
code" for this one, then in future we can't re-use that bit for
anything actually related to Unicode.
David
I wasn't sure about using the header, as from the spec it seemed like
there was a huge degree of incompatibility or at least many different
implementations. @check_unicode however was new and clearly defined.
I doubt anyone will ever succeed in extending @check_unicode, but I
feel what you're saying. If you're sure setting the interpreter number
to something new won't cause problems that will be better. In
addition, I can make it check the year and only set the new
interpreter number if it's (20)10 or later. Then we'd only have to
worry about I6 or I7 doing something silly... there's no reason for
them to care about the interpreter number is there?
No, the I6 and I7 libraries never look at the interpreter number,
except for the version command, which just prints the number out. To
my knowledge the only games that did different things for different
machines were the Infocom ones, and then only in a few cases, mostly
Beyond Zork and the V6 games.
David