CompuServe Thread

#Flick Trouble

8 messages in this thread
#98048From: Black Belt SystemsJan 2, 1995 6:44 PM
I'm using AutoDesk's "AAPlay"… AutoDesk designed the FLC format (and FLI).
#98093From: Stephen SponagleJan 3, 1995 11:53 AM
Autodesk Animator has been recommended to me for creating .flc's. If I can't get IM R/t's .flc to work, I'll get the man to buy Animator and import the frames. Hey… maybe, perhaps there is some sort of header information required. If IM R/t's .flc's play in Animator, maybe resaving them, there, will write a header that Authorware and Premiere expect to see. Authorware's error message comes up when trying to load the .flc, it says Error: File does not seem to be the type specified by the extension (which I have as .flc) or is not recognized. Premiere's error message on loading states the file is corrupted or is in use by another program.
#98106From: Black Belt SystemsJan 3, 1995 2:25 PM
In use by another program? Egads. Sounds like Authorware is well and truly confused. Now regarding animator, mind you, I've only tried the player – I don't have, and have not tried, Animator itself.
#98107From: Stephen SponagleJan 3, 1995 3:21 PM
When a file looks to be in use (btw, that error was reported within Premiere), it usually tells me that the file wasn't properly closed or completed. I know that Authorware plays .flc's… it was demonstrated to me… .flc's created in Autodesk Animator. Now can you imagine Macromedia's response when I call them and explain that Authorware must be broken because it won't play .flc's created on an Amiga? And then I'll call Adobe and tell them the same thing about their Premiere. -Steve
#98115From: Troy BarlowJan 3, 1995 6:28 PM
I've seen a similar flc problem in other programs on the PC. I think it was related to two things. First there is a field in the header that should be set to 3 (I think it's 3). This field is used to determine if the flc was closed properly (the header reflects the data). This might be your problem. Second, the frame count included the ring frame, and it shouldn't. There are really numframes + 1 since all animations must include a ring frame. No likely your problem but what the hey. Frames are stored as follows in a 2 frame FLC (numframes = 1): FRAME 0 (RLE compressed) FRAME 1 (SS2 deltas to apply to FR0, resulting frame is FR1) RING FRAME (SS2 deltas to apply to FR1, resulting frame is same as FR0) A player will display FR0, then loop on FR1 and the RING FRAME. Frame 0 is no longer used. One other problem I've found was Autodesk Animator Pro will crash if you create a FLC that has a custom block of data just before the first FRAME chunk. You would think a player would skip over unknown chunks, and most do, as long as it's a unknown "subordinate" chunk and not another type of frame chunk. Very strange. I found this out while creating FLC's that had a custom Audio chunks in them, I made it a sub chunk and the problem went away! For instance take this FLC: HEADER SETTINGS CHUNK TYPE (AutoDesk settings (optional)) FRAME CHUNK TYPE PSTAMP SUB CHUNK FRAME CHUNK TYPE PAL SUB CHUNK RLE SUB CHUNK FRAME CHUNK TYPE PAL SUB CHUNK SS2 SUB CHUNK If you stick a custom chunk between HEADER & SETTINGS CHUNKS it will crash some players. Adding sub chunks are no problem.
#98137From: Black Belt SystemsJan 4, 1995 12:38 AM
Thanks, Troy – I'll pass this along to tech and see what they say. –Ben …via AutoPilot
#98180From: Troy BarlowJan 4, 1995 5:40 PM
No problem. If you need any details on the format (or .FLX format) just let me know. Oh yea, one more detail about SS2 compression. Autodesk defines operation bytes in each compressed packet. They define a opcode of < 0 to mean copy WORDS and > 0 to mean replicate a WORD (I might have these backwards). However '0' is undefined in the spec. This don't make sense since if you have to skip over more pixels than fit in one packet you will need another packet to encode the pixel skip. This is a good place to use a '0' opcode in your encoder, and it seems thats what '0' is used for. However an opcode of 0 will break some (most?) players on the PC (even some versions of aaplay). If you use a '0' opcode for this reason, try breaking the skips up instead. Really they should fix the broken players out there, but at least this can help avoid the problem. In other words, don't create packets that contain nothing but a pixel skip even though it seems legal. Try loading a FLX file into AutoDesk Animator Pro someday and watch it crash! Also, I'm sure your aware of the 4,000 frame limit in FLI and FLC files 🙂 And FLI, if you create them, must be 320 * 200, unlike FLC.
#98191From: Black Belt SystemsJan 4, 1995 11:54 PM
Thanks again Troy – anything else you think of, just pass it right along. 🙂 –Ben …via AutoPilot