Esprit de Apple Corps/EDAC-2.iso/Graphics/Apps/Programs/LHG/readme.txt

Text File | 1992-10-18 | 5.7 KB | 92 lines

Lord High GIFfer (prototype)
by Todd Whitesel
GEnie special release 18-Oct-92
Code freeze date 4-Mar-92
USE AT YOUR OWN RISK.

Ok, due to popular demand and the fact that the real program is still at least
a few months off, I am releasing this sucker into the libraries so everyone
can have fun with it. Just remember that I have rewritten over half of it
already and plan to rewrite the other half in the next few months, so what
you are looking at is strictly a "first cut" design prototype that I made so
I could investigate what sorts of things worked and what didn't. I hesitate
to even call this an Alpha version, as some people have suggested. This code
was frozen just as I was stepping back from the project for a while in order
to figure out what directions it should go in. Originally I thought I could
get away with far fewer changes, but that bad judgement call and the rest of
my life have been what's kept LHG from being completed by now.

This version of the code has some known problems and limitations: number one
is that only shell arguments and finder icons are supported. To use it with a
shell, make sure LordHighGIFfer's filetype is EXE and give it the pathnames of
gif files to view as arguments. To use with the finder, create */apps/ and put
LordHighGIFfer there or edit the icon if you are using system 5. (With 6 you
can just remap the icons and put it anywhere you like.) The LHG.icon currently
recognizes both TXT and BIN files ending in ".gif". Finder doesn't seem to mind
it being an EXE instead of an S16, so I don't see any benefit to changing it.
If you try to launch it directly, it will quit without doing anything.

Number two is that the memory allocation is yucky. Basically what it will do
is allocate a single huge block from the memory manager to load in the GIF.
Then it will allocate another huge block to decode the image into. With large
pictures this can easily run into problems on 1 meg systems and even on four
meg systems (like mine) if the picture is huge. If it appears to "skip" a
picture, then it is likely that it couldn't allocate enough memory. "Shift
booting" and other fun techniques can be used to deal with this if you really
want to view something that barely fits. I had to rewrite the decompressor
from scratch to alleviate part of this problem, and I still have some GIFs
that are so huge I still can't view them without rewriting it again (which
won't happen before the 1.0 release because, naturally, I would like to get
that finished before the decade is out).

Number three is that its error-handling is sorely lacking (if not totally
absent). If it has a problem decoding it will simply stop and let you view
what it got, which means that you'll see part of a picture and then lots of
random gunk that happened to be sitting in memory. Until recently this would
_always_ be caused by an incorrect or corrupt GIF; however James Brookes has
found a GIF that the prototype aborts about 3/4 of the way through but that
my new decompressor can view just fine. As of today I don't know what causes
it, but by watching the thermo bars it looks like an ambiguous part of the
GIF specification is being tested and the prototype makes the wrong decision.
If you get a picture with gunk in it, please try it on another program or
another system and make sure it is good before you send me a bug report;
I'll try to get the picture and make sure the current code handles it.

Number four is the way interlaced GIFs are handled. Interlaced GIFs are great
for previewing a picture while you download it but they are annoying as hell
for anything else. The prototype's viewer will redraw each frame in the order
it was encoded in the GIF, so for interlaced pictures you get this funky
venetian blinds effect that reminds me of classic HGR slide shows. I haven't
quite gotten to fixing this effect yet, but it will be gone before I ship.
Interlaced picture viewing also has the only true crash danger that I know of;
if it tries to display a picture that is interlaced but is less than 5 lines
high, it will trash memory and crash. Since virtually no _real_ GIF is this
short, the problem only occurs with damaged pictures that look just enough
like a legitimate picture to fool the decoder -- if the damage makes it look
like the GIF contains multiple images and one of them triggers the bug. I only
discovered this a month ago with a damaged picture, and it hasn't happened
before or since, so it's not very likely that you'll run into it.

Number five is the color picker. It is slow. Way too slow. As I write this my
current project is making it faster and adding some extra options at the same
time. If you don't want to wait for the palette crunch, just click the mouse
any time during the decoding (i.e. thermo bars creeping) or during the palette
dancing screen and it will go straight to a visible-intensity-to-graylevel
convert (this picks the brightness of each color according to color theory, by
adding in 30% of the red, 60% of the green, and 10% of the blue, and usually
looks more natural than the picture you get with 33% of each).

Lastly is the interface. It has none. You get the thermo bar, the dancing
palette screen, and the view screen where you can use the mouse to move around
in the picture. Click once to go on to the next picture. It doesn't have an
exit key (sorry) but the CDA panel should be accessible anytime except while
it's decoding (this is because I wasn't calling GetNextEvent often enough).

Ok, I think that about covers it. Just remember, if there's something you don't
like about it, you're probably right. But I hope you like it anyway. It took
a lot of work to bring the program to even that point, because there are a lot
of nonobvious things that I was trying to get working, and I didn't spend too
much time polishing the things I was already planning to rewrite.

Todd Whitesel