Yep that’s what I meant. I haven’t thought about any of the details yet or whether anything else would be needed.
1 Like
I’m curious what critical features were in z5 that you couldn’t live without? In Dialog’s case, I think it was the throw/catch opcodes. Given you already have native support for German and Spanish, perhaps it’s the ability to redefine the alphabet table?
Thanks,
-Dave
It was an easy decision actually. z5 has way less limitations and there is now a good Z-machine version 5 interpreter available for any of the major 8-bit and 16-bit targets, so there is no need to stick with z3 for targetting retro platforms. All these terps can be bundled using my Puny BuildTools (soon to be rebranded to Z-machine BuildTools when they get Arcturus support). And also the opcode for arc_image is something you only can do in z5.
The languages ride in the standard ZSCII table and the logic for the parser comes from the language .granule file.
1 Like
Fair enough. There are some retro platforms without disk drives that would fare better with a z3 target, but I get that’s really splitting hairs.
There are some things you can do in z3 that you can’t necessarily do as well in z5 - objects are smaller, dictionaries are smaller, and any list of objects in a property is guaranteed to be 8 bits per slot. (Granted, you could do the latter optimization even on z5 if you knew the game had fewer than 256 objects in it).
z5 doesn’t waste two bytes per parameter in the routine header for default parameter values, and also has special opcodes for 1 and 2-parameter routine calls which swings the pendulum back in its favor a bit too though.
-Dave
1 Like
Yeah, Dialog’s (fail) and (stop) system relies on @throw to escape from a deeply-nested stack of routines. That’s the one thing it really can’t do without.
1 Like
Hey sorry for replying late to this. I must have missed this post yesterday and only stumbled upon it now after reading the thread again.
I would think that fairy gold or an ice cube may be a less common use case but I understand of course that this is a metaphor. And yes, what you describe is exactly what I mean when referring to intelligent containers. I will argue now that the percentage of items in containers that will magically vanish is significantly lower than the percentage of items that stay static in it. So for the majority of of objects that may be put into a container, the feature is genuinely useful. For those moments where it is not, you can alway override the way the container presents itself. You are in full control if it lists or not.
I personally would model the melting instead of just deleting the object, and the leak stops being a leak. Something like this:
counter melt
on each_turn when cube in cooler
change melt to melt + 1
if melt is 3
say "You hear a small slump from inside the cooler."
if melt is 6
move cube to nothing
On a side note you could also do it like this:
after 3 turns do melt_cube // once, three turns from now
every 4 turns do melt_cube // every five turns, indefinitely until vanished
Now the player gets a plausible narration. The listing changing afterwards is the consequence of a thing they heard.
Oh… TAKE ALL and DROP ALL: no work at all, they’re already there. One line:
summon.takeall
gives you TAKE ALL, DROP ALL, and TAKE ALL FROM . They’re in a granule rather than the core on purpose: TAKE ALL often flattens a scene into a loot sweep, and I’d rather let an author opt into that deliberately rather than have it on by default. TAKE ALL skips scenery and what’s inside shut containers; DROP ALL keeps what you’re wearing.
1 Like
Implemented and pushed. arcimg now adds the ARCI chunk to every .blorb it produces:
'ARCI' length 2
+0 1 extension version (currently 1)
+1 1 band mode: 9, 12, or 0 = not declared
I guess this is straightforward. It says that this Blorb holds pictures for arc_image, and gives the version of the extension they were made for and the band geometry: 9 lines (320x72 pixels) or 12 lines (320x96 pixels).