Hinweise zur Kompatibilität/API Änderungen

6.2 Hinweise zur Kompatibilität/API Änderungen

Hollywood 9.0 API-Änderungen

In Hollywood 9.0 wurden einige API-Änderungen vorgenommen. Höchstwahrscheinlich müssen Sie Ihre Skripte nicht anpassen, damit sie mit der Version 9.0 funktionieren. Überprüfen Sie einfach die folgenden Hinweise, um festzustellen, ob für Ihr Skript eine Anpassung erforderlich ist.

– Unter AmigaOS und kompatiblen Systemen werden in LIBS:Hollywood installierte Plugins nicht mehr automatisch von allen mit Hollywood kompilierten Programmen geladen. Von Hollywood kompilierte Programme laden jetzt nur die Plugins, die neben dem Programm im gleichen Verzeichnis gespeichert sind. Wenn Sie möchten, dass Ihre Programme auch alle Plugins in LIBS:Hollywood lädt, müssen Sie den Tag GlobalPlugins in der Präprozessor-Anweisung @OPTIONS auf True setzen. Sie können auch das Konsolenargument oder Merkmal (ToolType) -globalplugins für das Programm verwenden.
– Unter Windows wurde Hollywoods Grafik-Modul komplett neu geschrieben und verwendet jetzt Direct2D. Dies hat viele Vorteile und ermöglicht auch die Nutzung der GPU, wenn das Autoskalierungs-System aktiv ist. In einigen seltenen Fällen kann Ihr Skript jedoch mit Direct2D langsamer sein als vorher, je nachdem, wie Sie Ihre Grafik erstellen. Wenn Ihr Skript mit Hollywood 9.0 langsamer ausgeführt wird, können Sie Hollywood entweder zwingen, das alte Grafik-Modul zu verwenden (welches aus Kompatibilitätsgründen mit der Windows-Versionen noch unterstützt wird, die Direct2D nicht unterstützen (d.h. alle Windows-Versionen vor Vista SP2)) oder die Art und Weise anpassen, wie Ihr Skript seine Grafiken zeichnet. Um Hollywoods altes Grafik-Modul zu aktivieren, setzen Sie einfach den Tag SoftwareRenderer der Präprozessor-Anweisung @DISPLAY auf True. Alternativ können Sie auch die Art und Weise anpassen, wie Ihr Skript seine Grafiken zeichnet, um die Leistung mit Direct2D zu verbessern. Bei Direct2D führt jeder Zeichnungsvorgang immer zu einer vollständigen Aktualisierung des Displays, auch wenn nur ein einziges Pixel gezeichnet wird! Daher muss Ihr Skript seine Grafiken so zeichnen, dass die Aktualisierung des gesamten Displays minimiert wird. Dies kann entweder durch Verwendung eines Doppelpuffers oder durch Verwendung von BeginRefresh() und EndRefresh() erreicht werden. Siehe BeginRefresh für Details.
– Unter Windows skaliert Hollywood Ihre Skripte jetzt automatisch so, dass sie auf hochauflösenden Monitoren an die DPI des Monitors angepasst werden. Dies garantiert, dass sie auch auf hochauflösenden Monitoren in der richtigen Größe angezeigt werden. Wenn Sie dies nicht möchten, setzen Sie den neuen Tag DPIAware in der Präprozessor-Anweisung OPTIONS auf True. Dies wird insbesondere für GUI-Anwendungen empfohlen, da diese viel besser aussehen, wenn das Programm sich der Auflösung anpassen kann.
– Lader und Adapter werden jetzt in der Reihenfolge berücksichtigt, wie sie in der Zeichenkette an ein Tabellenargument von Loader oder Adapter übergeben werden. Wenn Sie beispielsweise die Zeichenkette digibooster|xmp an OpenMusic() übergeben, wird zuerst versucht, die Musik mit digibooster.hwp zu öffnen. Und nur wenn dies fehlschlägt, wird als nächstes mit xmp.hwp versucht, die Datei zu öffnen. Auf diese Weise können Sie auch generische Lader wie Native, Inbuilt und Plugin priorisieren. Wenn Sie z.B. möchten, dass native und interne Lader vor Plugin verwendet werden sollen, können Sie die Zeichenkette native|inbuilt|plugin übergeben, um dies zu erreichen. Beachten Sie, dass es sich zwar um eine API-Änderung handelt, es aber wahrscheinlich keine Skripte gibt, die wirklich vom alten Verhalten abhängen, da die Reihenfolge meist zufällig war.
– Wenn ein nicht vorhandener Pfad an ChangeDirectory() übergeben wurde, schlug der Befehl stillschweigend fehl und zeigte keinen Fehler an. Dies wurde jetzt geändert. ChangeDirectory() löst jetzt einen Fehler aus, wenn ein nicht vorhandener Pfad an ihn übergeben wird.
– SaveAnim(), BeginAnimStream() und WriteAnimFrame() unterstützen die Tags Transparency und UseAlpha nicht mehr, da sie einfach keinen Sinn ergeben. Die Transparenz- und Alpha-Einstellungen werden jetzt ausschließlich durch das Format der Quelldaten bestimmt, die an diese Befehle übergeben werden.
– Wenn der Tag KeepProportions für ein Display aktiv ist und DisplayBGPic() oder ChangeDisplaySize() aufgerufen wird, werden die Skalierungsdimensionen jetzt neu berechnet, um das Seitenverhältnis der neuen BGPic- oder Display-Größe anzupassen. Diese Änderung wirkt sich auch auf den Befehl SetDisplayAttributes() aus, wenn sie mit den Parametern Width und Height aufgerufen wird.
– Wenn der Tag Monitor nicht im optionalen Tabellenargument gesetzt ist, erkennt ChangeDisplayMode() jetzt immer automatisch den Monitor, auf dem sich das Display befindet. Wenn es sich also auf einem zweiten Monitor befindet und Sie ChangeDisplayMode(#DISPMODE_FULLSCREEN) aufrufen, wird dieser Monitor in den Vollbildmodus versetzt. Bisher wurde immer der erste Monitor verwendet (außer wenn der Tag Monitor für das Display festgelegt wurde).
– Videos, die vom nativen Video-Modul des Betriebssystems verarbeitet werden (z.B. DirectShow und Media Foundation unter Windows, AVFoundation und QuickTime unter macOS), werden jetzt automatisch in der Größe geändert und neu positioniert, wenn die Größe des Displays vom Benutzer geändert wird, auch wenn kein Skalierungssystem aktiv ist. Dies geschieht rein aus ästhetischen Gründen, da es sonst sehr hässlich aussieht. Sie können dieses Verhalten unterbinden, indem Sie den Tag NoLiveResize in @DISPLAY setzen. Beachten Sie, dass Videos, die mit Hollywoods integriertem Video-Modul verwaltet werden, nicht automatisch in der Größe geändert und neu positioniert werden. Dies geschieht nur bei Videos, die vom Betriebssystem verwaltet werden.

Hollywood 8.0 API-Änderungen

Für Hollywood 8.0 wurden keine Änderungen an der API vorgenommen.

Hollywood 7.1 API-Änderungen

Es gab einige kleine API-Änderungen in Hollywood 7.1. Meist müssen Sie wahrscheinlich Ihre Skripte nicht anpassen, um mit 7.1 arbeiten zu können. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– Es gab einige kleinere Änderungen am plattformunabhängigen Sprachenkatalogformat von Hollywood. Zeilen, die mit einem Semikolon/Strichpunkt (;) beginnen, werden jetzt als Kommentare betrachtet und ignoriert. Wenn Sie eine Katalogzeichenfolge definieren müssen, die mit einem Semikolon beginnt, müssen Sie dem Semikolon einen umgekehrten Schrägstrich (\) voranstellen. Außerdem werden jetzt leere Zeilen ignoriert und Zeichenketten, die mit einem einzigen umgekehrten Schrägstrich enden, gelten als mehrzeilige Zeichenkette. Es könnte notwendig sein, Ihre Sprachkataloge so zu ändern, dass sie mit dem neuen Format kompatibel sind.

Hollywood 7.0 API-Änderungen

Neue Plugin- und Keyfile-Speicherorte unter Windows, macOS, Linux und Android

Zuerst sollten Benutzer von Windows-, macOS- und Linux beachten, dass in Hollywood 7.0 Plugins nun in einem Unterverzeichnis Plugins gespeichert sein müssen, das im selben Verzeichnis wie die Hollywood-Datei unter Windows und Linux sein muss. Unter macOS muss das Plugins-Verzeichnis innerhalb des Programmpakets gespeichert werden, d.h. im Verzeichnis HollywoodInterpreter.app/Contents/Resources/Plugins. Beachten Sie, dass HollywoodInterpreter.app im Programmpaket Hollywood.app gespeichert ist, nämlich in Hollywood.app/Contents/Resources. Auf Android müssen Plugins jetzt im Verzeichnis Hollywood/Plugins auf Ihrer SD-Karte gespeichert werden (statt in Hollywood/_Plugins wie in früheren Versionen). Bei AmigaOS und kompatiblen müssen Plugins wie gewohnt in LIBS:Hollywood kopiert werden.

Beachten Sie, dass ausführbare Dateien, die von Hollywood kompiliert werden, immer noch Plugins aus demselben Verzeichnis wie die ausführbare Datei laden (außer auf macOS, wo sie sich im Verzeichnis des Dateispeichers Plugins befinden müssen). Hollywood selbst wird jedoch jetzt unter Windows, macOS und Linux die Plugins in einem Unterverzeichnis Plugins wie oben beschrieben benötigen.

macOS Benutzer beachten bitte auch, dass die Datei Hollywood.key nun auch ins Verzeichnis HollywoodInterpreter.app/Contents/Resources kopiert werden muss. Es muss sich nicht mehr im Verzeichnis HollywoodInterpreter.app/Contents/MacOS befinden.

Wichtige Unicode-Hinweise und andere API-Änderungen

Da Hollywood 7.0 nun voll Unicode unterstützt, kann es einige Kompatibilitätsprobleme mit Ihren alten Skripten geben. Wenn Sie Ihre Skripte nicht anpassen möchten, können Sie sie einfach im Nicht-Unicode-Modus ausführen, indem Sie Unicode wie folgt deaktivieren:

@OPTIONS {Encoding = #ENCODING_ISO8859_1}

Wenn Sie dies als allererste Zeile in Ihrem Skript hinzufügen, wird Hollywood Ihr Skript im Legacy-Modus laufen lassen und es sollte keine Kompatibilitätsprobleme geben. Allerdings läuft Ihr Skript im Modus ISO 8899-1, was bedeutet, dass es nicht korrekt auf nicht-westeuropäischen Systemen läuft.

Deshalb wird empfohlen, dass Sie Ihr Skript nicht im Legacy-Modus ausführen, sondern immer den Unicode-Modus benutzen. Die meisten Skripte werden wahrscheinlich nur aus der Box laufen, ohne irgendwelche Probleme zu bereiten und ohne irgendeine Notwendigkeit etwas anzupassen. Wenn Ihr Skript Kompatibilitätsprobleme mit Hollywood 7.0 zeigt, lesen Sie bitte die folgende Liste der API-Änderungen von Hollywood 7.0, um zu erfahren, wie Sie Ihre Skripte anpassen können.

– Zuerst einmal stellen Sie sicher, jetzt alle Ihre Skripte mit UTF-8-Codierung zu speichern. Wenn Sie Ihre alten Skripte mit Hollywood 7.0 ausführen, wird Hollywood zunächst prüfen, ob sie nur gültige UTF-8-Zeichen enthalten. Ist dies nicht der Fall wird Hollywood davon ausgehen, dass sich die Skripte in der ISO 8859-1-Codierung (oder der Standard-Codierung des Systems auf Amiga) befinden und sie automatisch in UTF-8 umwandeln. Da diese automatische Konvertierung zu Problemen mit Skripten führen kann, die eine andere Codierung als ISO 8859-1 verwenden, empfiehlt es sich, alle Skripte jetzt in UTF-8 zu speichern.
– Da Hollywood 7.0 standardmäßig im Unicode-Modus läuft, wird nun auch die Standard-Zeichenketten-Codierung auf #ENCODING_UTF8 gesetzt. Dies bedeutet, dass Sie Probleme haben, wenn Ihr Skript versucht, die Zeichenkettenbibliotheks-Befehle zu verwenden, um auf die rohen Binärdaten von Zeichenfolgen zuzugreifen. Wenn die Zeichenfolgencodierung auf #ENCODING_UTF8 gesetzt ist, können sich die Befehle der Zeichenkettenbibliothek nur mit Zeichenfolgen befassen, die gültigen UTF-8-Text enthalten. In Hollywood können Zeichenfolgen aber auch binäre Daten enthalten. Zum Beispiel können Sie eine Datei mit dem Befehl DownloadFile() in eine Zeichenfolge herunterladen und dann ihre Länge mit StrLen() herausfinden. Dies wird nicht funktionieren, wenn Hollywood im Unicode-Modus ist (d.h. wenn die Standard-Zeichenketten-Codierung auf #ENCODING_UTF8 gesetzt ist), da StrLen() dann gültige UTF-8-Daten erwartet. Um dieses Problem zu umgehen, müssen Sie #ENCODING_RAW an StrLen() übergeben, damit die Zeichenkette, die Sie übergeben haben, rohe Binärdaten anstelle des gültigen UTF-8-Textes enthält. Ebenso akzeptieren die meisten anderen Befehle der Zeichenkettenbibliothek einen zusätzlichen Parameter encoding, mit dem Sie die Zeichencodierung der Zeichenkette, einstellen können. Wenn Ihr Skript die Zeichenkettenbibliotheks-Befehle nicht verwendet, um mit rohen Binärdaten zu arbeiten, müssen Sie sich keine Sorgen machen und Ihr Skript sollte im Unicode-Modus einwandfrei funktionieren.
– Die Standardtextcodierung wird auch automatisch von Hollywood 7.0 auf #ENCODING_UTF8 gesetzt. Dies bedeutet, dass Befehle wie TextOut() und Print() jetzt UTF-8 codierten Text erwarten. Dies ist kein Problem, wenn Sie Ihr Skript nur in UTF-8 konvertieren, aber es könnte zu Problemen führen, wenn der auszugebende aus einer Datei (oder einer anderen externen Quelle) gelesen wird, die keine UTF-8-Codierung verwendet.
– ReadChr() und WriteChr() können jetzt bis zu 4 Bytes lesen und schreiben statt nur ein einziges Byte, wenn Hollywood im Unicode-Modus ist. Das ist, weil sie jetzt wirklich mit Zeichen umgehen und in UTF-8 kann ein Zeichen bis zu 4 Bytes für die Speicherung benötigen. Wenn Sie einzelne Bytes lesen und schreiben möchten, müssen Sie jetzt die neuen Befehle ReadByte() und WriteByte() verwenden.
– ReadString() und WriteString() können nicht mehr für binäre I/O verwendet werden, da sie Zeichenketten lesen und schreiben, d.h. wie ihre Namen implizieren eine Anzahl von Zeichen (nicht Bytes!). Wenn Sie rohe Binärdaten lesen und schreiben müssen, verwenden Sie jetzt die neuen Befehle ReadString() und WriteString().
– ReadChr(), WriteChr(), ReadString() und WriteString() lesen und schreiben jetzt standardmäßig UTF-8-Zeichen. Wenn Sie sie verwenden, um Daten aus Nicht-UTF-8-Textdateien zu lesen, kann es Probleme mit Nicht-ASCII-Zeichen geben. In diesem Fall müssen Sie diesen Befehlen mitteilen, dass sie Zeichen im Format ISO 8859-1 lesen, indem Sie #ENCODING_ISO8859_1 im optionalen Argument encoding übergeben.
– Sie sollten die beiden Ereignis-Handler OnKeyDown und OnKeyUp für nicht-englische Zeichen nicht verwenden. Nicht-englische Zeichen sollten nur mit dem neuen Ereignis-Handler VanillaKey behandelt werden, der stattdessen eine vollständige Unicode-Unterstützung hat. OnKeyDown und OnKeyUp werden weiterhin wie bisher arbeiten, aber mit nicht-englischen Zeichen sind sie in der Regel unsicher. Sie könnten mit Ihrem System arbeiten, aber nicht auf Systemen mit einer anderen Länder-/Spracheinstellung. Verwenden Sie nur VanillaKey, um nicht-englische Zeichen zu behandeln.
– Die Befehle IsKeyDown() und WaitKeyDown() unterstützen nicht mehr englische Tasten. Wenn Sie den Zustand einer nicht-englischen Taste erhalten müssen, verwenden Sie stattdessen den Ereignis-Handler VanillaKey.
– Das plattformneutrale Format, das von OpenCatalog() unterstützt wird, muss nun in UTF-8 Zeichencodierung mit oder ohne BOM sein. ISO 8859-1 Dateien werden nicht mehr unterstützt.
– Multi-Byte-Zeichenkonstanten wie 'ABCD' werden nicht mehr unterstützt, da sie mit dem von Hollywood 7.0 unterstützten UTF-8-Zeichenkonstanten in Konflikt stehen. Wenn Ihr Skript Multi-Byte-Zeichenkonstanten verwendet, müssen Sie Ihr Skript umschreiben, um den direkten numerischen Wert der Zeichenkonstante zu verwenden.
– Hollywood 7.0 benutzt neu die Anweisung FallThrough, die es ermöglicht, in den nächsten Case-Bereich einer Switch-Case-Anweisung durchzufallen. Dies bedeutet allerdings, dass es nicht mehr erlaubt ist, Variablen oder Funktionen mit der Bezeichnung FallThrough zu verwenden. Dies wird einen Fehler auslösen, weil FallThrough nun eine reservierte Bezeichnung ist.

Hollywood 6.0 API Änderungen

Es wurden einige kleine API-Änderungen in Hollywood 6.0 durchgeführt. Höchstwahrscheinlich werden Sie Ihre Skripte nicht anpassen müssen, um mit 6.0 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, ob Ihr Skript eine Anpassung erfordert.

– Seit Hollywood 6.0 mit integrierter Unterstützung für vektorbasierte Zeichnungen daher kommt, verwendet die Vektorenbibliothek nicht mehr automatisch die ersten Bilder, um das richtige Plugin zu finden. Stattdessen wird es nun Hollywoods eingebauten Vektorenmodul als Standard verwenden. Wenn Sie dies nicht wollen, müssen Sie den Befehl SetVectorEngine() verwenden, um die Vektorenbibliothek anzuweisen, das Plugin beim Bilder zeichnen zu verwenden.
– Der ChangeDisplayMode() Befehl schaltet nicht mehr alle, sondern nur das aktive Display in den Vollbildmodus. Diese Änderung war notwendig, weil Hollywood 6.0 Multi-Monitor-Unterstützung zur Verfügung stellt, die es ermöglicht, mehrere Displays im Vollbild-Modus auf separaten Monitoren darzustellen.
– Der Hollywood Display-Handler wurde neu geschrieben und unterstützt den Anzeigemodus OwnScreen nicht mehr. OwnScreen war ein spezieller Modus, der auf AmigaOS und kompatiblen Geräte verwendet wurde, um Hollywood im Vollbild-Modus zu öffnen, aber den Bereich um das Display nicht abgedeckt wurde. Das heißt, Hollywood öffnete kein Schutzfenster, welches die Amiga Bildschirm Dekorationen bedeckte. Wenn Sie das Aussehen von OwnScreen erreichen wollen, müssen Sie die Konsolenargumente ‘-nobackfill’ und ‘-nostyleoverride’ zusammen mit ‘-fullscreen’ verwenden. Dann sollte es genau gleich aussehen, wie der alte OwnScreen Anzeigemodus.
– Vor Hollywood 6.0 überschrieben die angegebenen Attribute in der @DISPLAY Präprozessor-Anweisung automatisch die Displayattribute, die mit der Kommandozeile angegeben wurden. D.h. wenn das Borderless-Attribut in @DISPLAY auf False gesetzt und das Skript mit dem Argument ‘-borderless’ gestartet wurde, dann würde das Skript trotzdem noch mit einem umrandeten Fenster angezeigt werden, da die Angaben in @DISPLAY höhere Priorität als die Angaben in der Befehlszeilen hatten. Beginnend mit Hollywood 6.0 wurde dieses Verhalten umgedreht: Displayattribute, welche mit der Kommandozeile gesetzt werden, setzen nun die Displayattribute der Präprozessor-Anweisung außer Kraft. Wenn Sie dieses Verhalten nicht wünschen, kompilieren Sie Ihr Skript mit dem ‘-locksettings’ Argument. Dann sind die Kommandozeilenargumenten nicht mehr in der Lage, Ihre Präprozessor-Displayeinstellungen außer Kraft zu setzen.
– Vor Hollywood 6.0 wurden die Befehlszeilenargumente in den Präprozessor-Anweisungen des Skripts, die die Art der Anzeige definierten, auf alle Displays angewendet. Zum Beispiel wenn Sie ein Skript mit vier Displays mit dem Argument ‘-borderless’starteten, wurden alle vier Displays randlos geöffnet. In Hollywood 6.0 werden Befehlszeilenargumente, die den Anzeigestil ändern, standardmäßig nur auf Display Nummer 1 angewendet. Wenn Sie alle Displays beeinflussen wollen, müssen Sie das neue Argument ‘-alldisplays’ verwenden.
– Einige Befehlszeilenargumente wurden aus rein kosmetischen Gründen umbenannt: ‘-audiodev’ heißt jetzt ‘-audiodevice’ und ‘-depth’ ist nun ‘-scrdepth’. Ihre Funktionalität hat sich nicht geändert.
– Die Unterstützung für mpega.library auf AmigaOS und kompatible Geräte wurde fallen gelassen. mpega.library verursachte einige Schwierigkeiten. Weil es in der Regel jedes Datei-Format als MPEG-Strom erkannte, führte dies zu mehreren unerwünschten Wirkungen. Wenn Sie MP3s abspielen möchten, können Sie stattdessen ein Plugin wie avcodec.hwp verwenden.

Hollywood 5.0 API Änderungen

Es wurden in Hollywood 5.0 einige kleine API-Änderungen vorgenommen. Höchstwahrscheinlich werden Sie Ihre Skripte nicht anpassen müssen, um mit 5.0 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– Die Plugin-Schnittstelle wurde komplett neu geschrieben und ist nicht mehr mit alten Plugins kompatibel. Auf Amiga-Systeme müssen Plugins immer in LIBS:Hollywood installiert werden. Das alte Plugin Verzeichnis Hollywood:Plugins wird nicht mehr von Hollywood 5.0 unterstützt. Alternativ können Plugins in das Verzeichnis des Programms installiert werden (besonders nützlich, wenn Sie Plugins mit kompilierten ausführbaren Dateien von Hollywood verteilen wollen).
– Schatten und Randeffekte auf Ebenen werden im Vergleich zu früheren Versionen anders (besser!) aussehen, weil Hollywood jetzt echte Alpha-Kanal-Mischung für diese verwendet. Der Nachteil ist, dass die neuen Schatten und Randeffekte langsamer als in früheren Versionen sind.
– Schatten und Ränder sind nun für jede Ebene globale Einstellungen. Das bedeutet, dass Sie nicht mehr Ebenen verwenden können, die mehrere Schatten- oder Rahmenarten haben (zum Beispiel eine Textebene, wo nur ein Teil des Textes einen Schatten oder einen Rand hat). Das wird nicht mehr unterstützt. Entweder hat die Ebene einen Schatten/Rand oder nicht. Aber es ist nicht mehr möglich, einen Schatten/Rand nur für einen Teil er Ebene zu haben.
– Ebenen mit einem Rand werden jetzt anders dargestellt, wenn sie mit einem Übergangseffekt angezeigt oder ausgeblendet werden. Da die Ränder in Hollywood 5.0 nicht mehr Teil der Hauptebene sind, kann der Übergangseffekt für den Rahmen nicht mehr mit der Hauptebene kombiniert werden. So wird jetzt Hollywood einfach den Rand verblassen, während der Übergang des Hauptebeneneffekts angezeigt wird. Wenn Sie dieses Verhalten nicht wünschen, können Sie den neuen Tag NoBorderFade verwenden.
– Aus Gründen der Kohärenz unterstützt Hollywood dicke Ebenen nicht mehr, wenn bei Füllungsstil #FILLNONE gesetzt ist. Der Grund ist, dass das Dicke-Ebenenkonzept sich oft nicht mit dem neuen Ebenenränderkonzept verträgt. Anstelle einer Dickeneinstellung darf man den Rändern der Ebene eine 'Dickegröße' zuweisen, um sie dicker zu machen. Die Hauptebene wird jedoch immer eine Dicke von 1 haben. Wenn Sie diese Dicke erhöhen wollen, schalten Sie die Ränder ein und setzen die gewünschte Dicke im Tag BorderSize.
– Hollywood 5.0 bietet Unterstützung für Vektorgrafiken. CreateGradientBGPic() und CreateTexturedBGPic() werden nun ein Vektor-BGPic für Sie erstellen. Das bedeutet, dass Sie nicht mehr die Grafiken dieser BGPics mit dem SelectBGPic() Befehl modifizieren können. Ein weiterer Unterschied ist, dass wenn eine Textur-BGPic skaliert (zum Beispiel, wenn der Benutzer die Größe eines Fensters ändert), Hollywood dann nicht das texturierte BGPic skaliert, sondern es wird auf die neue Auflösung gezeichnet. Vor 5.0 wurden die texturierten BGPic skaliert. Beginnend mit 5.0, werden die BGPic komplett neu gezeichnet.
– Vor 5.0 haben die Befehle CopyFile() und DeleteFile() Platzhalter im Dateinamen als Argument akzeptiert. Dies wird nicht mehr unterstützt. Wenn Sie selektiv Dateien kopieren/löschen möchten, müssen Sie jetzt ein optionales Argument verwenden. Für weitere Informationen lesen Sie die Dokumentation dieser beiden Befehle.
– Vor 5.0, verwendete Hollywood reguläre Dateifilter von AmigaOS in den Befehlen MatchPattern(), CopyFile() und DeleteFile(). Beginnend mit der Version 5.0 verwendet Hollywood plattformunabhängige Dateifilter, die sich von denen im AmigaOS in einigen Fällen unterscheiden. Siehe MatchPattern für Details.
– Lange Zeichenketten [[...]] verhalten sich in Hollywood 5.0 anders, wenn Ihr Skript mit Wagenrücklauf und Zeilenvorschubcodierung gespeichert wurde (CR + LF-Codierung ist der Texteditor Standard auf Windows, Amiga und Unix-Systeme verwenden nur LF-Zeichen für Zeilenumbrüche). Zuvor wurden Wagenrücklauf-Returnzeichen ('\r') immer in die lange Zeichenkette integriert, dies ist nicht mehr der Fall. Alle Zeilenumbrüche werden nun in einzelne Zeilenvorschübe umgewandelt ('\n'). Wenn ein Wagenrücklaufzeichen vorhanden ist, wird es verworfen. Diese Änderung wurde vorgenommen, um zu verhindern, dass Skripte sich anders verhalten, wenn sie auf Windows und auf AmigaOS/Unix/Mac gespeichert wurden.

Hollywood 4.5 API Änderungen

Es wurden in Hollywood 4.5 einige kleine API-Änderungen vorgenommen. Höchstwahrscheinlich werden Sie Ihre Skripte nicht anpassen müssen, um mit 4.5 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– RotateLayer() verhält sich anders in 4.5, als es in 4.0 tat. Dieser Umbruch war notwendig, weil Hollywood 4.5 Ankerpunkte für die Ebenen einführt. In Hollywood 4.0, RotateLayer() dreht die Ebene um seinen Mittelpunkt, so dass ein Ankerpunkt 0.5/0.5 angenommen wurde. In 4.5 haben jedoch alle Ebenen einen Standardankerpunkt von 0.0/0.0. Wenn Sie also das 4.0-Verhalten replizieren möchten, müssen Sie den Ankerpunkt der Ebene auf 0.5/0.5 mit Aufruf von SetLayerAnchor() festlegen.
– Ab jetzt werden Datendateien für Programme, die für macOS kompiliert wurden, nur noch im Ordner "Ressourcen" vom Programmpacket gesucht. Diese Änderung wurde vorgenommen, um die macOS UI-Richtlinien zu erfüllen. Alle Datendateien müssen in seinem App-Packet plaziert werden.
– Wenn Sie mit CreateSprite() einen Sprite-Link (das heißt Typ #SPRITE) erstellen, konnten Sie vorher auch Links von Sprite-Links erstellen. Dies ist nicht mehr möglich. Wenn Sie Sprite-Links erstellen, müssen Sie immer ein Sprite angeben, welches real existiert.
– Wenn sie #VANILLACOPY mit SetAlphaIntensity() verwendeten, zeichnete Hollywood vorher manchmal etwas nicht. Z.B. wenn man versuchte, einen Pinsel mit Maske in einen Alphakanal mit SetAlphaIntensity() und #VANILLACOPY zu zeichnen. Dieses Verhalten hat sich nun geändert: Hollywood zeichnet jetzt die sichtbaren Maskenpixel als 255 Alphaintensität und die unsichtbaren Maskenpixel als 0.
– SelectBGPic() hatte ein geheimes Feature, das nie irgendwo dokumentiert wurde (und somit nicht offiziell war): Wenn Sie SelectBGPic() auf dem aktuellen BGPic aktivierten Ebenen verwendeten, wurden alle Ebenen vor EndSelect() als versteckte Ebenen eingesetzt. Dieses Verhalten ist jetzt weg. SelectBGPic() wird nun normale Ebenen einfügen und zeichnen, wenn EndSelect() aufgerufen wird. Wenn Sie das bisherige Verhalten haben wollen, erstellen sie ihre Ebenen mit dem setzen von Hidden auf True.

Hollywood 4.0 API Änderungen

Es wurden einige kleine API-Änderungen in Hollywood 4.0 durchgeführt. Wahrscheinlich müssen Ihre Skripte nicht anpassen, um mit 4.0 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– SetPointer() Syntax hat sich völlig verändert. Es ist wird nicht mehr ein Dateinamen akzeptiert, sondern erfordert, dass Sie zuerst CreatePointer() aufrufen.
– Alle Übergangs-Effekte sowie die Befehle PlayAnim(), die MoveXXX() & DisplayBGPicPart() verwenden jetzt eine neue Syntax. Allerdings wird die alte Syntax noch aus Kompatibilitätsgründen unterstützt.

Hollywood 3.1 API Änderungen

Es wurden einige kleine API-Änderungen in Hollywood 3.1 durchgeführt. Wahrscheinlich müssen Ihre Skripte nicht anpassen, um mit 3.1 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– Doppelpunkt wird nicht mehr als Befehlstrenner unterstützt. In Hollywood 1.x wurde der Doppelpunkt verwendet, um mehrere Befehle auf der gleichen Zeile zu trennen, z.B.
; Hollywood 1.x Code - wird nicht länger unterstützt x=100:y=200:width=50:height=50:Box(x, y, width, height, #RED)
Der 1.x Emulator innerhalb von Hollywood emuliert dieses Verhalten bis zu Hollywood 3.0. In Hollywood 3.1 wird es nun nicht mehr unterstützt, da der Doppelpunkt für die objektorientierte Programmierung erforderlich ist. So müssen Sie Ihre Skripte aktualisieren, wenn Sie noch Doppelpunkte verwenden, um mehrere Befehle in einer einzigen Zeile zu trennen. Seit Hollywood 2.0 können Sie so viele Befehle in einer einzigen Zeile setzen, wie Sie möchten, so dass der obigen Code nun wie folgt geschrieben wird:
x=100 y=200 width=50 height=50 Box(x, y, width, height, #RED)
Das sieht nicht sehr schön aus, so dass Sie wahrscheinlich vom Aufrufen mehrere Befehle auf der gleichen Zeile gänzlich verzichten werden.
– Der #TYPEWRITER Übergangseffekt ist jetzt weg. Dies war ein besonderer Effekt, der nur auf Textobjekte verwendet werden konnte. Allerdings machte es die Schriftschnittstelle unnötig komplex, so dass er wegfallen musste. Sie können nur mit einer Reihe von Print() aufrufen das Verhalten von #TYPEWRITER emulieren.

Hollywood 3.0 API Änderungen

Es wurden einige kleine API-Änderungen in Hollywood 3.0 durchgeführt. Wahrscheinlich müssen Ihre Skripte nicht anpassen, um mit 3.0 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– Wenn Hollywood 3 ohne Argumente gestartet wird, wird es im Fenstermodus geöffnet. Alle vorherigen Versionen öffneten Vollbildmodus. Aber ich denke, es ist viel klüger, Hollywood öffnet sich im Fenstermodus, weil der Vollbildmodus möglicherweise nicht auf jedem System läuft.
– Kommandozeilenargumente werden nun anders gehandhabt. Sie müssen sie mit einem Bindestrich als Präfix (-) verwenden. In früheren Versionen haben Sie Hollywood wie folgt aufgerufen:
Hollywood script.hws WINDOW BORDERLESS
Dies wird nicht mehr funktionieren! Sie müssen jetzt Bindestriche verwenden. Der richtige Aufruf von Hollywood ist nun:
Hollywood script.hws -window -borderless
Diese Änderung war notwendig, weil der neue GetCommandLine() Befehl mit seinen eigenen Argumenten arbeitet.
– Das zweite Argument von FileRequest() hat sich geändert. Bisher war es ein Muster im AmigaDOS Format. Nun ist es ein Zeichenkettenfilter der angibt, welche Dateien angezeigt werden sollen. Diese Änderung war wegen der neuen plattformübergreifende Natur von Hollywood notwendig. Betriebssysteme wie Windows und macOS haben einfach nicht so aufwendige Filtermuster wie es das AmigaOS bietet.
– In früheren Version fiel beim Befehl OpenFile() das optionale dritte Argument auf #MODE_READWRITE zurück, wenn es nicht angegeben wurde. Dies wurde geändert. Nun ist der Standardmodus #MODE_READ. Ich denke, es macht viel mehr Sinn, den schreibgeschützten Modus zum Öffnen von Dateien als Voreinstellung zu verwenden.

Hollywood 2.5 API Änderungen

Es wurden einige kleine API-Änderungen in Hollywood 2.5 durchgeführt. Wahrscheinlich müssen Ihre Skripte nicht anpassen, um mit 2.5 zu arbeiten. Überprüfen Sie einfach die folgenden Hinweise, um zu sehen, ob Ihr Skript eine Anpassung erfordert.

– Die Unterstützung für ttengine.library wurde entfernt. Natürlich wird dieser Schriftartentyp in Hollywood immer noch unterstützt. Das einzige, was Sie nicht mehr tun können, ist mit SetFont() *.ttf Dateien direkt zu verwenden.
SetFont("dh1:arial.ttf") ; das ist Hollywood 2.0 Code!
Dies gilt nicht mehr. In Hollywood 2.5 können Sie nur TrueType-Schriftarten verwenden, die in Ihrem System mit dem FTManager oder einem ähnlichem Werkzeug installiert wurden. Sie öffnen diese, als wären sie normale Schriften:
SetFont("Arial Narrow.font") ; OKAY in 2.5!
Hollywood 2.5 lädt alle TrueTypes, die kompatibel mit der bullet.library ft2 (OS4) oder freetype2 (MorphOS, AROS, AmigaOS3) Schnittstellen sind.
– Der Befehl CheckEvent() wurde entfernt. Er passte nicht mehr in das Konzept. Bitte verwenden Sie jetzt stattdessen immer den Befehl WaitEvent().
– Der Befehl Plot() funktioniert jetzt nur mit ausgeschalteten Ebenen. Die Ebenen des Typs #PLOT sind nicht mehr möglich. Es macht einfach keinen Sinn, 1x1 große Ebenen zu haben. Wenn Sie das wirklich benötigen, können Sie den Befehl Box() verwenden, um ein Pixel zu zeichnen.
– Aufgrund des neuen Textdarstellungmoduls ist es nun zwingend, zwei eckigen Klammern in den Zeichenketten von den Befehlen Print(), TextOut() und CreateTextObject() zu verwenden, wenn Sie eine einzelne eckige Klammer ausgeben möchten. Zum Beispiel kann der folgende Code
Print("[Hello World]") ; das ist Hollywood 2.0 Code!
einen Syntaxfehler in Hollywood 2.5 erzeugen, da das neue Textmodul einen Formatierungsbefehl nach der eckigen Klammer erwartet. Ab jetzt müssen Sie den Code so wie folgt schreiben:
Print("[[Hello World]]") ; OKAY in Hollywood 2.5!
Dann wird es funktionieren, wie Sie es erwarten.
– Wenn der Füllstil #FILLTEXTURE oder #FILLGRADIENT eingestellt ist und Sie einen ARGB-Wert verwenden, werden jetzt diese Stile auch den Alphawert beachten. Dies war in Hollywood 2.0 nicht der Fall.
– Wenn Ebenen aktiviert sind und Sie einen Befehl aus der Zeichenbibliothek aufrufen (z.B. Ellipse()) und eine ARGB-Farbe angeben (d.h. Sie möchten mit Transparenz zeichnen), würde Hollywood 2.0 für Sie eine transparente Ebene erstellen, als ob Sie den Befehl SetLayerTransparency() mit dem A-Byte des ARGB-Wert als Transparenzeinstellung angegeben hätten. Dies wird nicht mehr länger auf diese Weise geschehen. Wenn Sie mit einer ARGB-Farbe zeichnen, wird Hollywood 2.5 der Ebene keine Transparenzeinstellung geben, obwohl die Ebene jetzt eine Transparenz hat. Aber mit Hollywood 2.5 wird die Transparenz bereits in den Grafikdaten wiedergegeben (d.h. im Alpha-Kanal) und ist nicht dynamisch wie im Fall von SetLayerTransparency() gehalten.
– Bis zu Hollywood 2.0 hat RotateBrush() immer ein Pinsel der maximalen Größe zurückgegeben, die eine Rotation mit dem Originalpinsel einnehmen könnte, das heißt maxs = sqrt (Breite * Breite + Höhe * Höhe). Der neue Pinsel von Hollywood wäre dann die Breite und Höhe 'maxs' zugewiesen. Dies ist nun nicht mehr der Fall. Der Pinsel ist genau so groß wie alle Grafiken sind.
– In Hollywood 2.0 verwenden WriteMem() und ReadMem() immer ungepuffertes IO, während alle anderen DOS-Befehle IO gepuffertes einsetzen. Jetzt sind alle Befehle einheitlich und sie verwenden nun alle standardmäßig gepuffertes IO. Darüber hinaus wurde in Hollywood 2.0 bei WriteMem() immer automatisch vor dem Start des Schreibvorgangs der Puffer geleert. Dies wird in 2.5 nicht mehr durchgeführt. Also wenn Sie WriteMem() oder ReadMem() in Ihren Skripten verwenden und Sie müssen ungepufferte IO wie in 2.0 haben, rufen Sie zunächst SetIOMode() auf, um den IO-Modus auf ungepuffert zu ändern. Dann wird es funktionieren, wie Sie es gewohnt sind. Aber denken Sie daran, dass es nicht den Puffer wie in Hollywood 2.0 leert. Und denken Sie daran, sobald Sie SetIOMode() aufrufen, alle anderen DOS-Befehle auch den hier eingestellte IO-Modus verwenden werden! Wenn Sie nur für WriteMem() oder ReadMem() ungepuffertes IO wollen, müssen Sie SetIOMode() wieder nach Ihrem Aufruf verwenden. Sie müssen auch FlushFile() manuell aufrufen, wenn Sie auf die gleiche Datei von ungepuffertem IO auf gepuffertes wechseln. Das alles klingt ein wenig kompliziert, aber es ist wirklich einfach. In der Tat gibt es Ihnen die volle Kontrolle über die DOS-Befehle. Bitte beachten Sie die Dokumentation von SetIOMode() für weitere Informationen.
– Bis zu Hollywood 2.0 richtete der Befehl TextOut() automatisch den Text aus, wenn eine spezielle Koordinatenkonstante wie #CENTER oder #RIGHT als x angegeben wurde. Dies wird nicht mehr auf diese Weise durchgeführt. Es gibt ein neues Argument, das Sie für die gewünschte Ausrichtung angeben können.

Hollywood 2.0 API Änderungen

Obwohl Hollywood 2.0 ein gigantisches Update ist, waren nur wenige API-Änderungen erforderlich. Hier ist eine Liste der Dinge, die Sie in Ihrem Skript ändern müssen:

– Wenn Sie Befehle aufrufen, die keine Argumente akzeptieren, aber einen Wert zurückgeben, müssen Sie Klammern verwenden. Zum Beispiel arbeitete der folgende Code in 1.9, aber funktioniert nicht mehr in 2.0:
; falsch! x = MouseX y = MouseY
Sie müssen das nun folgendermaßen schreiben:
; richtig! x = MouseX() y = MouseY()
Die falsche Version wird durch die Art und Weise nicht einen Compiler-Fehler auslösen. Es ist richtiger Hollywood Code, tut aber etwas ganz anderes: Er weist den Befehl MouseX() der Variablen x zu. Das ist in diesem Fall aber nicht das, was Sie wollen.
– GetTimer() liefert jetzt immer den Wert in Millisekunden. In Hollywood 1.x war die Standardeinheit Sekunden. Natürlich hätte ich die alte Implementierung beibehalten können, aber es gibt ehrlich gesagt niemand, der einen Rückgabewert in Sekunden will, weil er einfach zu ungenau ist. So entschied ich den Programmierer einen Gefallen zu tun und Millisekunden als Standard zu setzen, so dass Sie nicht jedes Mal den langen GetTimer(1, #MILLISECONDS) eingeben müssen, sondern nur noch GetTimer(1).
– Die Befehle MoveBrush(), MoveTextObject(), MoveAnim() ... können nicht mehr alte Objekte "greifen". Zum Beispiel arbeitet der folgende Code in 2.0 nicht korrekt:
MoveBrush(1, #LEFTOUT, #CENTER, #CENTER, #CENTER) Wait(100) MoveBrush(1, #CENTER, #CENTER, #RIGHTOUT, #CENTER)
In Hollywood 1.x bewegt dieser Code den Pinsel 1 von links außen in die Mitte, wartete 100 Millisekunden, und bewegt den Pinsel nach rechts außen. In Hollywood 2.0 wird es das Gleiche tun, aber die eine Kopie vom Pinsel wird in der Mitte des Displays bleiben. Dies ist auf große Veränderungen in dem Auffrischungssystem zurückzuführen. Wenn Sie das 1.x Verhalten imitieren wollen, verwenden Sie MoveSprite() anstelle von MoveBrush().
– DisplayTransitionFX() kann nicht mehr für transparente Hintergrundbilder verwendet werden; Umschalten auf transparente BGPics kann jetzt nur noch ohne Wirkung erfolgen. Dies liegt daran, dass Hollywood 2.0 jetzt echte transparente Fenster auf MorphOS, OS4 und AROS verwendet. Diese Fenster haben eine Ebene, wo keine Grafiken erstellt werden können.
– In Hollywood 1.x MixBrush() skalierte die beiden Pinsel gleich groß, wenn sie unterschiedliche Abmessungen hatten. Dies ist nicht mehr der Fall. MixBrush() mischt nur noch die Teile, die passen und verwirft entsprechend den Rest.
– RotateBrush() wird nun eine Maske für den Pinsel erstellen, wenn es noch keine hat. Sie müssen dies nicht mehr auf eigene Faust tun.
– Wenn Ebenen aktiviert sind und Sie InKeyStr() benutzen, wird nur eine Ebene des Typs #PRINT installiert werden. In Hollywood 1.x erzeugte InKeyStr() für jedes Zeichen eine #PRINT Ebene.

Hollywood 1.9 API Änderungen

Es gab in Hollywood 1.9 einige kleinere API-Änderungen, die hier aufgeführt sind:

– Die Befehle EnableEventHandler() und DisableEventHandler() wurden entfernt. Sie könnten viel Ärger verursachen, denn wenn man sie verwendet, müssen Sie nicht wissen, wann Ihre Ereignisfunktionen aufgerufen werden. Bitte benutzen Sie nun den neuen Befehl CheckEvent().
– EnablePrecalculation() und DisablePrecalculation() wurden entfernt, weil Effektvorkalkulation von Hollywood nicht mehr unterstützt wird. Das Argument/Tooltype PRECALCULATION fällt darum auch weg.
– WhileMouseOn() hatte einige Änderungen erfahren, die Sie wahrscheinlich unter bestimmten Umständen feststellen könnten: In früheren Versionen sprang Hollywood sofort zu Ihrer WaitEvent()-Schleife zurück, nachdem ein OnButtonClick Ereignis aufgetreten ist. Dieses Verhalten war falsch! Jetzt wird es zurück zu Ihrem Befehl WhileMouseOn() springen, weil die Maus nach ONBUTTONCLICK immer noch über dem Knopf ist. Wenn Sie möchten, dass Hollywood 1.9 sich wie Hollywood 1.0 und 1.5 verhält, können Sie den neuen Befehl BreakWhileMouseOn() verwenden.

Hollywood 1.5 API Änderungen

Leider hatte ich in dem Update von Version 1.5 einige API-Änderungen an der Hollywood Sprache vornehmen müssen. Wenn Ihr Skript nicht richtig unter Hollywood 1.5 funktioniert, aber arbeitete unter 1.0 tadellos, so lesen Sie bitte die folgenden Informationen durch und passen Sie Ihr Skript an.

– Die Syntax der Konstante hat sich geändert. In Hollywood 1.0 gaben Sie nur durch ihren Namen Konstanten an, aber jetzt werden Sie auch ein '#' als Präfix angeben müssen (zum Beispiel #CENTER statt CENTER und #BOLD anstelle von BOLD). Es tut mir leid, aber diese Änderung war absolut notwendig.
– Undo() wird nicht funktionieren, bis Sie EnableLayers() aufgerufen haben. Wenn Sie Undo() in Ihrem Skript verwenden, stellen Sie also sicher, dass Sie EnableLayers() am Anfang benutzt haben.
– Syntax von PlaySample() hat sich geändert. Sie können nicht mehr einen Kanal für die Wiedergabe festlegen. Hollywood wird alles für Sie tun. Geben Sie einfach die Nummer des Samples an und ob es als Schleife (loop) abgespielt werden soll oder nicht.
– Syntax von PlayAnim() hat sich geändert. Es läuft jetzt synchron. Diese Änderung war notwendig, weil die alte PlayAnim() Umsetzung nicht mehr in das Konzept passt. Wenn Sie Anims asynchron abspielen wollen, verwenden Sie Pinsel-Link-Frames und zeigen sie mit DisplayBrush() an. Da PlayAnim() nun synchron ist, sind die Befehle IsAnimPlaying() und WaitAnimEnd() nicht mehr erforderlich und wurden entfernt.
– ClearScreen() wurde entfernt, weil es nicht mehr ins Konzept passte.
– LoadModule() lädt nicht mehr THX, P61 oder MED-Modul. Modulunterstützung konzentriert sich nun auf das Protracker-Format. Andere Modulformate können nicht sauber durch AHI abgespielt werden.
– Print() unterstützt Antialiasing für TrueType-Schriftarten nicht mehr. Diese Änderung war notwendig, um zurzeit mit Ebenen kompatibel zu bleiben. Antialiasing wird für alle Objekte in Hollywood 2.0 wieder eingeführt.

Navigation zeigen