I’m looking for beta testers for Zag, the platform independent Glulx interpreter. I have fixed all the bugs I could find. Now I need help to find more bugs.
If you’re interested in helping out, you can download the latest version here:
banbury.bootes.uberspace.de/downloads/zag/
The archives contain binaries for Windows, Linux and MacOSX.
If you find any bugs, you can report them here:
github.com/Banbury/zag/issues?page=1&state=open
What libraries do I need to get sound in the Linux version?
It’s a single *.jar file, so I assume a Java runtime is all you need.
Zag has it’s own sound library. So it shouldn’t depend on any other libraries. I tested it with Linux Mint and had no problems.
Well, I don’t get sound at all in Six by Wade Clarke, although the game believes sound is supported. It plays just fine in Gargoyle.
I’m running 64-bit Kubuntu 14.04, and my Java runtime is openjdk-7-jre.
This isn’t a Linux problem. I just tried on Windows and I don’t here any sound either. I’m not sure what kind of sound file Six is using, but obviously Zag isn’t supporting it.
Yet.
I’ll see if I can fix it. Thanks for reporting this.
The chunks are type OGGV.
Oh well, that explains it. No OGG support so far. I already had a look at it, but it’s not exactly trivial. I’ll put it on the TODO list.
Well, that was easier than expected. OGG Vorbis sound is now supported. You can download the new version from the link above.
Brilliant! Thanks.
Hi,
I have tested latest build with a few recent games made with Superglús, and it seems to work fine (Oggvorbis sound included).
I have also tested it with the oldest Superglús game I can remember and it works too, what means:
Thanks for testing and pointing out the ROM issue. I didn’t even know, that Glulx has a ROM. I could create a switch in the properties, that turns this behaviour on or off. This way users, who want to play the old Superglús games and know what they are doing, can turn writing to ROM on.
Could you provide me with a game, that exhibits this bug?
I’ve always thought this to be the best solution overall in any software. I wish iFrotz would do it… and I wonder whether Git or Glulx wouldn’t benefit from that approach, instead of having two different executable files (I’m not complaining, because hey - we DO have two different executable files, so it is possible to play those superglus games).
I’d rather have two executables because every additional test on memory access slows down execution. Making the test optional based on a preference slows it down more, because then you need two “if” statements instead of one. Making it optional based on a compile-time setting means putting the “if” in an #ifdef, so it disappears entirely when configured off.
In interpreted languages, the situation is different, of course.
It isn’t like that in Java (and most other languages). I can combine both tests in a single ‘if’. The compiler optimizes this very well. And if the first test fails the second will never be evaluated. Therefore there is very little additional overhead. And Java doesn’t have a precompiler, so there’s no #ifdef.
I still think it would be worth doing in Java – combining "if"s is just a syntactic transformation, it’s the same amount of work. However, not having a preprocessor makes it a hassle. And you get to decide whether it’s actually worth it, of course. 
Supporting two versions most certainly is not worth it. As an alternative I could use two memory classes: one safe, one unsafe. I could switch them without problem, even during runtime, as long as no game is running. Actually that sounds like a good idea 
.
If Zag can use Java’s JIT then the cost of the tests will disappear.
Is there a reason, why it shouldn’t be able to use the JIT?
I don’t know but I’d guess it would use it unless you turned it off somehow.