Re: Portability of games (was Re: Limitations of Inform and TADS?)


Mon, 13 Nov 1995 21:15:06 GMT

In article <weybtowy20.fsf@iasc3.scm.liv.ac.uk>,
Bruce Stephens <bruce@supr.scm.liv.ac.uk> wrote:
>>>>>> "Mathematical" == Mathematical Institute, (01865) 2-73525 <nelson@vax.oxford.ac.uk> writes:
>> The Z-machine can be implemented pretty quickly. I can't, offhand,
>> think of a good way of improving speed by any significant margin,
>> given the compactness of the format. We probably could soup up the
>> text compression rate, but (again) that's probably not going to be
>> needed enough to make it worthwhile.
>
>I think the compactness is my concern. The Z-machine could be speeded
>up by moving some of the information that's packed so carefully into
>separate bytes which can be operated on more quickly. Of course, this
>would probably create larger codes, and so would only be of benefit on
>machines (like the Psion) which couldn't really use it for space
>reasons.

On the interpreter end, there are a couple of things that could
be done to speed it up. (Of course, with freely available source, anyone
can implement these as they choose.)

o) Optionally removing the VM-ish paging. (This was done by
Stefan Jokisch but isn't in the main ZIP distribution.) This of course helps
speed things up on machines with 24 or 32 bit addressing and enough memory to
hold the whole datafile in memory at once. Optionally (at compile time)
since it's obviously preferable to leave it in for those that want it
(willing to trade time for RAM usage) or need it.

o) Changing the main interpret() loop to being a function-pointer
based dispatch, which definitely is constant speed no matter which
Z-machine instruction you're emulating.

There are probably many others, but these are the most obvious that
can be done while still maintaining portable C code.

-- 
unknown@apple.com		Apple II Forever
These opinions are mine, not Apple's.