ZMPP/Glulx update
Wei-ju Wu
just wanted to let you know that there is a new build of the ZMPP/
Glulx interpreter on the ZMPP website:
http://zmpp.sourceforge.net/games/index.html
The most noticeable things that changed are
- addition of mouse input
- displaying the styles in text grids
- does not scroll to the top on every turn anymore
- 23 of 38 tests of Zarf's Glulxercise test suite currently pass
What's still missing:
- Glulx: save/restore, undo, function calls in string decoding
- Glk: timer events, sound, writing/reading files
- tons of polishing and testing, especially on Windows and Linux
Best,
Wei-ju
Carlos Sánchez
Hi,
I'm very very interested in your progress in glulx support, so great
news, and thanks so far for the work done :)
On the other hand, I would be also very interested in testing the
compatibility of Superglus games with ZMPP. Superglus generates glulx
files, but as I already had a problem in the past with Git (as Git is
not a complete glulx machine implementation) I would like to know in
advance if there is going to be any problem with ZXMPP, and solve it
before is late :)
I can provide a demo game (in spanish) and even test it myself if you
tell me how.
Please let me know your thoughts.
Wei-ju Wu
thank you very much for your comments, I have replied to you in a
personal message, I hope that is Ok with you.
Wei-ju
Andrew Plotkin
>
> On the other hand, I would be also very interested in testing the
> compatibility of Superglus games with ZMPP. Superglus generates glulx
> files, but as I already had a problem in the past with Git (as Git is
> not a complete glulx machine implementation)
It is as far as I know.
If you're talking about one-byte and two-byte locals, I'm pretty sure
that Glulxe that was wrong in their handling, as well as Git. I'm
deprecating them in the next version of the spec, and I'm not
implementing them in Quixe.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Wei-ju Wu
> It is as far as I know.
that was my understanding as well from reading past raif posts.
> If you're talking about one-byte and two-byte locals, I'm pretty sure
> that Glulxe that was wrong in their handling, as well as Git. I'm
> deprecating them in the next version of the spec, and I'm not
> implementing them in Quixe.
what is your recommendation to handle deprecated features on Glulx in
general ? Are authors recommended to recompile and redistribute or
should interpreter writers just implement them (with a warning) ?
Wei-ju
Andrew Plotkin
> On May 19, 8:38�am, Andrew Plotkin <erkyr...@eblong.com> wrote:
> > It is as far as I know.
>
> that was my understanding as well from reading past raif posts.
>
> > If you're talking about one-byte and two-byte locals, I'm pretty sure
> > that Glulxe that was wrong in their handling, as well as Git. I'm
> > deprecating them in the next version of the spec, and I'm not
> > implementing them in Quixe.
>
> what is your recommendation to handle deprecated features on Glulx in
> general ? Are authors recommended to recompile and redistribute or
> should interpreter writers just implement them (with a warning) ?
That's a good question (he said, wishing he had a good answer).
I don't have an answer *in general* for spec errors (or errors in
Glulxe, which acts as a reference implementation). I'm coping
case-by-case. So far we've only had a couple issues like this, and
this is the worst.
(The other cases I recall have been Glk file/stream handling, and they
affected very few shipped games, so I felt safe in changing the spec.)
For this short-locals thing, I recommend that authors recompile their
games to not use them. I assume that the released Superglus games are
written to match Glulxe's behavior, and I am not going to change that.
However, that behavior is not well-documented (or particularly sane --
I think it's not consistent between big- and little-endian machines).
Therefore, I do not recommend that new interpreters try to copy it,
even for a compatibility option. I see I have some code in Quixe to
handle short locals, but it doesn't match Glulxe; it's my best attempt
at doing what the spec says, and I don't remember now how close I got.
Carlos Sánchez
Well, it is not , one-byte and two-byte locals are in the
specification (section 1.3.1), so a glulx implementation that doesn't
support one-byte and two-byte locals is as incomplete as a glulx
specification that doesn't support "copy" opcode, or indirect
addressing, etc. Now is not a problem anymore anyway as I modified the
unsupported code for better compatibility (except for old games made
with old versions, obviously).
If you decide to deprecate one-byte and two-byte locals then Git will
be a complete glulx machine implementation (again, afaik), but only
then it will be, and because Mohamed goes to the mountain, as the
mountain doesn't come Mohamed. Deprecate them is not a bad idea
anyway, to avoid problems like the one we had. If it is cleary
specified in the Glk specification no one will use them and won't have
nasty surprises.
> If you're talking about one-byte and two-byte locals, I'm pretty sure
> that Glulxe that was wrong in their handling, as well as Git. I'm
> deprecating them in the next version of the spec, and I'm not
> implementing them in Quixe.
Glulxe was working well with one-byte and two-byte locals (in fact, it
is the recommended Superglus interpreter), Zag was working well with
one-byte and two-byte locals, Zoom was working well with one-byte and
two-byte locals, only Git failed to support them. I understand why,
but that doesn't make it a complete implementation, it is incomplete,
and is nothing wrong with it.
++U
Carlos Sánchez
I recommended,but obviusly I cannot force every author to do it, and
some of them are even MIA. For the time being old Superglus games
using 1/2-byte locals are running well in all known interpreters but
Git, though once that is deprecated maybe that changes if mantainers
stop supporting short locals.
By the way, I'm just curious: can you explain how being little endian
or big endian may affect? I mean, you are just refering to an offset,
and so that should be internally managed.
vaporware
One and two byte locals are a decent idea, but as specified they
aren't very useful: they can only be used with the copyb/copys
opcodes. So they just save space on the stack, and the stack has no
specified size anyway.
vw
Eliuk Blau
Wei-ju, in order to test the new sound feature of ZMPP-Glulx, I invite
you to run "Damusix Demo" in your interpreter.
Additionally, remember that "Damusix" use Glulx's @protect oppcode.
(In case of ZMPP had not support this).
The demo uses sounds in MOD and Ogg Vorbis format. You can get the
demo from the link below:
http://www.caad.es/eliukblau/download/damusix/damusix_v3_090103_r2.zip
Saludos! =) And congratulations for your work! :-D
Eliuk Blau.
P.S.1: If you need support with the audio tests, I am ready. =)
P.S.2: Sorry for my bad English. ;-)
Wei-ju Wu
the CAAD community has always been very helpful in improving ZMPP.
And just as I was preparing to look for some good examples to work on
the sound support, it just falls down from heaven :-)
Thanks a lot for this,
Wei-ju
Carlos Sánchez
for Superglus. It is completely unusable for adventure game
development as it is really really rudimentary and far away from any
of today's standars, but I managed to do a test set game with it,
that is in english and so it can be used as a compatibility check for
interpeter developers who can't read spanish.
More information here:
http://www.superglus.com/doku.php/interpreter_programmers_help
This test set has been already tested successfully on the latest
Glulxe(WinGlk), Glulxe(GargoyleGlk) and Git(GargoyleGlk) versions on
Windows.
Zag is not working completely well as latest version does not support
Ogg Vorbis, and so all Ogg Vorbis sounds are not played (what is a
good behaviour on the other hand). Also, the soundnotify events seems
not to be received.
I haven't been able to test on Zoom, I would appreciate any feedback
related to that.
Eliuk Blau
> Zag is not working completely well as latest version does not support
> Ogg Vorbis, and so all Ogg Vorbis sounds are not played (what is a
> good behaviour on the other hand). Also, the soundnotify events seems
> not to be received.
I am in process of creating a Java API to play, easily, various types
of sound formats that are supported by SPI. Of course, I'm still a
novice in Java, and the API is not yet done and take a while. However,
I have a jar (and sources) that integrates several different libraries
to play mp3, ogg, flac, mod, xm, apart from the usual aiff and wav.
The API will be called JavaMusix, of course. xD
Well, if you think my current adaptation work (and I say I had a hard
time getting the source code and make them work together) can be
useful for you, Wei-ju, I can offer what I have done. =) [And you will
avoid the trouble I took to get the libraries and make them work
together, xD]
Is powered by the brilliant api "jlGui-BasicPlayer." So if you want to
use it, will have to check the documentation of BasicPlayer and each
of the various libraries (if you're interested, I give you more detail
by email).
If you want a demo, download this:
http://dl.dropbox.com/u/2223571/javamusix.jar
Run in (text mode):
java -jar javamusix.jar (no parameters, to hear a demo in XM format)
java -jar javamusix.jar music.[mp3 | ogg | mod | xm | flac | wav | au
| aiff] (for any other format)
Saludos! =D
Good Luck!
eliukblau [AT] gmail [DOT] com
Carlos Sánchez
> I have made today in a few hours a very rudimentary english library
> for Superglus. It is completely unusable for adventure game
> development as it is really really rudimentary and far away from any
> of today's standars, but I managed to do a test set game with it,
> that is in english and so it can be used as a compatibility check for
> interpeter developers who can't read spanish.
>
> More information here:
>
> http://www.superglus.com/doku.php/interpreter_programmers_help
>
> This test set has been already tested successfully on the latest
> Glulxe(WinGlk), Glulxe(GargoyleGlk) and Git(GargoyleGlk) versions on
> Windows.
The same test has been passed successfully today on Git and Glulxe
(Gargoyle Linux).
Carlos Sánchez
> (Gargoyle Linux).
And the test fails at the start on Zoom (1.1.4.1).
Wei-ju Wu
> On 20 mayo, 04:42, Carlos Sánchez <csanche...@gmail.com> wrote:
>
> If you want a demo, download this:http://dl.dropbox.com/u/2223571/javamusix.jar
great, it worked right out of the box for me, that saved me quite a
bit of work searching for libraries, thanks ! I will have to check the
license of the involved for compatibility, since ZMPP now uses BSD
instead of the GPL.
SPI would be sufficient for me, since the ZMPP has always used Java
Sound for playing Blorb sounds.
Wei-ju
Eliuk Blau
The libraries used in JavaMusix are LGPL, Z-Lib and BSD (this last
one, I think)
=)
Eliuk.
Andrew Plotkin
weeks ago, and I had to read a bunch of interpreter source code to
remind myself what was going on out in the world. That's what I do
*every* time someone mentions short local variables in Glulx.
After sufficient nose-beating, I do eventually learn. I have now
summarized the whole situation on my web site:
<http://eblong.com/zarf/glulx/about-locals.html>
This doesn't add anything new to the discussion -- it's just a
description of everything that's been said: what the spec originally
said, what the next spec is going to say, what various interpreters
actually do.
(Hint: no two of these is exactly the same. That's why I needed to
write some documentation.)
If anybody sees anything inaccurate on that page, please let me know.
vaporware
> The subject of 8-bit and 16-bit local variables came up a couple of
> weeks ago, and I had to read a bunch of interpreter source code to
> remind myself what was going on out in the world. That's what I do
> *every* time someone mentions short local variables in Glulx.
>
> After sufficient nose-beating, I do eventually learn. I have now
> summarized the whole situation on my web site:
>
> <http://eblong.com/zarf/glulx/about-locals.html>
>
> This doesn't add anything new to the discussion -- it's just a
> description of everything that's been said: what the spec originally
> said, what the next spec is going to say, what various interpreters
> actually do.
>
> (Hint: no two of these is exactly the same. That's why I needed to
> write some documentation.)
>
> If anybody sees anything inaccurate on that page, please let me know.
FWIW, reviewing the FyreVM code suggests that it behaves mostly the
same as Glulxe: "call frame local" operands are always treated as 4-
byte values, ignoring the locals structure, except when used with
@copyb or @copys. However, FyreVM always uses a big-endian stack, so
the behavior is at least consistent across platforms.
For the sake of supporting the Superglus games out there that rely on
this feature, perhaps we could also document how those games expect
short locals to work?
vw
Andrew Plotkin
>
> FWIW, reviewing the FyreVM code suggests that it behaves mostly the
> same as Glulxe: "call frame local" operands are always treated as 4-
> byte values, ignoring the locals structure, except when used with
> @copyb or @copys. However, FyreVM always uses a big-endian stack, so
> the behavior is at least consistent across platforms.
Okay. (I figured people would be copying my algorithms. *I* did.)
> For the sake of supporting the Superglus games out there that rely on
> this feature, perhaps we could also document how those games expect
> short locals to work?
I'm game. :) Anyone have a good description?
Wei-ju Wu
> Here, vaporware <jmcg...@gmail.com> wrote:
>
> > FWIW, reviewing the FyreVM code suggests that it behaves mostly the
> > same as Glulxe: "call frame local" operands are always treated as 4-
> > byte values, ignoring the locals structure, except when used with
> > @copyb or @copys. However, FyreVM always uses a big-endian stack, so
> > the behavior is at least consistent across platforms.
>
> Okay. (I figured people would be copying my algorithms. *I* did.)
Hi Zarf,
thanks for posting the clarification. ZMPP's local handling works the
same as described above: 4 Byte-locals except for @copyb and @copys. I
don't remember where I got it from (probably from glulxe), but I
clearly remember that local formats were checked in the very early
versions, which did not work: at least one of the games I tested
defined a short local and yet it wrote a long local led to interpreter
crash. Below is the (Scala-)code that ZMPP uses since mid-April.
Wei-ju
/**
* Stores an int at the specified address within the current frame's
local
* space. Note that we do not check the type, simply set the value
without
* a check with type Int.
*/
def setLocalAtAddress(destAddr: Int, value: Int) {
stack.setInt(fp + localsPos + destAddr, value)
}
/**
* Analogous to setLocalAtAddress(), this returns an int-sized value
* and does not check the format, as the Glulx specification
requests.
*/
def getLocalAtAddress(localAddr : Int): Int = {
stack.getInt(fp + localsPos + localAddr)
}
// For copyb/copys
def getLocalByteAtAddress(localAddr : Int): Int = {
stack.getByte(fp + localsPos + localAddr)
}
def getLocalShortAtAddress(localAddr : Int): Int = {
stack.getShort(fp + localsPos + localAddr)
}
def setLocalByteAtAddress(destAddr: Int, value: Int) {
stack.setByte(fp + localsPos + destAddr, value)
}
def setLocalShortAtAddress(destAddr: Int, value: Int) {
stack.setShort(fp + localsPos + destAddr, value)
}
Carlos Sánchez
I have checked your summary and I think everything said is correct,
except for the link to Superglus website, as sourceforge is not used
for the project now for 5 years. It would be better to link to
www.superglus.com :)
About how to make old Superglus games work in all interpreters, we are
facing two problems:
1) Locals
2) ROM writing
The first problem was impeding Git to work, but is easy to solve and
in fact I will make a proposal about what to do with 8/16 bit
variables when deprecated. The second problem is a different one, and
is due to a bug in Superglus.
Well, for the locals issue, all you need to do is make interpreters
ignore locals types, and make them all be 32 bits. I think that will
work fine with all Superglus games, as the only thing I had to do to
make it compatible with Git was just change all the locals to 32 bit.
Superglus has never used copyb nor copys so that is not a problem.
Short local variables in old versions where all 8bit wide, and allways
used with aloadb (being the local variable the third parameter). They
were never used as function parameters, allways as function locals. So
my proposal for 8/16 bit variables behaviour for interpreters, once
deprecated is: make them be 32 bit, that is ignore the header and make
all locals be 32bits.
The second problem was discovered when I managed to make Git work:
Superglus, due to a bug, was writing in memory address 0 a temporary
value. Memory address 0 is allways the ROM, so in fact that should not
have been done, but neither Glulxe nor Zag complained about it, only
Git did. The problem is due to a bug in glulxa that didn't say
anything when a label in source code didn't exist, instead of that,
the label was considered as '0', and that lead to Superglus writing in
ROM because of a typo. Interpreters that don't allow to write in ROM
(only Git so far afaik) will show that bug.
Obviously, this is a harder problem, cause writing in ROM shouldn't be
allowed in general, and so Git behaves correctly here. There is no
solution for that problem, except allowing writing in ROM.
Carlos Sánchez
> this feature, perhaps we could also document how those games expect
> short locals to work?
Well, I have just explained how I solved the problem, and a way to
avoid it in the future (just make interpreters ignore the locals size
in header and make then allways be 32bit wide)
Sadly, I cannot explain why or what do old Superglus games expect,
cause I'm only the one who mantains Superglus, and the original author
is not avaliable. I just can guess, and I guess they were used cause
they were going to store a character (an ascii code) and so they were
made char-wide/bye-wide. There is no counterpart on making them be
32bit wide while "aloadb", the only opcode used to fill them with
data, can be used properly (that is, fills all the other 3 bytes with
0s), so the later checks and comparisons work.