kdarling@hobbes.ncsu.edu (Kevin Darling) (03/15/91)
In response to email: A little more info on Animator FLI files. The frame speed is related to 1/70th second ticks. All chunks I've seen were padded to even sizes; so if you simply save the position of each chunk and its size before decoding it, then you can easily skip to the next chunk when you return from doing one. BTW, watch out for frames with zero chunk counts (I think they're placeholders left in accidentally). FLIs are not double-buffered, tho a few have large enough delta chunks that on slow machines you might want to convert them to that. That's all the docs I have on FLIs themselves. I know on CIS there is sample C source code (on PICS forum), but I don't have it. Sorry. Also, I'm getting a lot of requests for source to the 68K asm FLI display program that I mentioned the other day. I'll be happy to give it out; but no, it's not directly for a Mac or Sun or ?... I quickly wrote it to help demo a new personal not introduced yet, running OS-9/68070. However, as it's all plain 68000 code, you should be able to easily hack at the source. You will need to add code to allocate space to load the data (and load it)<g>, any video setup, and code to store extracted palette data into your hardware. The program itself directly writes delta video bytes to screen memory. Which means: FLIs are meant for a 320x200x8-bit chunky-pixel pseudo- color display with 6-bits per R,G,B in the palette. The program ran on a machine with a matching 8-bit/pixel display, 8-bits/R,G,B palette. Rendering to different style displays is up to you :-). Most FLIs don't animate palette data, so you could do lookups or conversion for direct color displays pretty easily, I'd say. I'll post the source on _alt.graphics.pixutils_ within a couple of days. Followups there, too. Regards - kevin <kdarling@hobbes.ncsu.edu> <76703.4227@compuserve.com>