FLI und FLC Erläuterungen und theoretische Grundlagen 

 


1.0 FLI und FLC Autodesk Animator - Aufbau der Files

Die FLC- Datei dient zur animierten Ausgabe von Bildern. In einer FLC bzw. FLI- Datei sieht der Aufbau folgendermaßen aus. Als erstes kommt der File-Header. Dieser liefert eine Kurzbeschreibung der Datei. Als nächstes ein Frame- Header, der die Zusammensetzung der Frames beschreibt, so z.Bsp. 1. Frame:= eine Palette + ein Vollbild, 2.Frame ein Palettenauschnitt + eine Bildänderung. bis alle Frames benutzt sind, dann fängt man wieder von vorn an. Ein Frame, also ein Bild kann aus mehreren Komponenten bestehen. Diese Komponenten heißen Chunks. Bspw, kann ein Chunk ein Vollbild sein oder eine Palette oder ein Palettenausschnitt,...

1.1 Der FLC Header

Eine FLC-Datei hat die Endung 'flc'. Die FLC-Datei hat einen 128 Bytes großen FileHeader. Der Header ist folgendermaßen codiert:
Tabelle 1    FLC Header 
Position 
Typ
Format
Beschreibung 
$00-$03 dword intel Zeigt die Größe der gesamten Datei an
$04-$05 word intel Dateierkennung immer $AF11(Fli) oder $AF12(flc) 
$06-$07 word intel Anzahl der Bilder; Anzahl der Frames 
$08-$09 word intel Bild-Breite in Pixel =320 oder anders bei Flc 
$0A-$0B  word intel Bild-Höhe in Pixel =200 oder anders bei Flc 
$0C-$0D word intel Bits pro Pixel immer 8 oder $0008 
$0E-$0F word intel Ablaufflag bit1=1 am Schluß Beenden; bit2=1 immer Wiederholen
$10-$13 word intel Ablaufgeschwindigkeit
$14-$7F byte intel Reserviert (immer 0)
 

Weitere Erläuterungen zum File-Header sind, daß die DIN-Angaben des File-Headers nicht von allen Files eingehalten werden.Test's haben es bwiesen.  So z.Beispiel zeigt '$14-$7F' meist einen Eintrag von Text (z.B. Hersteller & Datum), also muß es nicht Null sein. Weiter zeigten einige Dateien noch Abweichungen im WORD '$0C-$0D', das die Angabe der Farbtiefe angibt. Einige Dateien haben anstatt $0008 meist $0000 stehen. Der Grund ist mir unklar, ich habe dies nur bemerkt, als mein Programm immer die Fehlermeldung  -->Kein flc<-- Format anzeigte. Mit PV (Picture Viewer unter Dos) liefen die Dateien ohne Fehlermeldung Also scheint eine Einhaltung des Words nicht von Nöten.
Weiterhin haben die meisten Dateien im WORD $0E-$0F den Eintrag $0003. Deshalb gehe ich davon aus, daß es einem jeden selbst  überlassen ist, ob die Datei am Ende neu beginnt oder beendet wird. Der Rest war bis jetzt nicht abweichend von DIN.  Das anschließende 129.Byte ist der Beginn der 1.Frame, mit Beginn Frame-Header.


1.2 Der Frame-Header

Das Frame ist ein vollständiges Bild, das nach jedem Zeittakt neu gezeichnet wird, also "wie ein Fernseh-Bild". Für jedes Bild gibt es einen Frame-Header. Dieser hat eine Größe von 16 Bytes. Zu diesem Header existieren 3 Informationen. Es folgt die Beschreibung:
 
Tabelle 2    Frame-Header
Position
Typ
Format
Beschreibung
$00-$03 dword intel zeigt Größe des gesamten Frames inclusive Header 
$04-$05 word intel Frameerkennung $F1FA für 'Bild' oder $F100 für 'Prefix'
$06-$07 word intel Anzahl der beinhaltenden Chunks 
$08-$0F byte intel reserviert, wahrscheinlich immer Null 
Eine Sonderform des Frame-Headers ist der Prefix-Header, (was immer das sein mag, ich habe bis jetzt noch keinen gesehen?). Der beanspruchte Speicherplatz dieses Prefix-Headers kann überlesen werden. Nun genau das 17.Byte ist der Beginn des 1.Chunks, beginnend mit einem Chunk-Header.


1.3 Der Chunk Header

 Der Chunk-Header besteht aus zwei Informationen und insgesamt 6Bytes, die wie folgt abgelegt sind.
 
Tabelle 3   Chunk-Header
Position
Typ
Format
Beschreibung
$00-$03 dword intel zeigt Größe des gesamten Chunks  inclusive Header
$04-$05 byte intel Angabe des Chunktypes
Bei der Ausprogrammierung habe ich festgestellt, daß die Angabe der Größe eines Chunks im letzten Header nicht stimmen muß. Dies habe ich wieder mit PV festgestellt. Das Programm liest wahrscheinlich ein gesamtes Frame ein und entschlüsselt dieses Frame dann Chunkweise. Ich hatte erst eine Chunkweise Entschlüsselung, welche nicht immer funktionierte. Weiterhin eine Erläuterung der Chunk-Typen. Das LowByte des Chunk-Typ Words enthält 8 verschiedene Bytes mit folgender Bedeutung:
Tabelle  4  Chunktypen
Wert
Name
Beschreibung
$04 Color 256 Paletteninforrnation
$07 Delta Flc Word-orientierte Deltakompression
$0B Color 64 Paletteninformation
$0C Delta Fli Byte-orientierte Deltakompression
$0D Black ganzer Bildschirm mit Null
$0F Byte Run Byte-Lauflängencodierung für Vollbild
$10 Literal unkomprimiertes Vollbild
$12 PSTAMP 'Postage stamp'
Ansonsten konnten keine weiteren Abweichungen oder Infos gefunden werden

1.3.1 Chunktyp $04 Color 256 (nur für FLC)

Informationen und Hintergründe für eine Palettenablegung im FLC-File in Verbindung mit der Umsetzung nach Windows. Mit dem Chunk-Typ "Color 256" und der Erkennung $04 wird eine Palette für das FLC-File beschrieben. Das FLC Format ist stark an die Eigenschaften von Windows angebunden. So sind die Palettenwerte RGB im Wertebereich von 0-255. Also genau wie in Windows. Die Paletteninformation ist im FLC-File als RGB abgelegt , in Windows BGR + NullByte. Also muß die Information behandelt werden (siehe assembler Routine). Die Palette ist Stückweise folgendermaßen abgelegt:: assembler Routine

1.3.2 Chunktyp $07 Delta Flc nur für FLC

 Informationen und Hintergründe für eine Wordorientierte Deltakompression im FLC-File in Verbindung mit der Ausprogrammierung in Windows. In diesem Chunk stehen Informationen zur Veränderung des Bildes. Die Speicherung erfolgt als  Lauflängencodierung. Die  Speicherungerfolgt zeilenweise. Somit kann das Bild problemlos gespeichert werden (drehen). Weitere Infos zum Aufbau folgen aus dem  assembler Text zur Decodierung des Chunks.

assembler Routine


1.3.3 Chunktyp $0B Color 64

Informationen und Hintergründe für eine Palettenablegung im FLC oder FLC-File in Verbindung mit der Umsetzung nach Windows. Mit dem ChunkTyp Color 64 und der Erkennung $0B wird eine Palette für das FLC/FLI- File beschrieben. Das FLC Format ist stark an die Eigenschaften vom Dos-Speicher angebunden. So sind die PalettenWerte RGB im Wertebereich von 0-63. Genau wie eine Standard VGA.für Windows, muß diese Information natürlich erst skaliert werden. Alle Werte mit 4 multiplizieren oder shl,2; die Paletteninformation ist im FLC- File als RGB abgelegt; in Windows BGR + NullByte. Die Information muß behandelt werden (siehe assembler Routine). Die Palette ist folgendermaßen stückweise abgelegt: assembler Routine

1.3.4 Chunktyp $0C Delta Fli

Informationen und Hintergründe für eine Byteorientierte Deltakompression im FLC/FLI-File in Verbindung mit der Ausprogrammierung in Windows. In diesem Chunk stehen Informationen zur Veränderung des Bildes. Speicherung als  Lauflängencodierung. Es erfolgt eine zeilenweise Speicherung. Somit kann das Bild Problemlos gespeichert werden (Drehen). Weitere Infos zum Aufbau folgen aus dem assembler Text zur Dekodierung des Chunks.

assembler Routine


1.3.5 Chunktyp $0D Black

Der ganze Bildschirm wird gelöscht. Hier braucht man nicht zu unterscheiden, ob man sich  in Windows oder in Dos befindet, denn es ist egal, ob von oben nach unten oder von unten nach oben gelöscht wird. Alle Pixelbytes des Bildes werden mit  Null überschrieben, und somit erhält das Bild die Farbinformation des ersten Paletteneintrags.

assembler Routine


1.3.6 Chunktyp  $0F  Byte  Run

Für ein Lauflängencodiertes Vollbild gilt das gleiche, wie bei dem Chunktyp "Delta Fli". Der Unterschied ist,daß das Vollbild  am Anfang einer Zeile keine Übersprungelemente besitzen kann, weil es sonst kein Vollbild wäre. Der Entscheidungs-Code zwischen Lauflängencodierung und normaler Codierung ist unterschiedlich. Weitere Informationen sind aus dem Assembler-Modul zu entnehmen.

assembler Routine


1.3.7 Chunktyp $10 Literal

Der letzte Chunktyp ist die Speicherung eines unkomprimierten X * Y Vollbildes.  Hier sei nur noch zu sagen, daß eine Differenz zwischen Windows und FLC besteht, die durch Zeilenweises Direkteinspeichern in das Windowsbild wieder wettgemacht werden kann. Auch hier sind weitere Informationen zu diesem Typ dem  Assembler Modul zu entnehmen.

assembler Routine


1.3.8 Chunktyp $12 PStamp (nur für FLC)

Dieser Chunk übergibt das verkleinerte Abbild einer Animation. Bisher habe ich keine Animation mit diesem Chunk gefunden. Auch eine genaue Beschreibung war nicht aufzutreiben. Der Chunk kann jedoch ohne Bedenken überlesen werden.

assembler Routine (@ jmp "Drüber")



2.0 Das Modul FLC-Player

Der FLC- Player ist unterteilt in
 
Pocedure
Bedeutung 
OPENflc Öffnen des Files und Anzeige des ersten Bildes
STARTflc  Anzeige der nächsten Frames
STOPflc Timer ausschalten keine weiteren Frames
CLOSEflc Schließen des Files und des Fensters
 
 
Dateiname
Größe
Bemmerkung
GLOBALS_.PAS
2219 
Globale Variablen für den Anim-Player
INIT_FLC.PAS
4047 
Decodieren des Headers und Parameter füllen
CHUNKASM.PAS
15822 
Decodieren der Chunks
NEXTFRAM.PAS
2750 
Lesen einer Frame und Festlegung der Frameart
PLAY_FLC.PAS
11046 
Fenstererstellung und Verzweigung zu den Modulen
 

2.1 Allgemeines zu der Programmierung

In dem Modul Openflc wird als erstes das Ausgabefenster für den FLC-File erstellt, dann wird der File auf die Endung geprüft. Als nächstes wird der FLC-Header ausgewertet und der Speicher für die Frames und das Bild bereitgestellt. Zum Schluß wird der 1.Frame angezeigt. Start und Stop-FLC sind kleine Funktionen, die den Timer für ein Fenster aktivieren bzw. deaktivieren. Die Timerinformationen werden von dem FLC-Fenster aufgenommen und dann ausgewertet. Das wichtigste Modul ist 'NextFrame'. In diesem Modul wird der FrameHeader ausgewertet und je nach Chunk verzweigt. Es sei noch auf die
Variable "was_go_flc" hinzuweisen. Diese Variable wird auf True gesetzt, wenn ein Frame bearbeitet wird. Ist der Frame abgearbeitet, so wird "was_go_flc" auf false gesetzt. Ein nächstes Frame kann nur dann geladen werden, wenn "was_go_flc" auf false ist. Warum so ein Aufwand? Eine Abarbeitung eines Frames kann einige Zeit brauchen. Während der Abarbeitung der Frames könnte der Timer für das Window wieder eine Meldung an das Fenster geben und somit ungeahnte Fehler hervorrufen, dh.das zur gleichen Zeit mehrere Frames berechnet werden würden. Da viele globale Var's vorhanden sind kommt es zu undefinierten Zuständen. Bleiben wir in der Hinsicht doch bei einer sequentiellen Programmierung. Die NextFrameProcedure verzweigt zu den Chunks, die Abarbeitung erfolgt in Assembler-Modulen, die reichlich in der Datei beschrieben sind. Nach der Abarbeitung der Chunks wird das alte FLC-BMP-Bild freigegeben und erneut bestimmt und dargestellt. Wichtig wäre vielleicht zu erwähnen, daß keine Auschnitte gezeichnet werden, sondern immer ganze X * Y Bilder.

2.2 Abschließende Worte zu FLC und FLI

Die Ausprogrammierung mittels Buch war nicht möglich, da einige Informationen zum Thema DeltaFLC nicht stimmten.
Wegen den Segmentsprüngen war die Ausprograrnmierung unter Windows 3.1 16bit  teilweise sehr umständlich. Eine 32bit Ausprogrammierung wurde von Windows nicht akzeptiert. Die Adressierung erfolgte schön mit EDI und ESI. In Win95 kam
es so recht schnell zu Abstürzen (Grund Emulation der 16bit). Unter Windows habe ich Untersuchungen durchgeführt. Auf Grund von TaskSwitches kam es zu Abstürzen, da EDI und ESI nur als 16bit Register gepuscht und gepopt wurden. Selbiges vermute ich bei Win'95.

3.0 Quellen für Formate

Ich habe folgendes Buch verwendet, was mir eine kleine Hilfe war.
Klaus Holtdorf 
Das Handbuch der Grafikformate
2. Auflage --- Franzis' - Verlag 
ISBN: 3-7723-6393-8

Blättern:
Allgemeines zum Aufbau der Grafikformate     Mein Format Codieren

Praktikum