Re: LZ: New idea for compression program!
[Prev][Next][Index][Thread]
At 03:30 PM 9/9/96 -0400, you wrote:
>On Sun, 8 Sep 1996, Scott J. Rein wrote:
>
>> Last, we have a choice: either the program can be run like a normal ZShell
>> program, or we can give the shell out as an 85B file so that it contains
>> both a pointer to ZShell AND the shell. We would have to get permission
>> from whoever made ZShell (to be able to distribute ZShell with our program)
>> for the latter choice. This would be my choice though.
>
>A better (?) way would be to make the decompressor run from ZShell, and have
>the identifier byte that ZShell uses be different than that one, so the
>decompressor knows that's what these strings are. Now, this program would find
>all compressed strings, and display them like ZShell. It would be able to use
>a multi-column format, since you would not get the description like in ZShell.
>This program will simply decompress the string to a temporary one, and run it.
>We should try to do this fast, and then work out what to do with saved games
>and highscores, because it sounds like the best way is to change the way the
>program works. So, if we release the compression stuff, and very few people
>end up using it, then the programmers do not have to worry about it. If many
>people start to use it, then maybe it will be added into ZShell, and all games
>that wish to use compression (All of them I hope) will be changed to work with
>the new ZShell (5.0?) like what happened with 4.0!
This is a good idea. There is still the problem of updating the
PROGRAM_ADDR information and such before the decompressor actually executes
the user program. Maybe Rob Taylor can tell us what will need to be
modified and what exactly it should be changed to :-). I also agree that it
should be done now, instead of waiting for consent from the game
programmers. I will begin working on the decompressor (and compressor for
the PC) now, but at least four things will be changed later:
- First of all, there will be no actual compression until
someone comes up with the specifics for an algorithm
(everyone on this list is great at optimization, so I'll
leave that alone), but instead, I will make it add some
number to each byte to fake the compression.
- The program will be decompressed into a pre-existing
string (which must be large enough or else there will be
an error message).
- Only the PROGRAM_ADDR variable will be updated (although
this may confuse ZShell and endanger the program (Rob?)).
None of the other program specific variables will be
updated, if there are are any, until we find out if it
is safe to do so and how to do it (Rob?).
- The identifier byte will be $7E for now. I chose this
because ZShell developers have reserved everything from
$80 up (of course if compression is built into ZS 5.0,
then we can use those), and $7F is used by the GCP
format. If there are any other formats using $7E, we
can change this.
So, if anyone has any good compression/decompression routines, put them
on the list and have the optimization monsters :-) eat them up. Then we can
include it.
References: