ZILF 1.6 released

When playing Rascal without color, using Unix Frotz, it’s hard to tell the walls and the doors apart because apparently white is the default color for both? But I can’t figure out if that’s a Rascal bug, a ZILF bug, or a Frotz bug.

Huh. Does pressing C to toggle the color mode help? The walls and doors should only be drawn with backgrounds in true color mode.

If not, here’s the latest build, which has an official “no color” mode.

rascal.z5 (105.4 KB)
source code

Yes, it looks fine in color mode. (I assume)

If I understand `APPLY-SPRITE-COLOR` correctly, in black-and-white mode it ends up doing `<COLOR ,ZCOL-DEFAULT ,ZCOL-DEFAULT>` which to me feels like it should do the right thing. Except apparently it decides that default foreground and default background color are the same? Not that I’ve tried to debug that to see if that’s what’s actually happening…

I see the same wrong behavior in “true color” mode, but maybe Unix Frotz in text mode doesn’t support that? “Classic color” and “no color” look fine, though. (Except I seem to run into some rendering bug that causes the upper half of the map to be erased.)

The modes in the version included with ZILF 1.5 are “true color” (default, if available) and “Z-machine color”, so the one that works is actually the Z-machine color mode.

It looks like Unix Frotz claims Standard 1.1 compliance but doesn’t support true color, and instead of mapping true color to the closest Z-machine colors as suggested in the Standard, it seems to be treating any background color as white. The wall background is a pretty dark brown that I’d expect to map to black:

Hmm. I’ll have to start testing with Unix Frotz. For now, opening any popup (T/I/G/Q/?) and exiting it should force a full redraw.

Ah, I must have misread the instructions then. Oops!

Doesn’t seem to work for me with the newer version. Compiling the one from 1.5, I don’t see this problem though:

1 Like

Which version of Frotz are you running? I can reproduce the bug with 2.56pre (built from master), but not 2.55 (built from the tag) or 2.54 (packaged with Ubuntu). I suspect it’s a Frotz bug.

I guess it’s 2.56pre, because I compiled it from the latest git version. Though it introduces itself as 2.55pre.

1 Like

Version 1.6 is now available for download with more parser improvements (mainly for stacks of indistinguishable objects like you might encounter in (the also updated) Rascal), status line layouts for small screens (inspired by a thread here), a couple previously missing opcodes, and the usual optimizations and bug fixes.

5 Likes

Is there a way to see which parts of the files have changed since the last update?

You could try the standard diff utility (on Linux, Mac, or WSL) or something like KDiff3.

2 Likes