nderungen am FLIC-Player FLICTCxx.PRG


04.11.94
Version 4.1.0
So, nun kommt der Player auch mit Dateien klar, die eine falsche (zu kleine,
z.B. ohne Header und Ringframe wie bei 7J7.FLI) Lngenangabe im Header
stehen haben. Dieser "Fehler" hat mich einige Nerven gekostet, gewohnheits-
mig hatte ich den Fehler bei mir gesucht, nur lag er leider eben nicht bei
mir. Ich kam erst auf die Ursache (falsche Lnge im FLIC-Header), nachdem in
einer auf das Ntigste reduzierten Version des Players (ohne Anzeige, etc)
nach dem Umstieg von Fread() auf BLOAD pltzlich alles funktionierte...
Sollte der Player eine abweichende Gre feststellen, passiert folgendes:
-Datei ist grer als im Header eingetragen:
 Es wird intern mit der realen Dateigre gearbeitet.
 Ist die Info-Seite aktiviert, wird eine Warnung ausgegeben.
-Datei ist kleiner als im Header angegeben:
 Es erscheint eine Abfrage, ob das Programm beendet werden, oder ob die
 Datei trotzdem abgespielt werden soll.
Ferner ist das uralte work-around (ein Byte weiter vorne nochmal versuchen)
endlich berflssig geworden, innerhalb eines FLICs scheinen die Grenan-
gaben nmlich zuverlssig zu sein...

28.10.94
Version 4.0.0 (ehemals 3.6.0 ...)
Es klappt! Es klappt! Der Player kann nun auch FLCs abspielen!
Mein Dank gebhrt Alexander Clauss, der mir mit Informationen ber das
FLC-Format aushelfen konnte; der c't-Artikel war in dieser Hinsicht leider
nicht sehr ergiebig. Momentan gibt es noch Probleme mit vereinzelten FLIs
(z.B. 7J7.FLI), bei denen der Player das Ende nicht richtig erkennt und
einfach abbricht, trotzdem werde ich diese Version verffentlichen, da nur
wenige FLIs betroffen sind und der Fehler auch schon in allen anderen
Versionen steckte.
Auslser fr den Entschlu nun doch FLCs abzuspielen, war brigens die
Erkenntnis, da man auf einem 68030 in nur 6 Takten aus einem Intel-Wort
ein Motorola-Wort machen kann. Wie? - Ganz einfach: ein ror.w #8,D0 erledigt
das Gewnschte, zu allem berflu kann der '030 auch Worte von ungeraden
Adressen lesen, so da man mit zwei Befehlen ein Intel-Wort aus dem Speicher
holen und in das Motorola-Format wandeln kann!
Auerdem mssen nur sehr wenig Worte verarbeitet werden, das Meiste lt
sich ber Byte-Operationen erschlagen...

20.10.94
Version 3.5.3 (immer noch)
am Player selbst keine Vernderungen, allerdings ist die englische
Anleitung nochmal leicht berarbeitet worden (Dank an Lars Weinrich).
Auerdem habe ich einen einfachen Benchmark (HYDRAMRK.TOS) beigelegt, der
die CPU- und Busperformance mit, ntzlich um die Busbelastung durch die
Videoauflsung zu ermitteln. Benutzer von Auflsungserweiterungen knnen
sich zum Beispiel eine Auflsung 320x200 in HiColor, 60Hz, SINGLESCAN
basteln, allerdings natrlich auf eigene Gefahr (Monitordaten beachten!),
mein Rechner erreicht in einer solchen Auflsung (bei 20 Mhz) 117% im Ver-
gleich zu ST-Hoch auf einem 16MHz-Falken, neuer Rekord bei 40MHz und
<HANDS.FLI> 688.8 fps ...

06.10.94
Version 3.5.3
Es wird nun berprft, ob die abzuspielende Datei wirklich ein FLI ist,
nicht berall wo FLI hintersteht ist auch FLI davor (oder so hnlich).
In Version 4.0 werden wohl FLCs untersttzt werden, allerdings weiter nur
in HiColor (ich habe nmlich einige 320x200 FLCs entdeckt - es gibt sie
also doch!). Auerdem existiert nun die Datei SPEED.TXT in der die er-
reichten Maximalgeschwindigkeiten einiger FLIs auf meinem Falcon angegeben
sind.

04.10.94
Version 3.5.2 (nicht verffentlicht)
Im Fehlerfall wurde die Eingabedatei nicht geschlossen, nun behoben.

02.10.94
Version 3.5.1 (nicht verffentlicht)
Tja, nobody's perfect, ein alter, lngst tot geglaubter Bekannter war in
Version 3.5.0 wieder aufgetaucht (bei FAN.FLI und MOUSE.FLI):
<skipping unknown chunk type ...>, trat allerdings nur beim Spielen
von Platte auf, ich habe ihm (hoffentlich!) endgltig Hausverbot erteilt, das
mysterise work around aus Version 3.1 ist hiermit rehabilitiert ...
Der freie Speicher wird nun auf der Statusseite (-i=1) mit angezeigt.
Ich berlege fr zuknftige Versionen die Speicherverwaltung aus Version
3.4.x zustzlich wieder einzufhren, da bei sehr komplexen Animationen mit
sehr groen Einzelbildern die Abspielgeschwindigkeit beim jetzigen Verfahren
stark einbricht (die Festplatte ist halt kein D-Zug... wie wr's mit 'ner
RAM-Disk?!), ein Festplattencache kann den Effekt aber mildern ...

01.10.94
Version 3.5.0 (nicht verffentlicht)
Die Speicherverwaltung ist noch einmal komplett umgekrempelt worden, FLIs
die nicht komplett in den Speicher passen werden jetzt Bild fr Bild von
der Platte gespielt, die Daten fr das nchste Bild werden wenn mglich in
der Wartezeit fr das nchste Bild geladen, die Animationen wirken nun viel
flssiger, allerdings ist der Betrieb von Diskette dadurch ziemlich unmglich
geworden, aber andererseits sollte jeder Falcon genug Speicher haben, um eine
Datei von Diskette komplett laden zu knnen (oder gibt es nun doch 1MB-
Falcons?)
Auerdem ist der Player mit eingeschalteter VBL-Synchronisation nochmal ein
ganzes Stck schneller geworden (bis zu 20%) (eine Zeilenvertauschung bei den
Timing-Schleifen macht's mglich), nun lassen sich auch bei eingeschalteter
Vsync-Option meistens 95-105% der Originalgeschwindigkeit errreichen!
Ach ja, der Player ist sogar 1kB im Vergleich zur Version 3.4.1 krzer
geworden ...
Der <-m=xxxxx> Schalter aus Version 3.4.1 existiert brigens weiter,
vielleicht kann's irgend jemand gebrauchen und auerdem kann man so auch
ohne bergroe FLIs zu besitzen (so wie ich) der Platte mal ein bichen
Stre machen ...

27.9.94
Version 3.4.1 (nicht verffentlicht)
neuer Schalter (-m=xxxxx) eingefhrt, der den Player veranlasst nur
xxxxx kB RAM zu benutzen, dazu mute die Commandine-Auswertung komplett
berarbeitet werden, nach Auen hat sich allerdings nichts gendert.

27.9.94
Version 3.4.0 (nicht verfentlicht)
Der Player kann nun Dateien, die nicht in den Speicher passen direkt von
Diskette oder Festplatte abspielen, wobei das freie RAM als Puffer genutzt
wird. Im Gegensatz zu anderen Playern werden Dateien die komplett ins RAM
passen auch weiterhin ganz aus dem RAM abgespielt. 
Im Moment ldt der Player immer so viel von dem FLI, wie gerade in den
Speicher pat, spielt den Puffer bis kurz vor das Ende ab und ldt dann 
nach. Dieses Vorgehen bringt im Schnitt die hchste Abspielrate, allerdings
hakt die Darstellung bei groem Puffer und sehr langen FLIs ein wenig, da
unter Umstnden mehrere Megabytes nachgeladen werden mssen ...
In der nchsten Version wird es einen Schalter geben, der den Player anweist
nur eine gewisse Menge Speicher zu verwenden; auerdem denke ich ber FLC-
Untersttzung nach, wei jemand ob es auch FLCs in Auflsungen kleiner als 
640x480 gibt (z.B. 320x200 oder 480*400) ?

26.9.94
Version 3.3.3 (nicht verffentlicht)
Dateien, die nicht in den Speicher passen, werden nun auch nicht mehr
geladen. Dieser peinliche Fehler steckte in allen bisherigen Versionen
und konnte zu einem Totalabsturz fhren...

25.9.94
Version 3.3.2 (nicht verffentlicht)
Es gab wohl doch noch einen(?) Fehler im Player (nobody's perfect,
vielen Dank an Alexander Clauss!). Manchmal wurde der Chunkheader nicht
korrekt gefunden, das (sowieso nicht besonders elegante) work around aus
Version 3.1 war halt noch nicht ganz das Gelbe vom Ei, glcklicherweise 
gibt es eine ziemlich einfache Lsung (manchmal sieht man den Wald vor 
lauter Bumen nicht - nochmal vielen Dank an Alexander...), jetzt sollten
sich alle FLIs abspielen lassen, die auch in den Speicher passen... 
(mal schauen, wer mich diesmal eines besseren belehrt?!?)

8.9.94
Version 3.3.1
Fr den Grnanteil werden die in HiColor vorhandenen 6 Bit nun auch aus-
genutzt, vorher lag das niederwertigste Grnbit brach (d.h. auf Null).

6.9.94
Version 3.3
Schalter zur Anzeige der Header-Information eingebaut, bisher zeigte der
Player den Header beim Start kurz an und begann gleich darauf mit dem
Abspielen, sehr unschn, aber wie gesagt Vergangenheit.
Ein paar kosmetische Verschnerungen, um den Film wird nun ein Zelluloid-
streifen dargestellt, ist allerdings nur bei ausreichend hoher Auflsung
(ab 400x270) voll sichtbar, macht sich aber ganz gut (Eigenlob!).

4.9.94
Version 3.2 (immer noch)
Englische Kurzanleitung gestrickt: quick and dirty, aber besser als
nix, konstruktive(!) Kritik erlaubt.

13.8.94
Version 3.2
Umstellung auf 68020-Code, das bringt nun je nach Animation bis zu
15% mehr Geschwindigkeit!
Um diesen Unterschied messen zu knnen wurde ein neuer Schalter 
(-t=0/1) eingefhrt, der den Player anweist die vorgegebene Abspiel-
geschwindigkeit komplett zu ignorieren, neue Spitzengeschwindigkeit
bei Aufruf mit -t=0 -v=0 HANDS.FLI : 608 fps (Falcon, 40MHz CPU, 
20MHz Bus, 320x200, 66.3Hz).
Abfrage auf korrekte Auflsung eingebaut, vorher schmi der Player
Bomben, wenn er in einer Auflsung mit weniger als 65536 Farben 
gestartet wurde.

12.8.94
Version 3.1 ist nun (hoffentlich) fehlerfrei, letzte Probleme mit
wenigen Animationen beseitigt (FAN.FLI, MOUSE.FLI), irgendwie scheint
der Header bei diesen FLIs ein Byte frher zu beginnen (noch in den
Daten vom letzten Chunk?), mit dem Effekt, das mein Player nur die
zweite Hlfte vom Magic fand und mit einer Fehlermeldung abbrach,
das gehrt nun der Vergangenheit an, sollte das Magic mal nicht 
stimmen, macht der Player einfach einen zweiten Versuch ein Byte weiter
vorne... Ziemlich primitiv, aber es funktioniert, wer eine bessere Idee
hat mge sich bitte melden...

Version 3.0
Endlich sind die Assemblerroutinen fertig, in so einem FLI lauern
doch diverse Fallen beim Umstieg von einer Hochsprache (mit FOR-
Schleifen) nach Assembler (mit DBRA), die Paketanzahl und die Anzahl
der zu setzenden Pixel kann nmlich Null sein, mit entsprechend fatalen
Folgen in den Assembler-Routinen, aus 0.w wird durch Abziehen von 1.w 
(wegen DBRA) dann 65535.w, und nichts stimmt mehr... Davon hatte die
c't nichts erwhnt (schmoll...)
Ferner kann der Player nun endlich auch Animationen loopen und
den Vsync ignorieren.

Version 2.0
Diese Version ist immer noch in Basic, allerdings wertet sie die Farben
korrekt aus und zeigt die Animation nun in HiColor an, durch Umstieg
von DRAW auf WPOKE Geschwindigkeitsteigerung um mehrere hundert Prozent,
das Compilat spielt Animationen mit 10 fps (frames per second) ab,
hat allerdings noch Probleme mit diversen FLIs (FAN.FLI, MOUSE.FLI)

Version 1.0
Der erste Player, noch immer in Basic, kann inzwischen schon die
ersten Animationen abspielen (BIRDY.FLI), noch ziemlich langsam
und ohne Auswertung der Farbinformation, immerhin ist schon was
zu sehen...

Version 0.0
Erste Basic-Version eines FLI-Analyzers ist fertig, in Anlehnung an
einen  Artikel in der c't 8/94, das Programm kann den Header auswerten
und sich durch die komplette Block-Struktur eines FLIs hangeln.

Sven Bruns

[EOF]
