Calypso, a PunyInform benchmark

Authoring Inform 6
1

Calypso is a game written by Dave Footitt. He wrote it using Inform 6. We collaborated to make it compile using PunyInform as well. The game has ~25 locations, a few NPCs, and 70+ other objects.

I’ve now worked with Dave to update Calypso to use the latest PunyInform version, the latest standard library version, and the latest compiler. I also put in some excellent abbreviations produced by ZAbbrev for good measure (Thanks @heasm66 for this lovely tool!) .

The game is currently available as three different Z-code files:

  • Inform 6 z5 version, 74 KB
  • PunyInform z5 version, 43.5 KB
  • PunyInform z3 version, 42 KB

The different versions are close to identical in how they look and play. The Inform 6 version groups some static objects together in text in one location (e.g. “You see three stones here (yellow, green and red).”), while the PunyInform versions don’t. They could have, but it would have made them 1 KB bigger, and I thought the gain in functionality wasn’t worth the increase in size.

I tried running our Z-code interpreter Ozmoo in benchmarking mode, automatically playing through the game in 137 moves, and measure the time it took. I did this on an emulated Commodore 64 with a 1 MB REU (Ram Expansion Unit), which works like a RAM disk, i.e. a crazy fast harddrive for caching the entire story file. This means the slow disk drive of the C64 doesn’t play a part in these benchmarks, as the time measured is from the first prompt to the end of last move, and the story file is cached to the REU before the game even starts. So, how much time did it take?

  • Inform 6 z5 version: 1478s, or 10.8s/move
  • PunyInform z5 version: 184s, or 1.34s/move, i.e. 8 times faster than Inform 6 version
  • PunyInform z3 version: 173s, or 1.26s/move, i.e. 8.5 times faster than Inform 6 version

This makes the PunyInform game play at a quite enjoyable speed on a 1MHz 8-bit computer like the C64, while the Inform 6 version does get quite tedious. The difference in speed gets a lot bigger without an REU, as the Inform 6 version will need quite a bit of swapping from disk, while either PunyInform version fits in RAM.

If one moves up to a 16-bit platform like the Amiga 500, the CPU is clocked 7x faster, but interpreters are typically written in C instead of assembly, so the actual speed is probably more like 2-3x faster than a C64. At this speed, the PunyInform version will still be a lot nicer to play. Once you move to clock speeds of say 20-30 Mhz, moves are quite fast enough in the Inform 6 version as well, and at 100+ MHz, both would appear to repond instantly each move. Modern computers typically run at 2000+ Mhz.

The game, both source code and binaries, is available at GitHub - dave-f/calypso: A simple text adventure written using Inform

12 Likes
2

I note that a mid-late 16-bit platform can kept the interpreter and story file entirely in RAM, with the possible exception of mess-dos <6.x with large .z8 files (DOS frotz 2.55 is just below 100 kbytes; plus a full 512 kbytes .z8 story file are 612 kbytes, too unconfortably nearby the absolute maximum of 620 Kbytes) and this contribuites to the speed as the C64/128’s REU.

(back then I played SG infocom games on an A500 with 512K chip RAM and 512K of slow (trapdoor) RAM, and I never got disk readings during the sessions, a major plus if one remember the slowness of Amiga floppies…)

Best regards from Italy,
dott. Piergiorgio.

2 Likes
3

I think, that overhead of C language implementation of interpreters is very small, especially when using modern C compilers. The C code is translated to assembler using natural registers and addressing modes (by natural I mean, that in C variables can be put to data registers, and there are pointers, which are stored in address registers).

I know 680xx assembler and met some tricks, usage of special CPU instructions, but in time-critical games. Usually such constructions can be written in C with minimal overhead.

Note that the CPUs apart clock rate, vary in instruction set, number of registers available, instruction and data cache size, execution time of instructions and presence of special technologies.

On Amiga CDTV, the text-adventure games were very enjoyable. I owned this model back then. Now I have Amiga 1200 with hard disk drive, additional RAM and 68030/50MHz processor and playing such games is comfortable.

I believe Commodore 64 can run such games quite fast (1MHz can be enough for platformers, strategy and RPG games), unfortunately I didn’t play many text-adventure games on this hardware.

Never thought of making benchmark - in my opinion, the response time of text-adventures should be OK even on 8-bit computers.

I thought about comparison of authoring systems, but it’s tricky since every system is unique. It was when I heard about PAWS, Quill for the first time. Every author has his/her favourite tool.

1 Like
4

ha! you obviously haven’t played my punycomp entry from last year (“the candy striper of st. asterix”). i wrote it using the punyinform library but was very naive at the time and made NO attempt otherwise to adjust anything to speed things up for 8-bits. i’ve got wandering NPCs, NPC pathfinding, tons of daemons running amok in the background. the game is laughably slow if played on an out-of-the-box C64. if you listen closely you can hear the computer actually crying.

4 Likes
5

No, I didn’t play your game from PunyComp. I have followed PunyComp (played Garry Francis game with the captain theme). I understand that usage of modern library with loads of daemons can make 8-bit computer struggle with the execution of the code.

I have only experience with ADL, AdvSys for Amiga. Note that the mentioned PAWS and Quill are native for 8-bit computers (ZX-Spectrum) and runs OK. Native is often faster.

1 Like
6

You’re probably right that efficiency of C programs on the 68000 can be quite good, depending on how good the compiler is of course.

I’m a lot more familiar with the 6502, which is known to be a notoriously hard target for C compilers.

2 Likes
7

I think the key factor is that PAW and Quill are more limited - the game author doesn’t have access to a full programming language, but to a certain set of variables, flags and predefined checks. Also, the parser is limited, and written in assembly, so parsing is fast but not very extendable.

The parser and the world model in PunyInform are implemented in Inform (with minor parts in Z-machine assembly), and after compilation it’s all Z-machine assembly. Executing Z-machine assembly instructions is about 100-200 times slower than executing native assembly instructions on the C64. This is why it gets a lot slower than Quill, but this is also why it’s so much more flexible and powerful. It’s a tradeoff, for sure.

3 Likes
8

Yes, of course I was refering to 68000 family processors in my reply to your message (where you mentioned about Amiga 500 and C / assembly interpreters).

I don’t know 6502 processor good enough - but I recall it has much fewer registers.

What I wanted to point is that PAWS and Quill were designed for 8-bit computers at that time, thus they are fast and responsive on their architecture.

PunyInform is a superb project, and it’s very useful to work on 8-bit computers. It bases - partly - on adaptation of modern library - with optimization. The scale of 8-bit computers requires the programs to use some less resources than the next-gen machines.

More features and functions of PunyInform is OK, however I think that PAWS and Quill offer so many features, used by nowadays authors and they are more than enough.

As of Z-machine assembly - it’s very interesting information.Like I mentioned, such machine-state work with ADL which was written in C (I’m almost sure it was targetted to 16-bit Unix, MS-DOS and Amiga).

I’m not sure, but Z-machine was designed with 8-bit or 16-bit computer in mind?

Thank you for interesting discussion and info.

1 Like
9

The Z-machine was designed in 1979 (on a napkin in a restaurant actually), and the goal was to design a virtual machine that would be suitable for playing Zork on the computers which had started to make their way into people’s homes, e.g. Apple II, Commodore PET. These computers were typically 8-bit machines with 32-64KB of RAM.

Since the memory of the target machines was so small, they also needed to add virtual memory handling (AKA paging). This was the first time ever this was done on micro computers. When using a virtual machine, this is quite doable. Had they opted to compile to native code, it would have been a different story.

(Yes, good discussion!)

3 Likes
10

Thank you for answer and information. So I guess that first Z-machine interpreters are capable to run seemlessly on 8-bit computers. I think that some later generations of Z-machine can do this as well.

As I said, Professional Adventure Writer and Quill and some other systems (DAAD for example) are used widely by adventure authors (for example Gareth Pitchford and other friends from the Facebook group). They are equipped with all important functionality, including variables, messages, actions, vocabulary, rooms and items.

They offer native functions, designed to work on these computers. Inform 6 + PunyInform library as a late generation of Z-machine requires adaptation - I guess.

This is a different thing to adapt the 16-bit system (like later generation of Z-machine) to work with 8-bit, than designing a system especially for 8-bit system.

I don’t support 8-bit myself, as I’m only the ADL, AdvSys games author. :slight_smile: If I were into 8-bit, I would try PAW or Quill (or DAAD), either is available for Commodore 64. For now I have too small knowledge about these systems. If I were into new popular system, I would try Inform 6.

I like learning various authoring-systems in general.

2 Likes