Flic Images

Pro Motion trial doesn't support the saving of files in the flc format.
Unless you want to drop 60 USD on an ap that can make leader heads, i'd not waste your time or your loot.

We're still screwed on units for the time being, anyway.
 
Hello everyone! I just discovered this thread. I've been dissecting the Civ3 FLC format myself and have figured out a few things. If you're a programmer, this may be useful to you, but it probably won't do you much good if you just want to mess with the graphics.

First, you need to understand the standard FLC format. Although Civ3's format is nonstandard, it is heavily based on the standard format. An excellent FLC format reference is at http://www.compuphase.com/flic.htm. This company makes a product called EGI, which itself uses an extended version of the FLC format. Civ3 does not use any of the EGI-specific constructs.

Now here's what I've discovered about the Civ3 FLC files. So far, I've only looked at the unit FLCs, but I'm starting to look at the other FLCs to see what clues they provide:

Firaxis is using the last 40 bytes of the 128-byte FLC header (officially marked "reserved") to store its extra information. For the purposes of my dissection, I broke these 40 bytes into 20 WORD fields labeled Unknown1 through Unknown20, and came up with the following conclusions:
Code:
Unknown1:        Always 28 (0x001C) (?)
Unknowns 2-4:    Always 0 (not used)
Unknown5:        Number of unit "orientations" in the FLC
Unknown6:        Number of frames per unit "orientation"
Unknown7:        ?
Unknown8:        ?
Unknowns 9-10:   Always 240 (0x00F0) (?)
Unknown11:       ?
Unknown12:       Bitfield representing the particular orientations
                   present in the FLC?  (0x0001 when Unknown5 is 1,
                   0x00FF when Unknown5 is 8)
Unknowns 13-20:  Always 0 (not used)
The number of frames reported in the header is not the real number of frames: There is one additional frame (a ring frame, I presume) for each orientation, so in a FLC with 8 orientations and 10 frames per orientation, 80 frames are reported in the header, but the file actually contains 88 frames.

The last 8 colors in the palette are used for shadow (alpha-blending) information. Color 255 is fully transparent; color 248 is the least transparent (though not opaque). Don't know what the precise opacity values should be (probably isn't important, anyway), but I'm assuming a linear progression from darkest to fully transparent.

The first 64 entries in the palette are used for civ coding. These colors are replaced with the last 64 entries (in reverse order) from the palette of one of the PCX's in the Palettes subfolder.

Finally, the main thing that has been causing most programs to crash and burn upon attempting to read in the FLCs is probably the fact that the Size field of the FLC chunk header is sometimes bogus - this is particularly true in the case of COLOR_256 chunks, which always have a reported size of 3,452,816,845 (0xCDCDCDCD) regardless of their real size (a full 256-color palette should report a size of 778).

In the file Tact_AttackA.flc, an FLI_COPY chunk (this is the only unit FLC that has an FLI_COPY chunk) is reported to have a size of 506. This *should* be correct (the animation is 10x50 pixels for 500, plus the 6-byte header), *but* the chunk is followed by 16 (meaningless?) bytes of 0xCD. After that is a COLOR_256 chunk (which starts with 4 bytes of 0xCD for the size). My interpretation is that perhaps COLOR_256 chunks are always preceded by some unknown number of 0xCD bytes? So the read process would be: If you find 0xCDCDCDCD where you're expecting to find a chunk length, keep reading until you find a COLOR_256 chunk?
As I suspected (and Dan Magaha just confirmed), the X and Y offsets are in there somewhere, too. I'm guessing Unknown7 and Unknown8 contain those values, though I'm not convinced of that yet. If there are any other programmers out there, please post your own findings.
 
Adobe preimere 6.0 will also view the files. I don't know if it can edit them, but I would assume it could
 
If you try to load a FLC in that doesn't have the extra header information, the game will "fake" a header -- when it does this it assumes the number of directions is 1, among other things. This is why "normal" FLCs will work as leader heads, because the game expects only one "direction".

Trying to do the same thing with a normal FLC as a unit will crash the game because it assumes the number of directions is only 1 and the game requires 8 directions for units.

SWB, I did forward your e-mail onto our resident graphics guru and if he gets time he may fill in the blanks with what info you're currently missing about our custom headers. Nice work on the file format, BTW :eek:


Dan
 
Nice work on the file format, BTW
Thanks! :)

As I learn and/or receive more details, I'll post them here. When the format is completely mapped out, I'll produce a detailed reference and submit it to CivFanatics.

I also plan to produce a utility program to edit, compile, and decompile Civ3 FLCs. It's possible (perhaps even likely) that Firaxis will release such a tool first, however.

By the way, if any of you are interested in tinkering with the Intro, Space Race Win, or Security Briefing movies, they are in RAD Game Tools' Bink format. You can use their free RAD Video Tools program (http://www.radgametools.com/bnkdown.htm) to play, convert, or create BIK files. This program also works with FLC files (and many other animation formats). It mostly works, but not completely or perfectly, with Civ3's FLC files.
 
We must have some tools before we can make new animations or art, and there must at least be freeware or shareware tools available, else the modification community would be very small

:(


Pro motion is a no go (to expensive) for regular ppl wanting to fool around with game graphics

If somebody finds an alternative software, which is free or shareware then plz post




This is a demonstration of the animation/drawing software "PRO MOTION"
by Cosmigo.
To get started please have a look at the online help sections
"Getting started" and "What is PRO MOTION?". There you will find basic
informations helping you to understand the software.
If you continue using this software for more than 30 days please
buy a user license or remove it from your computer.

The following functions are not available in this DEMO
* saving of the file types .flc, .pcx, .bmp, .lbm, .iff, .png, .tga
* data export via clipboard

The DEMO only supports data output via the following file types
* .jpg (JPEG image files)
* .avi (Windows AVI Stream)
* .spr (full sized Sprites)
* .ani (32x32 Pixel Windows animated Cursor)
* .ico (Windows Icon)
 
Originally posted by Qnuc.dk
We must have some tools before we can make new animations or art, and there must at least be freeware or shareware tools available, else the modification community would be very small

:(


Pro motion is a no go (to expensive) for regular ppl wanting to fool around with game graphics

If somebody finds an alternative software, which is free or shareware then plz post





Agree, hope Firaxis is not completely stuck to ProMotion. Firaxis is listed first in the professional users list for Promotion on the Cosmigo website.

Dan, appreciate your input a lot!!! :goodjob: :goodjob:
 
Well, that sorta sucks, doesn't it? I didn't realize the trial didn't save FLC's. Sorry about that one, I'll see if I can find something else.

Very few people in the office still use the program (apparently they used it back in the SMAC era :) but I found, somewhat by accident, that it would read our FLCs when most other programs wouldn't.

At the very least you can use the trial to extract the FLCs to a series of single images, which is what I use it for (mainly for the website). As I imagine creating unit art isn't an overnight process, it'll at least get you going in the right direction as far as image dimensions, palette, and that sort of thing.

I'll keep you posted if I find anything else that might help.


Dan
 
I'm not sure why or how Pro Motion could be better than any other flc capable editor. Any editor can do leader FLCs, and no editor can do unit FLCs. I don't think anyone has suggested that Firaxis is going to come out with an add-on to Pro Motion only to handle the unit FLCs. It seems like SWB is saying all we need to know is what the special fields do and then you can fix a standard FLC with merely a hex editor right? (Although a tool to do what would be extremely useful!)
 
Don't get me wrong, Pro Motion isn't anything special, it's actually pretty flaky as graphics editors go. But, the FLC format isn't especially universal, so I haven't come across a lot of cheap or free tools that can read and write FLC's, especially with our modified header file format.

I thought the trial version would allow people to get started with leader animations and for free. Now that I know you can't save FLC's it's utility is reduced pretty much to converting FLCs to a series of single images, which isn't especially useful in and of itself :(

Dan
 
I've mentioned it a few times in this thread, but I'll mention it again -- PaintShop Pro, the most popular graphics program on the market, includes flc editing through the included AnimationShop. I own it, but I'm pretty sure the 30 day trial includes full capabilities for both programs. I've had no problem loading and saving .flc files, although the saved ones don't work in the game, for reasons we've already covered. Animationshop doesn't include paletting capabilities, but you can export/import on the fly to Paintshop, which does.

For SWB or Dan Magaha, would it be possible -- until we figure out a simple way to edit the header info -- to 'cut and paste' the appropriate portion of the header material from an original Fraxis flc file into a custom-saved flc? I'm no expert, but I've used hex-editing programs to alter settings in proprietary formats before -- maybe SWB can give more info on how to isolate the appropriate 'header' data and transplant it?

If we could do this, it would be easy enough to make custom units by just fitting them to pre-existing animation frame sizes, numbers, etc. I think there are enough choices out there to allow for plenty of variation.

Armor
 
For SWB or Dan Magaha, would it be possible -- until we figure out a simple way to edit the header info -- to 'cut and paste' the appropriate portion of the header material from an original Fraxis flc file into a custom-saved flc?

Unfortunately, no. For one thing, the header has meaningful data in it that might not be correct for your custom FLC (such as X and Y offset). There's a more fundamental reason, though, that requires a bit more explanation:

Here's the layout of a normal, 5-frame FLC file:
  • Frame 1: Full frame
  • Frame 2: Delta frame
  • Frame 3: Delta frame
  • Frame 4: Delta frame
  • Frame 5: Delta frame
  • Ring Frame: Delta frame
As you can see, there are actually 6 frames - five "regular" frames and a "ring" frame - and two types of frames - "full" and "delta." A full frame includes every pixel in the frame. A delta frame includes only those pixels that are different from the previous frame. The ring frame is used to loop back to the beginning - it's identical to frame 1, but it's encoded as a delta from frame 5 (it contains only those pixels in frame 1 that are different from frame 5). When playing back an FLC file, frame 1 (the full frame) is read only once, at the beginning; everything after that is delta frames, with the ring frame substituted for frame 1:
  • 1 - 2 - 3 - 4 - 5 - Ring - 2 - 3 - 4 - 5 - Ring - 2 - 3 - 4 - 5 - etc.
Civ3 unit FLCs are like several standard FLCs concatenated together, in that each "orientation" has a full frame followed by several delta frames and a ring frame. A unit FLC with 3 orientations (a real unit FLC would almost certainly have 8) and 3 frames per orientation would look like this:
  • Orientation 1 Frame 1: Full frame
  • Orientation 1 Frame 2: Delta frame
  • Orientation 1 Frame 3: Delta frame
  • Orientation 1 Ring Frame: Delta frame
  • Orientation 2 Frame 1: Full frame
  • Orientation 2 Frame 2: Delta frame
  • Orientation 2 Frame 3: Delta frame
  • Orientation 2 Ring Frame: Delta frame
  • Orientation 3 Frame 1: Full frame
  • Orientation 3 Frame 2: Delta frame
  • Orientation 3 Frame 3: Delta frame
  • Orientation 3 Ring Frame: Delta frame
No off-the-shelf software is going to produce FLCs that look like that. A custom tool is required.

Firaxis obviously has such a tool in-house; perhaps they will release it eventually. I am working on my own Civ3 FLC tool, but I need to understand a few more details about the Civ3 custom bits before I can finish it. Once the Civ3 FLC format is fully and publicly documented (which I plan to do, once I know all the details), other programmers will also be able to write programs to work with the files, and I hope they do.

In the meantime, those of you who would like to create Civ3 unit FLCs just need to be patient. The game's brand new; it will take a little while for all the customization tools to emerge. Some of you seem to be taking the position that the game is defective or something because you can't change the unit FLCs. That's not the case at all. I think it's amazing that so many of Civ3's game files are in standard formats - most games that I'm familiar with use proprietary formats exclusively. Firaxis has done a Good Thing by using standard, easily editable file formats wherever possible. The unit animations, however, were a special case: no standard format (that I'm familiar with) would have as easily or as cleanly supported what they needed to do. For this purpose, a proprietary format was truly called for. Even here, though, Firaxis stuck very closely to a standard format - Civ3 FLCs are different enough from standard FLCs that you'll need a special tool to work with them, but they're only different to the extent that they need to be. Any FLC source code out there could be made to work with Civ3 FLCs with only a few modifications.
 
Not sure if this is going to help or not, but I've worked on multiple file formats and animation formats for the game Homeworld, so I have a good grounding in both hex editing and animation formats. (I wrote an editor for Relic's custom MAD animation format).

(My webpage is at http://go.to/delphy and I mainly hang out on the Relic Editing forums at http://forums.relicnews.com/forumdisplay.php?s=&forumid=16)

However, I don't have the game as yet. So, I'd need to get the game before I could contribute to this project, or get one or two FLC files seperately.

Just thought I'd offer to lend a hand. :)

Regards,
Delphy
 
Mike Breitkreutz of Firaxis sent me this today:
The details of our FLC format are somewhat tricky and they are complicated by the fact that there are a few (non-fatal) bugs in the format which have been corrected in the code but not in all of the FLC files (so that the artists didn't have to re-build all of the FLCs). This is probably not the best implementation of a FLC format and I would have done some things differently had I created the format. For example, I would not have used the "reserved" area of the FLC header to store internal data -- especially since the FLC format supports user-defined chunks for just that purpose. Unfortunately, the format already existed when I started working on Civ3 so the format had already been made standard.

The name of our "custom" FLC format is FlicAnim and the header is the FlicAnimHeader. The FlicAnimHeader structure is 28 bytes long and consists of 10 fields. The remaining 12 bytes of the reserved field are set to 0:
  • DWORD size: Set to the size of the FlicAnimHeader structure (currently 28 bytes or 0x001C)
  • int flags: This field is used internally and by our FlicAnim creator and should be set to 0.
  • WORD num_anims: This is equivalent to the number of directions stored in the FlicAnim. This value can be calculated by dividing the total number of frames in the FLC (from the FLC header) by the anim_length (see below).
  • WORD anim_length: This is the number of frames in each direction. Note that each direction must have the same number of frames.
  • WORD x_offset: The pixel offset from the left edge of the image to the clipped sprite (see below).
  • WORD y_offset: The pixel offset from the top edge of the image to the clipped sprite (see below).
  • WORD xs_orig: The pixel width of the non-clipped sprite (see below).
  • WORD ys_orig: The pixel height of the non-clipped sprite (see below).
  • DWORD anim_time: This is the frame rate of the animation. It can be calculated with the following formula:

    anim_length * 1000 / fps

    where fps is the frames per second at which the FLC is supposed to be played. The value is in milliseconds. I'm not entirely sure if this is used.
  • int directions: Bit flags representing which directions are present. If a bit is set, that direction is present.

    Bit 0: southwest
    Bit 1: south
    Bit 2: southeast
    Bit 3: east
    Bit 4: northeast
    Bit 5: north
    Bit 6: northwest
    Bit 7: west

    I believe this was done so that you could have an animation with 4 directions and set bits 1, 3, 5, and 7 so that you have just the cardinal directions (for example). However, I don't think this will work for units in Civ3.
Note

DWORDs are 4 BYTES and are unsigned.
WORDs are 2 BYTES and are unsigned.
ints are 4 BYTES and they are signed.

Clipping

Our FlicAnim program calculates the smallest bounding box needed to contain all of the frames of the animation. The upper-left corner of this bounding box is stored as x_offset and y_offset. The xs_orig and ys_orig are the original height and width of the image (not taking the bounding box into account). I believe all of our units are 240x240 which is why you found these fields to always be 240.

FLC header

The standard FLC header has the expected data except the following:
  • The Size field should contain the total number of frames in the file (num_anims * anim_length). The actual number of frames will be Size + 1 because all FLC files contain a ring frame for looping purposes.
  • The Speed field should be set to 4.
  • The Creator field should be set to 0xF1F1F2F2, which desginates the FLICSPRITE_CREATOR we use to make the FlicAnims. (Note that the FLC specs state that this should be 0x464C4942 if not created by Animator Pro - I'm not sure why this info was ignored).
Palette

Most of our unit FLCs contain a bug wherein the FLI_COLOR_256 chunks contain an incorrect size. As the game knows that all of our palettes are 256 colors, it doesn't cause a problem. It does, however, cause problems in other programs that attempt to load our FlicAnims. Our most recently created units should contain the proper size information.

Compression

I'm fairly certain there is a bug in the FLI_WORD_LC (also referred to as FLI_SS2) compression used for many of the frames as well. I've read differing descriptions of the format that explain the skip count. In some descriptions, the skip count represents the number of 2-pixel words to skip while in others, it is the number of bytes to skip. Our format treats the skip count as the number of bytes to skip.



There may, in fact, be more bugs in the format than I've mentioned and haven't caught yet, so beware. Also, keep in mind that since I am still working on some of these issues, some of this could potentially change (though I don't think it's likely). It's also possible we will make tools available in the near future although the details on that are sketchy at this point.
Note that I would correct Mike's first bullet item under "FLC header" to read:
  • The Frames field should contain the total number of frames in the file (num_anims * anim_length). The actual number of frames will be Frames + num_anims because there is a ring frame for looping purposes at the end of each animation.
I think this fills in most of the blanks that I had. I'll keep you posted on my progress, though there probably won't be any more till the weekend at the earliest.
 
i don´t know what you think about this but
can pro motion be found on direct connect, i´m gonna search for it
 
It sounds like you understood what Mike Breitkreutz sent you, which is great, because I'm squarely out of my depth. I look forward to your progress with great anticipation.

I hope you weren't referring to me when you said that some people act as though the difficulty in creating custom flc files was an error on the part of Fraxis. While I have found it frustrating to run into this barrier, after finding the rest of the game so easy to modify, I share your opinion that Fraxis has done us a great service in leaving so much of the game open to modification. I greatly admire their openness, including their communications to this community and yourself.

Frankly, it's the most admirable behavior on the part of a game developer since Maxis and The Sims (who actually produced a number of custom editing tools themselves, in addition to fostering the largest custom graphics/mod community ever for a game). It looks as though Fraxis has the same attitude, which I find tremendously refreshing after playing so many games in which the developer clearly has gone out of their way to prevent modification, as though that would help to sell games.

Please keep us appraised of your progress, and thank you for undertaking this project!

Armor
 
Big thanks to SWB from this forum, Dan & Mike from firaxis, and everyone else around here. With all the info on this thread, I built a tool to convert CIV III Unit FLCs into standard FLCs and back. The standard FLCs it creates are editable with things like animation shop. The tool is called FLICster, and its pretty beta at this point. Read more on this thread:

http://forums.civfanatics.com/showthread.php?s=&postid=114569&t=8050#post114569
 
Top Bottom