Ž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% h”her 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 (aužer der Animation natrlich) und wartet nach Ende des Abspielens auch nicht auf Tastendruck. Damit sollte es nun m”glich 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 ver”ffentlicht werden, verlange ich die Zusendung eines Belegexemplars und bei Shareware zus„tzlich 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 ver”ffentlicht) 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. Aužerdem wird nun bei der Auf- l”sungsumschaltung und beim Double-Buffering die Logbase fest gelassen, d.h. Fehlermeldungen landen auf dem "richtigen" Bildschirm in der richtigen Aufl”sung. Wird eine Animation ber einen Mausklick abgebrochen, wird nun auf das Loslassen der Taste gewartet. 1.3.95 Version 4.5.0 (nicht ver”ffentlicht) Auf Anregung von Torsten Lang habe ich die Hardwareanforderungen etwas ab- geschw„cht, 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 demn„chst 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 w„re fertig und schon habe ich wieder einen Bug-Report in der Post (und wieder vielen Dank an Daniel Hedberg), Ihr lažt mir wohl gar nichts durchgehen, oder? Unbekannte Schalter in der Kommandozeile fhrten in eine Endlosschleife statt ins Desktop - nur ein Reset half noch :( , behoben. Aužerdem ist nun ber -S= die Grenze fr das intelligente Double-Buffering frei w„hlbar, 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 ver”ffentlicht) 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 ver”ffentlicht) 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 n„mlich auf korrekte Angaben in den Paketz„hlern angewiesen (und funktionierte bei all meinen FLCs - schmoll) - dummerweise mssen die Paketz„hler beim FLC-Format nicht sinnvoll initialisiert werden, das Zeilen- ende muž hier anhand der L„nge der entpackten Daten erkannt werden. Die erste Version einer ge„nderten FLI_Brun-Routine l„uft schon in BASIC, in den n„chsten Tagen werde ich sie in Assembler bersetzen... Ach ja: es gibt nun eine anst„ndige Fehlerbehandlung, d.h. falls ein Fehler auftritt wird ggf erst die Aufl”sung zurckgeschaltet und dann eine Fehler- meldung ausgegeben. Nun kann man sogar lesen was kaputt ist :) 31.1.95 Version 4.4.1 (nicht ver”ffentlicht) Interne Struktur wieder verknotet und dem Double-Buffering ein wenig Intelligenz (ein Widerspruch in sich ,) ) verpažt: 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 ver”ffentlicht) Ich habe den Code ein wenig aufger„umt und die interne Struktur ein wenig entknotet, als angenehmer Nebeneffekt klappt die Aufl”sungsumschaltung nun auch auf RGB/TV (tat sie vorher leider nur halb: hin klappte, zurck nicht :( Dank an Daniel Hedberg!). Habe ich vergessen zu erw„hnen, 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 enth„lt, die zweite das letzte Bild und auf der dritten verdeckt das n„chste Bild aufgebaut wird, damit reduziert sich Geflacker und Geruckel auf Null :) , soweit zu den guten Nachrichten ... die schlechte Nachricht ist, das das Double-Buffering qu„lend 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 st”žt der Falcon an seine Grenzen (hat jemand vielleicht FastRAM oder eine Speicherkarte mit 0 Waitstates?). In sp„teren 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 zust„ndige 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 betr„gt nicht 368 sondern 384 Pixel, das Bild erschien daher v”llig verzerrt :-( Nun sollte die Umschaltung aber auch auf RGB/TV funktionieren :-) (na, war das schnelle Arbeit?!) 14.12.94 Version 4.3.1 (nicht ver”ffentlicht) Da sich der Player nun ber die Tastatur steuern l„žt, lag es irgendwie doch nah auch andere Optionen ber die Tastatur „ndern zu k”nnen: schaltet die Synchronisation mit dem 200Hz-Timer ein bzw. aus (-t=...) schaltet die Synchronisation mit dem Vsync ein bzw. aus (-v=...) Warten nach letztem Bild ein bzw. aus (-L=...) <0> setzt alles auf die Anfangswerte zurck Aužerdem wird nun der Bildschirmspeicher bei der "-z"-Option gel”scht, das hatte ich leider bersehen; fiel auch nicht auf, weil das OS sowieso immer gel”schte Speicherbl”cke verteilt (kann sich aber „ndern!) Die Aufl”sungsumschaltung 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 ver”ffentlicht) Einige kleine Nettigkeiten eingefhrt, so ist es nun z.B. m”glich 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. Aužerdem 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 st”renden ruckeln. Dieser Schalter bringt Abhilfe, die Animation l„uft nun "runder". 21.11.94 Version 4.2.0 Auf vielfachen Wunsch kann der Player nun auch von selbst die Aufl”sung 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 Aufl”sung funktioniert auch nur mit der Falcon-Videohardware. Ich weise an dieser Stelle noch einmal darauf hin, daž ich *KEINE* Verantwortung fr even- tuelle Besch„digungen an Hard- oder Software bernehme, die Benutzung des FLICTCxx erfolgt auf eigene Gefahr. Ferner l„žt sich die Abspielgeschwindigkeit ber einen neuen Schalter (-s=) nun frei einstellen. Die Angabe erfolgt in Bilder/Sekunde. In der Datei SPEED.TXT habe ich als Referenzaufl”sung nun die normale Desktop- Aufl”sung 320x240x65536 mit 60Hz gew„hlt, 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) L„ngenangabe im Header stehen haben. Dieser "Fehler" hat mich einige Nerven gekostet, gewohnheits- m„žig hatte ich den Fehler bei mir gesucht, nur lag er leider eben nicht bei mir. Ich kam erst auf die Ursache (falsche L„nge im FLIC-Header), nachdem in einer auf das N”tigste reduzierten Version des Players (ohne Anzeige, etc) nach dem Umstieg von Fread() auf BLOAD pl”tzlich alles funktionierte... Sollte der Player eine abweichende Gr”že feststellen, passiert folgendes: -Datei ist gr”žer als im Header eingetragen: Es wird intern mit der realen Dateigr”že 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 Gr”ženan- gaben n„mlich zuverl„ssig 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 ver”ffentlichen, da nur wenige FLIs betroffen sind und der Fehler auch schon in allen anderen Versionen steckte. Ausl”ser 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! Aužerdem mssen nur sehr wenig Worte verarbeitet werden, das Meiste l„žt sich ber Byte-Operationen erschlagen... 20.10.94 Version 3.5.3 (immer noch) am Player selbst keine Ver„nderungen, allerdings ist die englische Anleitung nochmal leicht berarbeitet worden (Dank an Lars Weinrich). Aužerdem habe ich einen einfachen Benchmark (HYDRAMRK.TOS) beigelegt, der die CPU- und Busperformance mižt, ntzlich um die Busbelastung durch die Videoaufl”sung zu ermitteln. Benutzer von Aufl”sungserweiterungen k”nnen sich zum Beispiel eine Aufl”sung 320x200 in HiColor, 60Hz, SINGLESCAN basteln, allerdings natrlich auf eigene Gefahr (Monitordaten beachten!), mein Rechner erreicht in einer solchen Aufl”sung (bei 20 Mhz) 117% im Ver- gleich zu ST-Hoch auf einem 16MHz-Falken, neuer Rekord bei 40MHz und 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 n„mlich einige 320x200 FLCs entdeckt - es gibt sie also doch!). Aužerdem 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 ver”ffentlicht) Im Fehlerfall wurde die Eingabedatei nicht geschlossen, nun behoben. 02.10.94 Version 3.5.1 (nicht ver”ffentlicht) Tja, nobody's perfect, ein alter, l„ngst tot geglaubter Bekannter war in Version 3.5.0 wieder aufgetaucht (bei FAN.FLI und MOUSE.FLI): , trat allerdings nur beim Spielen von Platte auf, ich habe ihm (hoffentlich!) endgltig Hausverbot erteilt, das mysteri”se 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 zus„tzlich wieder einzufhren, da bei sehr komplexen Animationen mit sehr grožen Einzelbildern die Abspielgeschwindigkeit beim jetzigen Verfahren stark einbricht (die Festplatte ist halt kein D-Zug... wie w„r's mit 'ner RAM-Disk?!), ein Festplattencache kann den Effekt aber mildern ... 01.10.94 Version 3.5.0 (nicht ver”ffentlicht) 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 n„chste Bild werden wenn m”glich in der Wartezeit fr das n„chste Bild geladen, die Animationen wirken nun viel flssiger, allerdings ist der Betrieb von Diskette dadurch ziemlich unm”glich geworden, aber andererseits sollte jeder Falcon genug Speicher haben, um eine Datei von Diskette komplett laden zu k”nnen (oder gibt es nun doch 1MB- Falcons?) Aužerdem ist der Player mit eingeschalteter VBL-Synchronisation nochmal ein ganzes Stck schneller geworden (bis zu 20%) (eine Zeilenvertauschung bei den Timing-Schleifen macht's m”glich), 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 aužerdem kann man so auch ohne bergrože FLIs zu besitzen (so wie ich) der Platte mal ein bižchen Strež machen ... 27.9.94 Version 3.4.1 (nicht ver”ffentlicht) neuer Schalter (-m=xxxxx) eingefhrt, der den Player veranlasst nur xxxxx kB RAM zu benutzen, dazu mužte die Commandine-Auswertung komplett berarbeitet werden, nach Aužen hat sich allerdings nichts ge„ndert. 27.9.94 Version 3.4.0 (nicht ver”fentlicht) 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 l„dt der Player immer so viel von dem FLI, wie gerade in den Speicher pažt, spielt den Puffer bis kurz vor das Ende ab und l„dt dann nach. Dieses Vorgehen bringt im Schnitt die h”chste Abspielrate, allerdings hakt die Darstellung bei grožem Puffer und sehr langen FLIs ein wenig, da unter Umst„nden mehrere Megabytes nachgeladen werden mssen ... In der n„chsten Version wird es einen Schalter geben, der den Player anweist nur eine gewisse Menge Speicher zu verwenden; aužerdem denke ich ber FLC- Untersttzung nach, weiž jemand ob es auch FLCs in Aufl”sungen kleiner als 640x480 gibt (z.B. 320x200 oder 480*400) ? 26.9.94 Version 3.3.3 (nicht ver”ffentlicht) 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 ver”ffentlicht) 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 L”sung (manchmal sieht man den Wald vor lauter B„umen 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 unsch”n, aber wie gesagt Vergangenheit. Ein paar kosmetische Versch”nerungen, um den Film wird nun ein Zelluloid- streifen dargestellt, ist allerdings nur bei ausreichend hoher Aufl”sung (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 k”nnen 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 Aufl”sung eingebaut, vorher schmiž der Player Bomben, wenn er in einer Aufl”sung 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 H„lfte vom Magic fand und mit einer Fehlermeldung abbrach, das geh”rt 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 m”ge 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 n„mlich 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 erw„hnt (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]