nderungen am FLIC-Player FLICTCxx.PRG

2.3.95
Version 4.5.2
Die Geschwindigkeit beim Double-Buffering ist jetzt je nach Animation und
Rechner um bis zu 30% hher geworden, der Player wartete vorher auch bei
Double-Buffering noch auf den Vsync (so dieser aktiv war), was ziemlich
berflssig war und nur Zeit kostete :)
Als weitere Neuerung gibt es nun einen Quietmodus (-q=1): In diesem Modus
macht der Player keine Ausgaben auf den Bildschirm (auer der Animation
natrlich) und wartet nach Ende des Abspielens auch nicht auf Tastendruck.
Damit sollte es nun mglich sein den Player aus eigenen Programmen zum
Abspielen von FLIs/FLCs aufzurufen, ich warte auf die ersten Spiele mit
tollen Filmsequenzen :) Soll ein Programm, welches den FLICTC verwendet
verffentlicht werden, verlange ich die Zusendung eines Belegexemplars
und bei Shareware zustzlich eine Beteiligung von 10-20% an den
Registrierungseinnahmen. Bei kommerzieller Software sind die Nutzungs-
bedingungen von Fall zu Fall auszuhandeln.

2.3.95
Version 4.5.1 (nicht verffentlicht)
Die automatische Erkennung des Grafikmodus (Intel oder Motorola) ist nun
abschaltbar, d.h. falls der Schalter -I=0 oder -I=1 auftaucht, unterbleibt
der Versuch den Modus selbst zu ermitteln. Auerdem wird nun bei der Auf-
lsungsumschaltung und beim Double-Buffering die Logbase fest gelassen, d.h.
Fehlermeldungen landen auf dem "richtigen" Bildschirm in der richtigen
Auflsung. Wird eine Animation ber einen Mausklick abgebrochen, wird nun
auf das Loslassen der Taste gewartet.

1.3.95
Version 4.5.0 (nicht verffentlicht)
Auf Anregung von Torsten Lang habe ich die Hardwareanforderungen etwas ab-
geschwcht, FLICTC sollte nun auch (wieder) auf normalen STs mit MC68000
Prozessor laufen (leider mangels ST mit HiColor-Grafikkarte nicht getestet),
HiColor-Grafik ist aber weiterhin zwingend erforderlich. Je nach CPU-Typ
(oder besser Cookie) verwendet der Player entweder 68000 oder 68020-Code :)
Grafikkarten, die im Intelwortformat (tolles Wort :) ) arbeiten werden nun
automatisch erkannt, der -I=0/1 Schalter ist damit berflssig, ich werde
ihn demnchst entfernen (you have been warned).
Ferner ist ein kleiner Fehler bei der Anzeige der Header-Information von
bei FLIs behoben: Der angezeigte Wert war um den Faktor 2.85 zu hoch.

6.2.95
Version 4.4.4
Gerade dachte ich, ich wre fertig und schon habe ich wieder einen Bug-Report
in der Post (und wieder vielen Dank an Daniel Hedberg), Ihr lat mir wohl gar
nichts durchgehen, oder?
Unbekannte Schalter in der Kommandozeile fhrten in eine Endlosschleife statt
ins Desktop - nur ein Reset half noch :( , behoben.
Auerdem ist nun ber -S=<x> die Grenze fr das intelligente Double-Buffering
frei whlbar, sinnvoll auf normalen Falcons drfte x=10..x=14 sein, bei auf-
gebohrten Rechnern x=14..x=18.

4.2.95
Version 4.4.3 (nicht verffentlicht)
Die neue Assembler-FLI_Brun-Routine ist fertig, war nicht sonderlich schwer,
sogar die Condition-Codes fr die Sprnge waren auf Anhieb richtig, Sachen
gibt's :)
Nun steht auch in der deutschen Anleitung, da man mit der Taste "0" wieder
die Ursprungswerte einstellen kann ...

2.2.95
Version 4.4.2 (nicht verffentlicht)
Es war noch ein Fehler in der FLI_Brun Dekompression, d.h. der Player konnte
beim Entpacken des ersten Bildes in FLC-Animationen (und nur dort) ziemlich
bel abstrzen (Dank an Daniel Hedberg :) )
Meine Routine war nmlich auf korrekte Angaben in den Paketzhlern angewiesen
(und funktionierte bei all meinen FLCs - schmoll) - dummerweise mssen die
Paketzhler beim FLC-Format nicht sinnvoll initialisiert werden, das Zeilen-
ende mu hier anhand der Lnge der entpackten Daten erkannt werden. Die erste
Version einer genderten FLI_Brun-Routine luft schon in BASIC, in den
nchsten Tagen werde ich sie in Assembler bersetzen...
Ach ja: es gibt nun eine anstndige Fehlerbehandlung, d.h. falls ein Fehler
auftritt wird ggf erst die Auflsung zurckgeschaltet und dann eine Fehler-
meldung ausgegeben. Nun kann man sogar lesen was kaputt ist :)

31.1.95
Version 4.4.1 (nicht verffentlicht)
Interne Struktur wieder verknotet und dem Double-Buffering ein wenig
Intelligenz (ein Widerspruch in sich ,) ) verpat: bei -D=2 wird nun bei
Animationen, die laut Header nur mit bis zu 14 fps laufen sollen, das DB
eingeschaltet, bei schnelleren Animationen wird es abgeschaltet (eigentlich
naheliegend, oder?). Dies ist brigens die neue Standardeinstellung.

Januar 95
Version 4.4.0 (nicht verffentlicht)
Ich habe den Code ein wenig aufgerumt und die interne Struktur ein wenig
entknotet, als angenehmer Nebeneffekt klappt die Auflsungsumschaltung nun
auch auf RGB/TV (tat sie vorher leider nur halb: hin klappte, zurck nicht :(
Dank an Daniel Hedberg!). Habe ich vergessen zu erwhnen, da es einen neuen
Schalter (und natrlich auch eine neue Funktion) gibt? Ab sofort wird Double-
Buffering untersttzt, d.h. es werden dann drei Bildschirmseiten benutzt,
wobei die erste das vorletzte Bild enthlt, die zweite das letzte Bild und auf
der dritten verdeckt das nchste Bild aufgebaut wird, damit reduziert sich
Geflacker und Geruckel auf Null :) , soweit zu den guten Nachrichten ...
die schlechte Nachricht ist, das das Double-Buffering qulend langsam ist,
d.h. auf einem 16MHz-Falcon funktioniert das Ganze bis ca. 14 fps ohne
Geschwindigkeitsverlust (wobei dann schon ca. 80-90% der Rechenzeit auf das
Umkopieren von Bildschirmen entfallen :( ), bei mehr als 14 fps wird das DB
dann zum Bremsklotz, hier stt der Falcon an seine Grenzen (hat jemand
vielleicht FastRAM oder eine Speicherkarte mit 0 Waitstates?). In spteren
Versionen werde ich das DB vielleicht noch so ndern, da die Bildschirmseiten
nicht kopiert, sondern dreimal entpackt werden, drfte meistens schneller sein
als komplettes Kopieren ... der zustndige Schalterbeamte ist brigens -D=0/1

15.12.94
Version 4.3.2
Heute morgen fand ich in meiner Mail eine kurze Nachricht von Christian
Krger wegen des Fehlers beim Umschalten in HiColor auf RGB/TV:
die Breite in RGB-Overscan betrgt nicht 368 sondern 384 Pixel, das
Bild erschien daher vllig verzerrt :-(
Nun sollte die Umschaltung aber auch auf RGB/TV funktionieren :-)
(na, war das schnelle Arbeit?!)

14.12.94
Version 4.3.1 (nicht verffentlicht)
Da sich der Player nun ber die Tastatur steuern lt, lag es irgendwie doch
nah auch andere Optionen ber die Tastatur ndern zu knnen:
<t> schaltet die Synchronisation mit dem 200Hz-Timer ein bzw. aus (-t=...)
<v> schaltet die Synchronisation mit dem Vsync ein bzw. aus (-v=...)
<l> Warten nach letztem Bild ein bzw. aus (-L=...)
<0> setzt alles auf die Anfangswerte zurck
Auerdem wird nun der Bildschirmspeicher bei der "-z"-Option gelscht, das
hatte ich leider bersehen; fiel auch nicht auf, weil das OS sowieso immer
gelschte Speicherblcke verteilt (kann sich aber ndern!)
Die Auflsungsumschaltung in RGB funktioniert leider noch nicht korrekt und
ist deshalb auf RGB erstmal nicht mehr verfgbar (ich arbeite aber daran!)

11.12.94
Version 4.3.0 (nicht verffentlicht)
Einige kleine Nettigkeiten eingefhrt, so ist es nun z.B. mglich die Ab-
spielgeschwindigkeit im Betrieb ber die Tasten <+> (schneller) ,<-> 
(langsamer)und <0> (normal, bzw. externe Vorgabe) zu beeinflussen, einfach
mal ausprobieren! Diese Erweiterung hat zur Konsequenz, das der Player nun
nur noch auf die Maustasten und die Leertaste reagiert.
Auerdem gibt's mal wieder ein paar neue Schalter:
-I=1 schaltet in einen Intelwort-orientierten Grafikmodus (z.B. fr TT's mit
     VGA-Karte, funktioniert aber nur in HiColor, und auch dort nur vielleicht)
-d=1 Debugmodus fr eben diesen Zweck, auf TT's strzt der Player scheinbar
     nach Programmende ab ... (sch... Compiler!)
-L=1 don't wait on Last frame, berspringt die Warteschleife nach dem letzten
     Bild einer Animation: in manchen FLIs sind das erste und das letzte Bild
     identisch, dies fhrt zu einem strenden ruckeln. Dieser Schalter bringt
     Abhilfe, die Animation luft nun "runder".

21.11.94
Version 4.2.0
Auf vielfachen Wunsch kann der Player nun auch von selbst die Auflsung
wechseln (-z=1) - auch bei externen Videoerweiterungen. An dieser Stelle
vielen Dank an Christian "chrisker" Krger der mir die entsprechende Routine
zur Verfgung stellte.
Weiterhin sind noch ein paar kleine Verbesserungen abgefallen. Unter anderem
wird nun ber den CookieJar der Prozessortyp und die Videohardware getestet,
die Darstellungsroutinen laufen erst ab 68020 und das direkte Umschalten der
Auflsung funktioniert auch nur mit der Falcon-Videohardware. Ich weise an
dieser Stelle noch einmal darauf hin, da ich *KEINE* Verantwortung fr even-
tuelle Beschdigungen an Hard- oder Software bernehme, die Benutzung des
FLICTCxx erfolgt auf eigene Gefahr.
Ferner lt sich die Abspielgeschwindigkeit ber einen neuen Schalter
(-s=<x>) nun frei einstellen. Die Angabe erfolgt in Bilder/Sekunde. 
In der Datei SPEED.TXT habe ich als Referenzauflsung nun die normale Desktop-
Auflsung 320x240x65536 mit 60Hz gewhlt, die Angaben sind nun leichter ver-
gleichbar.

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]
