Suggestions

OSDM Version: V2.01.140 V2.21.274

Text Effects and Fonts

Wegen Text Effects. Ich finde die „Size“ option beim Amiga Text Super. Sollten die anderen Text effects auch haben.

Ausserdem die separate definition des fonts fuer scroller, zini text, page text etc. (wie beim Amiga Text) Das oeffnet einem gleich unendlich mehr moeglichkeiten. Ich wuerde sogar soweit gehen, dass fuer jeden der Scoll Texte ein eigener Font konfiguriert werden kann. Auch wichtig das fixen von anderen bugs und quirks.

Weitere Vorschlaege und Ideen zum Thema Text Effects, speziell fuer die Amiga Text und Page Text features kann man in dieser discusion mit Jizzy finden.

Hier ist auch noch ne Suggestion vom Bobo

„Fonts. Wildcop hat sich sehr viel Arbeit mit den Fonts gemacht (Klasse !! ) , hier hätte ich noch ne besondere Idee…. Und zwar um die Demo klein zu halten eine Möglichkeit zum einbinden von TTF Fonts. Die Bitmapfont müsste dann halt beim Starten der Demo erzeugt werden.“

Fonts Defintion

Es ist schade das die Fonts in OSDM eine feste Groesse haben muessen.

Ich musste meinen Font der eigentlich 21 pixel gross is tweaken, damit er zu einem 32×32 font wurde. Ich weiss nicht was die konsequenzen sein wuerden, aber es waere cool, wenn ich die Raster Groesse des fonts selber bestimmen kann und an Hand dieser nummern (X und Y) dann der Font aus dem Image geparsed wird.

Die Reihenfolge der Buchstaben muss natuerlich immer die gleiche sein.Das macht dann auch die Bildaufloesung fuer das Font Image praktisch unerheblich. Ich koennte dann alle zeichen nebeneinander in ein breites und sehr flaches image packen oder auch nicht, wo dann das naechste Zeichen auf der naechsten Zeile erwartet wird, wenn auf der aktuellen Zeile am Ende kein Platz mehr dafuer ist. Ich hoffe das diese Erklaerung Sinn macht hehe.

Das mit der Font Erweiterung um weitere characters waere dann ueberhaupt kein problem. Das geile ist das durch diese Aenderung die alten Fonts ja immer noch funktionieren und nicht geaendert werden muessen. In den Prefs INI files steht ja in der ersten Zeile auch die Versions Nummber der OSDM Version drin mit der sie erstellt wurden. z.B. “;O.S.D.M v1.61.184“ in der aktuellen Version.

Wenn die mit einer neuen Version eingelesen werden die dynamische fonts unterstuetzt, koennen die noetigen parameter automatisch vordefiniert werden, also keine Arbeit fuer den User.

Noch ne weitere Idee fuer die Font sets Definierung, die mir eingefallen ist als ich Deine Idee gesehen habe von wegen extended sets.

Peace: Lass doch den User in den Settings selber definieren welche Zeichen und in welcher Reihenfolge in seinem Font sets zu finden sind. Speicher einach die Unicode definitions ab (was Du dann auch bei den Texten machen solltest) Standard wegen der Backwards Compatibility waere dann wieder die Zeichenkette:

{SPACE}!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[

und wer dann Bock hat spezielle Fonts zu erstellen koennte dann machen was er will, sogar Intros mit text in Russisch, Arabisch, Griechisch, Chinesisch, Japanisch, Koreanisch und… okay, you got the idea hehe.

Ich koennte sogar Block ASCII fonts erstellen mit Zeichen wie

░ ▒ ▓ █ ▀ ▄ ▌ ▐ ■ ▪ ┌ ┐ └ ┘ ─ │ ├ ┥ ┴ ┯ ╞ ╟ ╚ ╔ ╩ ╦ ╠ ═ ╬

Ich finde die „Size“ option beim Amiga Text Super. Sollten die anderen Text effects auch haben. Ausserdem die separate definition des fonts fuer scroller, zini text, page text etc. (wie beim Amiga Text) Das oeffnet einem gleich unendlich mehr moeglichkeiten. Ich wuerde sogar soweit gehen, dass fuer jeden der Scoll Texte ein eigener Font konfiguriert werden kann. ░ ▒ ▓ █ ▀ ▄ ▌ ▐ ■ ▪ ┌ ┐ └ ┘ ─ │ ├ ┥ ┴ ┯ ╞ ╟ ╚ ╔ ╩ ╦ ╠ ═ ╬

Text Effects

Ich haette da auch noch eine grundsaetzliche empfehlung zu diesem Thema mit den „Text Effekten“.

Es waere sehr sinnvoll, wenn man grundsaetzlich den REIN und den RAUS effekt separat spezifizieren koennte. Im Falle des Amiga Text und auch des Page Text Effects macht die Verwendung von Control Codes wie beim Scroll Text sehr viel Sinn. Die Codes wuerde man dann am Anfang und/oder auch am Ende einer Seite festlegen. So koennte man die Effekte dann sogar fuer jede einzelne Seite variieren und sogar kombinieren. ^F^TL^ZI1 zum Beispiel koennte bedeuten ^F = Fade, ^TL = Type Left to Right, ^ZI1 = Zoom IN from 1×1 pixel

Die Seite wird also Zeichen fuer Zeichen von links oben Zeile fuer Zeile aufgebaut, wobei die Zeichen von 1×1 pixeln auf die Zielgroesse gezoomed und gleichzeit eingefaded werden. Die Bedeutung der Control Codes wuerde sich dann bei der definition des FADE-OUTs (am ende einer seite) umkehren auf das gegenteil. Also Reinzoomen wird Rauszoomen und Reinfaden wird zu Rausfaden.

Damit wuerde IMO die best moegliche flexibiliaet mit gleichzeitiger Einfachheit der anwendung ergeben. Die Einfuehrung von Control Codes fuer diese Effects koennte dann auch noch weiter ausgebaut werden, zum beispiel um innerhalb einer seite die Aufbaugeschwindigkeit zu manipulieren oder auch je nach gewaehlten Fade-In effecten spielereien wie das loeschen von zeichen (backspace emu) oder die freie bewegung eines „Cursors“ innerhalb einer textseite.

Es ist schon klar das Bestimmte kombinationen von TEXT-IN und TEXT-OUT effects keinen sinn ergeben oder zweideutigkeiten verursachen. Da muessen dann Fallentscheidungen getroffen werden (wie „Ignore“ oder „Preference“) die man huebsch schon im code fuers spaetere „Manual“ fuer die Advanced Users beschreiben sollte „along the way“.

Die selben regeln kann/sollte man danach auch im User Interface („Jizzy's“ Knoepfe und Haeckchen) beruecksichtigen, duchs deaktivierung/aktivierung von optionen und/oder auch durch fehlermeldungen oder/und warnungen oder/und Erklaerungen.

Die Control Codes haben eher weniger or gar nicht mit dem Scripten zu tun. Sie sind viel mehr wie die codes die es schon fuer den Scroll Text gibt.

Nachdem es die beschriebene funktionalitaet gibt, kann man auch ohne weiteres das grafische user interface verbessern und vereinfachen. Zum Beispiel koennte es fuer jede seite am anfang und am ende eine sektion gebem fuer die definition der ein und ausblend effekte. Das kann zum Anfang ne text box sein oder auch Check boxes und dropdowns usw., die dann intern einfach nur zu den Control Codes umgemodelt werden (von wegen rueckwaerts kompatibilitaet usw.)

Erst die codes um die gewuenschte funktionalitaet zu liefern und dann das user interface ausbauen… so geht das und nicht anders herum, sonst verlaeuft sich das ins nix und wird nie etwas.

Character Animation for Amigatext

Siehe Text-Effect in der Demo “War and Peace“. In der Demo wird eine Vertikale Ganzbild Animation (Logo) verwendet, aber man koennte wahrscheinlich ohne zu grossen Aufwand in aehnlicher form was im OSDM fuer den Amigatext mit einbauen, wo man dann nur eine Einzelcharacteranimation braeuchte, die fuers ein oder Ausfaden fuer alle Zeichen ausser „Space“ verwendet werden wuerde. Die sollte man dann beim Amigatext separat wie den „Copper“, „Rotate“, „Zoom“ und „Fade“ fuers Ein- und Ausfaden an und ausstellen koennen.

Ne Animationsoption fuer jedes einzelne Zeichen separat hoert sich auch cool an, wuerde aber meiner Meinung nach ein wenig zu weit gehen, nicht?

Das die Characteranimation von der Groeese mit der ausgewaehlten Schriftgroesse fuer den Amigatexteffekt uebereinstimmt ist die Verantwortung des Users und nicht von OSDM. Zur Vereinfachung und Vermeidung von Fehlern koennte OSDM auch automatisch die ausgewaehlte Schriftgroesse als Framewidth fuer die (angenommene) Horizontal Chracterframeanimation verwenden und den User via Meldung darauf aufmerksam machen, wenn die Image Width nicht teilbar ist durch die Pixelbreite des Fonts. Die Animationsgeschwindigkeit sollte automatisch mit der Effektgeschwindigkeit angepasst werden.

Megatro Exit

Empfehlung fuers Megatro feature. Derzeit wird eine EXE mit allen intros erstellt. Ein Megatro wird immer im Vollbild ausgefuehrt (womit ich leben kann). Der „Exit Key“ wird automatisch zu „Space“ gesetzt, egal was bei den einzelnen intros spezifiziert wurde. Es wuerde mehr sinn machen, wenn man „Space“ zwar benutzt um einen teil des Megatros zu beenden um zum naechsten zu springen, gleichzeitig sollte man aber auch einen Exit Key definieren (z.B. „ESC“) um das gesammte Megatro abzubrechen und zu beenden, ohne zum naechsten teil zu springen. Das Fehlen dieser Option war der Hauptgrund warum ich ein eigenes Interface fuer mein Megatro 2009 geschrieben habe. Ich wollte es keinem zumuten durch 28 intros springen zu muessen, nur um wieder aus dem demo rauszukommen.

Sprites

Auszug aus der deutschen Doku: „Bufferbereich von 512KB zur Verfügung: 1 Sprite = 512KB, 2 Sprites = 256KB, 4 Sprites = 128KB.“

Wenn ich Sprites benutze, dann habe ich meistens ein paar groessere und ein paar kleinere. Wenn ich 4 sprites habe und 3 davon zusammengenommen nur 12 KB gross sind z.B., dann ist doch noch 500 KB platz da. Das es dann nicht groesser als 128K sein kann ist bloed. Die speicherbloecke werden ja eh dynamisch bestimmt (also musst du ja dafuer ne function oder so haben). Bau doch einfach mal ein dass er anstatt 512/# enabled sprites ueber die enabled sprite slots enumerates und die image groessen verwendet. Wenn er 512KB erreicht hat, dann nimmt er keine weiten spirtes mehr an und Du kannst ne Fehlermeldung rauswerfen.

Wenn die 512 KB das Hauptproblem ist und nicht die Anzahl der Sprites, dann waere es wirklich cool, wenn man praktisch unbegrenzt viele sprites definieren koennte, solange die summer der Groesse der einzelnen Sprites nicht groesser als 512 KB ist. Das Interface in OSDM koennte man in diesem fall so gestalten, das man im Sprites TAB den Schalter fuer die nummer der aktiven Sprites (innerhalb des „Set“ Frames) dazu verwendet auf der linken Seite dementsprechend viele Sprites zur Verfuegung zu stellen (mit ON Checkbox, ID und Dateiname). Ich benutze kleine Sprites fuer alles moegliche und bin immer genervet, wenn entweder schon alle 8 sprite slots voll sind oder ich einige der noch freien slots nicht mehr verwenden kann, wegen einem wichtigen sprite das dann zu gross sein wuerde und rausgeschmissen wird. Viele dieser kleinen Sprites sind nur 1-3 KB gross im Schnitt.

Single-Loop / Reverse-Loop Features

a) Auch ein nützliches Feature wäre wenn man die Möglichkeit hätte eine Sprite Animation nur einmal durch laufen zu lassen und beim letzten Bild stehen zu lassen. Das könnte man per Checkbox in dem Bereich wo die Sprites auch geladen werden machen und sollte für jedes Sprite separat an wählbar sein Standard Einstellung sollte der Loop sein. Sollte nicht allzu schwer sein da man ja sowie so die Anzahl der Frames angeben muss, und anstatt beim letztn Frame wieder auf Frame 0 zuspringen wird halt immer wieder auf das letzte Frame gesprungen.

b) Auch sehr hilfreich in einigen Situationen waere die Option fuer eine Sprite Animation vorwaerz und dann rueckwaerz abzuspielen anstatt wieder von vorne. Endlos-Animationen sind zwar am besten, aber nicht immer machbar. Da diese dadurch „springt“ wenn sie nach dem letzten Frame wieder bei Frame 0 anfaengt, waere es in diesem Falle natuerlich besser, wenn nach den letzten Frame das vorletzte angezeigt wuerde, dann das vor-vorletzte usw., bis es wieder bei 0 ist und dann wieder normal vorwaerz laeuft.

Animated Gifs

While Frame Animations kind of work, would it be nice, if Animated gifs would be supported. This would probably also create a workaround for the 4000 pixels width/height limit of frame animations on some computers. The biggest advantage of Gif animations over frame animations is the ability to change the animation speed on a frame by frame basis, something that is one, if not the biggest shortcoming of frame animations.

The drawback of animated gifs would be the loss of the ability to change the animation speed and maybe other features as well, such as the rotation, scroll, zoom and alpha/fading feature, if that should become necessary. It would be an acceptable trade-off IMO.

Weitere Ideen und vorschlaege zum selben Thema

Zum problem „Grosse Grafiken“ fuer Animationen: Das ist eigentlich das groesste argument zur unterstuetzung von animated gifs oder vergleichbarem.

Nur schon alleine fuer die option auf frame-basis festzulegen wie lange ein frame angezeigt wird. Das reduziert in fast allen faellen schon die anzahl von benoetigten frames erheblich.

Da animated gif gleich noch ne menge andere sachen mit bringt, die es wahrscheinlich schwierig machen es so null komma nix im OSDM einzubinden, waere als alternative auch moeglich das man irgendwo fuer die frame animation nen „directions“ file hinterlegen kann, wo fuer die einzelnen frames die anzeigedauer definiert werden kann. Tools wie FAC oder auch 3rd party wuerden dabei dem user helfen diese definitionen zu erstellen, moeglicherweise sogar aus animated gif source dateien.

Siehe dazu auch ideen vom Bobo hier, die das generelle resources management vom OSDM betreffen

Scripting

Song Selection for TRAINER

Selektion eines Songs und switch to „ON“ via OSDM Script mittels IDN=X

CAL=TRAINER
LEA=TRAINER
IDN=1   ;Auswahl des 2ten Tunes im Trainer Menu

Custom Exit

Cool waere es, wenn man noch was machen koennte, wenn der user ESC oder SPACE (je nach Introeinstellung) drueckt, um das intro zu beenden. Um zum Beispiel ein eigenes „ausblende“ feature zu bauen oder noch nen „credits“ screen zeigen will und so etwas (mit getimeter musik ausblendung zum Beispiel). Das ESC Kommando sollte dann immer noch wie eh und je die normale OSDM intro exit routine ausfuehren.

Mehr dazu und auch Beispiele siehe suggestions osdm script

Generelle Ideen von Bobo

„Der OSDM hat eine tolle Scriptsprache mit der ne ganze Menge möglich ist. Ein Script ist im „GM“ auch mit enthalten, aber er wird etwas anders eingesetzt. Und zwar kann man hier auf jedes Objekt einen Script legen, womit ne ganze Menge mehr Effekte zu erstellen sind. Ausserdem hat der „Raum“ ( Im OSDM die Demo ) selber noch einen Script. Ich denke es sollte kein Problem sein einen Script auf jedes Objekt zu legen. Ich meine Logo,Sprites und so… Den Globalen Script hat der OSDM ja bereits. Ist vieleicht etwas Fummelei, sollte aber möglich sein.“

Timen

Das timen ist grundsaetzlich ein problem. IFT = XX anweisungen klappen nur, wenn das script gerade an der stelle der anweisung ist. Das ist natuerlich bloed, wenn man effekte hat, die voneinander abhaengen, z.b.

IFT = 10 : JSR = 1 ;blende was ein IFT = 20 : JSR = 2 ;blende es wieder aus

Und wie gesagt das timen ist ein problem im allgemeinen. Gibt es irgendwelche formeln mit denen sich errechnen laesst wie lang ein NOP ist und +1 Introzeit? Ist mir schon klar, dass das von der FPS und wahrscheinlich auch von der „Speed“ Einstellung des Regie -Screens abhaengt.

Mir ist inzwischen schon aufgefallen, das die dauer eines NOP (NOP = 1) im umgekehrten Verhaeltnis zur Framerate steht. Also ein NOP = 1 bei einer FPS = 30 ist 50% oder sogar mehr kuerzer als bei FPS = 60, was ich zwar irgendwie unlogisch finde, aber doch in der Praxis so erlebt habe. Die Introzeit vergeht bei niedrigerer Framerate auch schneller. Ein NOP ist aber auch nicht genauso lang wie ein Intervall der Introzeit. Wie gesagt, ein paar genauere Formeln waeren hier sehr hilfreich. Das ist keine wirkliche Aenderung im Source was hier gebraucht wird, sondern Dokumentation :).

User Variables

Die definition von user variablen wuerde viele sachen einfacher machen. Zum Beispiel zum Speichern, ob ein bestimmter Event eingetroffen ist oder nicht. Ein paar fixe user variablen (e.g. VAR1 - VAR10) wuerden es auch erst einmal tun.

siehe suggestions osdm script

Dokumentation des Script Features Allgemein

Die Dokumentation ist auch haeufig nicht sehr aufschlussreich. In machen Faellen muss man NOP's verwenden, damit der Gewuenschte Effect funktioniert, manchmal auch nicht. Die Effect steuerung via codes im Scroll Text haben auch erst funktioniert nachdem ich die PSH Anweisung vorher ausgefuehrt hatte. Was die IFR Anweisung genau macht ist mir auch noch nicht klar. Was ist der niedigste wert und was der hoechste und wie errechnen sich die wahrscheinlichkeiten. Die Anweisung scheint auch verzoegerungen auszuloesen

Ne Liste der Effekte die mit SFX angesteuert werden koennen waere nicht schlecht.

Clonen

Das Clonen ist mich auch noch ein Raetzel. Ich hab mal die CPY und CPX Anweisungen fuer nen sprite probiert und gar nix ist passiert. Ich wollte es fuer das Feuerwerk in meinem intro fuer die NY2010 demo verwenden.

CPW ist so schlecht in der Docu beschrieben, das es um so mehr verwirrt. Ich vermute mal, dass CPW immer gebraucht wird, um das geklonte object aauf dem bildschirm zu bewegen. Unklar ist mir ausserdem, wie lange die Klons den erhalten bleiben und wie man sie sonst noch kontrollieren kann.

Cloning Update: Das Clonen habe ich inzwischen hinbekommen und mit sprites erfolgreich durchgefuehrt (das ergebnis werdet ihr in ein paar wochen bewundern koennen). Noch nicht ganz klar ist mir die Logic was zu geklonten effecten unter bestimmten umstaenden passiert und wie genau sich script anweisungen fuer den effect auf die erstellten clones auswirkt. Commands wie ADA, ADX, ADZ usw. wirken sich sofort auf alle Clones aus soweit ich das sehen konnte. Wenn man da irgendwie eine Verzoegerung definieren koennte, dann wuerden mir gleich mehrere neue Verwendungszwecke einfallen. Genom wahrscheinlich gleich noch ein dutzend mehr hehe.

Schade das man nicht mit „CPZ“ objekte auf der Z-Ebene klonen kann. Damit liesse sich zum Beispiel bei 3D Balls (Vektorbobs) ein Object in 2D mit dem eingebauten editor erstellen und mit Clonen zusaetzliche Ebenen um dem Objekt mehr tiefe zu verleihen.

Mask Effects

Effekte fuer die MASK koennen nicht via Script controlliert werden (wie zum Beispiel beim Logo). Die dafuer forgesehenden Commands: SFX und RFX funktionieren nicht mit MASK. Alphawert Aenderungen via ADA-command scheinen auch nicht zu funktionieren.

Mask Effects und deren theoretischen SFX IDs

  • 0 = None
  • 1 = Vertical Slice Bumping
  • 2 = Flashing Skid Boxes
  • 3 = Create Desktop Mask
  • 4 = Scratch TV Crumble
  • 5 = Bordered Viewpoint

Ich wollte spezifisch den Flashing Skid Boxes effect ein und ausschalten. Ich weiss das bei anderen tricks benutzt werden, die das ein und ausschalten wahrscheinlich problematischer machen, obwohl es schon cool waere wenn man den „Create Desktop Mask“ ein und aus „faden“ koennte.. nen harter uebergang ist wahrscheinlich eher seltener wuenschendswert.

Wegen des problems des vorberechnens was es zu einem problem macht den Mask effekt via script zu aendern

Davon hast du doch ein paar mehr oder nicht? von den sachen die vorberechnet werden beim intro start. Da haette ich mal ne grundsaetzliche idee um das problem zu loesen. Man koennte einen neuen Script befehl hinzufuegen der zur deklaration von effekten benutzt wird, die vorberechnet weren muessen. Dieser befehl muesste am anfang des scripts verwendet werden… vielleicht aehnlich dem macro block z.b.

%PRE
MASK=1
MASK=2
EFFECT=SFX
...
%END

damit weisst du dann was vorzuberechnen ist und kannst alles beim intro start vorbereiten. Wenn der user dann im script den effect verwenden will, dann ist er ja schon vorberechnet. Richtig schlau waere natuerlich das zu automatisieren damit der user nix deklarieren muss, dazu muesstest du natuerlich den script code pre-parsen, um zu ermitteln was fuer effekte verwendet werden, um diese vorzuberechnen zu koennen. Beim Mask Effect z.b. wuerde ja im script code irgendwo folgende befehlsfolge auftauchen:

LEA = MASK
SFX = X

siehe suggestions osdm script

Genauere Werte im Script

Floating Point Werte fuer Intro-Time Abfragen, NOP commands und wertanpassungen via AD* commands. Ich dachte dabei eigentlich mehr an eine moeglichkeit die geschwindigkeits stufen fuer effekte zu erhoehen.

Wenn ich z.b. 3 Sprites in unterschiedlicher geschwindingkeit von unten nach oben scrollen lassen will.

Langsamste Variante um einen fluessige ablauf zu gewaehrleisten. In diesem fall wird das sprite 100 pixels nach oben bewegt und zwar auch schon ziemlich zuegig, speziell bei einer hoereren frame rate.

REP = 100
   ADY = -1
LOP

naechst schnellere variante, das sprite legt jetzt schon 200 pixels in der selben zeit zurueck.

REP = 100
   ADY = -2
LOP

und noch schneller und schon 300 pixels bewegt.

REP = 100
   ADY = -3
LOP

Wenn es fuer dieses problem eine bessere oder andere loesung geben sollte, auch gut. Was immer geht und gemacht wird hilft :).

AAx, ARx Commands (Speed)

Originally from ALPHA Version Feedback (April 2010)

Das Rotieren von Vectors via Script scheint auch ganz gut zu funktionieren, was auch klappt, wenn Rotation = off ist im Interface . Wirkt sich die Rotation die via Script geaendert wird auf alle Vector Objekte in einem Multi-Object aus, obwohl ich mit IDN = X ein bestimmtes ausgewaehlt habe oder nicht? Hilfreich waere auch die Stufen fuer die Rotationsgeschwindigkeit via Script zu verkleinern.

Dieser Code z.b. wird in der ALpha viel zu schnell ausgefuehrt das die Rotationsgeschwindigkeitsaenderung um 10 Werte praktisch sofort erfolgt.

REP = 10
ARX = 1
LOP

Ausserdem ist es schwierig die Anweisung in einer Schleife mit den ADX, ADY oder ADX Anweisungen zu verwenden, wo es eigentlich am meisten Sinn macht. Die Bewegungs und Drehungs Bewegungen erscheinen dadurch ziehmlich abgehackt und nicht schoen fluessig. Eine typische Schleife waere z.b.

REP = 200
ADX = 1
ARX = 1
LOP

Meine Empfehlung waere das die Aenderung der Geschwindigkeit um einen Wert im Hintergrund nur eine Aenderung um 1/100 durchfuehrt. Also in meinem Beispiel code drueber wuerde die X-Rotationsgeschwindigkeit nur 2 Schritte groesser sein am Ende der Schleife (im Massstab der Schritte im OSDM Interface).

REFLECTION Effect

Script support ausser dem Starten und Stoppen waere ganz nett. Z.b. das setzen und/oder anpassen der Y-Position mit MVY/ADY (wenn „Below“ angekreuzt ist), aenderung der Alpha Transparenz mit ADA, mit MVZ/ADZ und MVH/ADH koennte z.b. auch noch die groesse und start des zu reflektierenden bereiches aendern (entsprechend ob „Display“ an oder aus ist natuerlich, wenns AN ist, dann sollte natuerlich nur noch die Anpassung der Hoehe gehen und nicht mehr die position).

OSDM Eingabe Interface

VOBJ / OBJ Editor

Ein Editor (egal wie schlecht) zum bearbeiten und erstellen von VOBJ und OBJ dateien fuer 3D Vectors, Bobs und Bobs/Vector Animationen. So ganz per hand wie heute ist einfach mal das schlechteste was geht.

Programm Fenster

Da mittlerweile fast jeder mindestens einen 17“ Monitor hat, sollte vielleicht mal das Programmfenster vergrößert werden und auch eine etwas größerer Font verwendet werden das Fenster sollte mindesten so breit werden das man vernünftig Skripten kann sprich man die Befehle und deren komplette Beschreibung lesen kann ohne Scrollen zu müssen das gleiche wäre auch für die Höhe nicht schlecht ( für die, die nur mit der Regie arbeiten solle alle Regie Effekte angezeigt werden ohne zu Scrollen (wenn möglich).

Neue Option fuer Starfield Simulation

Eine neue Option fuer die „Starfield Simulation“, eine Checkbox mit dem Label „Synchronize with 3D Vector Objects“.

Die X, Y und Z Rotations Optionen, Speed und Angle wuerden dann uebersteuert, wenn der 3DVector Effect activ und diese option angekreuzt ist. Das Starfield dreht sich dann je nachdem wie die Rotationsparameter fuer das 3DVector Object sind. Die Geschwindigkeit natuerlich auch.

Vielleicht machts auch Sinn beim 3DBalls Effect, aber das kann wohl Geschmackssache sein, fuern 3DVector Effect waere es auch jeden Fall cool. Ich benutze die Starfield Simulation sehr haeufig als Hintergrund fuer Vector Objects und versuche haeufig auch die Bewegung der Sterne wenigstens grundsaetzlich der Bewegung der Vectoren anzupassen…nach Augenmass und nach Gefuehl heute leider nur.

Resources Management

Ideen zu dem Problem der beschraenkungen in Sachen daten groesse (wie Bilder usw) Hier sind ein paar generelle Ideen vom Bobo:

„Im „GM“ gibt es Räume, wobei man jeden Raum mit einem Hintergrund belegen kann ( Tile ). Beim OSDM wäre das halt die Demo. Ich hätte einen schönes Code da, damit der OSDM auch mit Tilen arbeiten kann. Da durch würde das Problem von großen Grafiken wegfallen.“

und

„Das Speichersystem der Resourcen in den Demos. Durch das Speichersystem „Platzhalter“ ist man sehr eingeschränkt. Ich hatte ja schonmal den Vorschlag gemacht das ganz in den Resourcen der Demo zu Speichern. Der „GM“ verwendet eine ähnliche Engine, und zwar wird am Ende der Exe eine Art Inhaltsverzeichnis gemacht wo halt die Größen der einzelnen Dateien gespeichert werden. Die Inhalte werden dann auch einfach hinter die Exe gehängt. Ich finde das System sogar einfacher umzusetzen, da der OSDM ja sowieso die Grafiken an bestimmten Stellen in der Exe speichert. Man müsste halt nur ein „Inhaltsverzeichnis“ dranhängen und dann nicht „IN“ der Demo sondern „HINTER“ der Demo speichern. Durch das System wären alle Limits auf einmal aufgehoben. Die Limits sind meiner Meinung nach das größte Problem beim OSDM, da mit mehr Grafiken auch viel aufwendiger Sachen gemacht werden können. Die Leistung sollte hier nicht das Problem sein, da PB sehr viele Sprites auf einmal darstellen kann.“

Zu Bildern hat er ausserdem noch folgende Ideen

„Import von Grafiken. Hier möchte der OSDM gerne vorbearbeitet Grafiken. Der „GM“ arbeitet bei dem Verarbeiten der Grafiken genau wie der OSDM, aber durch die Import-Funktionen der Grafiken werden die z.B. Gifs automatisch in Frames umgerechnet. Damit würde das „Gif-Problem“ erstmal aus der Welt geschaft.“

3D Engine

Ideen vom Bobo

„3D Funktionen. Der OSDM soll ja kein Aufwendiges 3D-System haben, wird ja auch nicht gebraucht…. Aber…. Der OSDM nutzt die S3DR Lib und Damit ist es möglich mal „auf die schnelle“ 3D Objekte zu erzeugen oder nen Sprite als Textur zu nutzen. Hier sollte man vieleicht versuchen die S3DR Zeichenbefehle einfach im Script zu übernehmen oder besser durch zuschleifen. Damit könnten Effekte wie „Weltkugel“ oder ähnlich selber per Script programmiert werden und der OSDM müsste für solche kleinen „Spielerein“ nicht Erweitert oder Umgebaut werden.“

IMPLEMENTED IN OSDM / DONE

DONE! Implemented in OSDM!


Here are the suggestions that were implemented by newer versions of Oldskool Demomaker. They are kept for historic purposes and to illustrate that somebody actually listens to what users are suggesting and changes to OSDM are being made consequently. So if you have an idea, suggestion or comment to missing or already existing features of OSDM, don't hold back with it :).

Scripting

Logo Zoom

Es waere nuetzlich die Moeglichkeit zu haben das Logos zu vergroessern oder verkleinern, selbst wenn auch nur via OSDM Script und/oder auch nur wenn kein Effekt auf das Logo angewendet wird (= None im OSDM Interface, oder mit SFX = 0 im OSDM Script abgestellt). Die verhandenen Commands ADZ und MVZ sollten hierfuer verwendet werden, in der gleichen weise wie das schon fuer Sprites geschieht.

Effekt Layer Steuerung

Was meine ich damit?

Die einzelnen Effekte sind ja wie auf Folien (Layern) Angeordnet und deren Reihenfolge wird in der Regie bestimmt. Was mir vor schwebt ist das man in einer Demo diese Reihen Reihenfolge per Skript Festlegen und ändern kann. Und Zwar so ähnlich wie es jetzt schon mit der Regie gemacht wird. Dazu müsste man den Einzelnen Layern (ebenen) eine Eindeutige ID geben. Damit man dann einen bestimmten Effekt sagen kann Du bist jetzt auf Layer z.B. 5. Und wenn man dann per Skript den die Layer ID ändert müssten sich der Effekt der vorher auf Layer 5 war ein nach oben rücken also auf 6 bei allen anderen Layern dann das gleiche Spiel also genau so wie es jetzt auch ist wenn man in der Regie Layer eines Effekts ändert.

Warum das ganze?

Damit könnte man einen Zusätzliche Tiefenwirkung erzielen. Ein Beispiel man ein Hintergrundbild mit einer Wiese und einer Mauer die von Rechts nach links durch das gesamte Bild läuft ungefähr in der des Bildes nach oben ist alles Schwarz. Jetzt könnte man z.B. ein Sprite oder ein Vektor von unten hoch kommen lassen über die Mauer hin weg Zoom das Sprite oder Vektor etwas in den Vordergrund und last dann das Sprite oder Vektor Den Layer wechseln so das es vor dem Hintergrundbild ist und last da dann z.B. weiter auf und ab hüpfen. Dann entsteht der Eindruck das das Sprite oder Vektor Objekt aus dem Hintergrund über die Mauer gehüpft ist. Es gibt noch unzählige andere Beispiele wo das wechseln des Effekt Layers sinnvoll wäre weil dadurch ein neuer Visueller Effekt entsteht.

Habe mir zwar noch keine Gedanken darüber gemacht wie man diesen Skript Befehl Sinnvoll Nennen könnte aber da fällt euch bestimmt was ein. Vielleicht ( “ FXL “ für FX = Effekt Layer oder nur “ LAY “ für Layer und dann halt einen Zahl ) Wo bei ich dann vorschlagen würde das „0“ der aller Oberste Layer sein sollte der der alle anderen überlagert und immer zu sehen ist.

3D Vector Control via Script

Es gibt zwar im OSDM Script commands wie OSX, OSY und OSZ um den betrachter im raum zu den objekten zu positionieren, aber die sind wie MVX, MVY und MYZ nur zum einmal fix festlegen gedacht und erlauben keine „kamerafahrten“. Mit ADX, ADY und ADZ kann man schon praktisch zwei-dimmensionale (plus zoom) vorbeifahrten machen, aber das ist doch ehrlich gesagt ziehmlich einschraenkend und nur bedingt cool anzuschauen.

OSDM Script

Neue Kommandos zum Setzen, Pruefen und Aendern der Rotation, Bewegung und Winkels fuer 3D Vectors und 3D Balls.

3D Vector & 3D Ball

  • X, Y, Z Rotate
  • X, Y, Z Move

3D Ball

  • X, Y, Z Angles

3D Vector

  • X, Y, Z Angles

= 27 Neue Kommandos

Namens-Vorschlag fuer die neuen Kommandos: siehe suggestions osdm script

Spiegel/Mirror oder Flip Feature

Ein nettes zusaetzliches Feature fuer Sprites waere die Moeglichkeit es zu Spiegeln(auf der x, y-Ache oder z-Achse). Wahrscheinlich waere es aber nur sinnvoll es zu einer SCRIPT ONLY Funktionalitaet wie das KLONEN zu machen, weil es dort eigentlich nur richtig zur Anwendung kommen kann. Der Gedanke ist das man z.b. bei einer animierten Sprite wo irgend etwas z.b. von Links nach Rechts ueber den Bildschirm „laeuft“, man es via Script Command „umdrehen“ kann, damit es in der entgegen gesetzten Richtung wieder ueber den Bildschirm „zurueck laufen“ kann.

EXT/QUT Command

Ein script command zum beenden des intros waere huebsch. Das macht nicht nur bei bestimmten typen von intros Sinn, sondern auch besonders bei der Erstellung von „Megatros“, um automatisch von einem „Part“ zum naechsten zu springen. Es gibt zwar schon eine Moeglichkeit ein intro automatisch zu beenden (wie ^Q1 innerhalb eines Scrollers), aber diese Methode ist doch ein wenig umstaendlich und bereitet andere Probleme (wenn man Scrollers auch fuer was anderes benutzen moechte z.B.).

siehe suggestions osdm script

Music Volume

Es waere sehr hilfreich, wenn man via script die lautstaerke der musik ein und aus-faden koennte. Besonders wenn man von einem zum anderen tune in der demo switchen will wenn man seine effekte mit der musik synchronisiert. Das aus und ein-faden wuerde uebergaenge weicher machen als das einfache an und ausknipsen der jeweiligen tunes.

siehe suggestions osdm script

Alpha-Transparenz Check

Script Feature. Ich vermisste die Anweisung „IFA“, um den Alpha-Transparenzwert eines Effektes zu checken. Ich habe schon mehrfach aus Versehen Alpha-Trans werte < 0 und > 255 gesetzt (durch ADA Anweisungen), was dann ungewollte Auswirkungen. Das Ding alleine hat mich 2+ Stunden gekostet bevor ich den Fehler im Script gefunden hatte.

siehe suggestions osdm script

Text Effects

ZiniText

0 - ZERO - NADA - NO - NITSCHWO Effekte werden aus unerklaerlichen Gruenden fuer den „ZINITEXT“ im OSDM Script unterstuertzt. Ich vermute das es hier um „vergessen“ und nicht um „ging nicht“ handelt

Amiga Text

Endferne Doch Bitte Gleich Auch Dieses Lässtige 20 Zeichen Limit Pro Amigatextzeile. Dieses Limit Ist Doch Quatsch Wenn Man Genug Platz Hat Fuer Mehr (Speziell Bei Kleineren Font Groessen). Wenn Heute Schon Die 20 Zeichen Nicht Mehr Passen, Dann Geht Der Text Ja Heute Schon Ueber Den Rand Hinaus Ohne Das Osdm Abkackt. Klar, Text Wird Natuerlich Abgeschnitten, Aber Wir Sind Ja Nicht Blind, Oder ?!

Eine ansprechen der AmigaText Seiten per ID im Skript wäre auch nicht schlecht. Dann könnte man bei einen bestimmten Effekt eine bestimmte AmigaText Seite einblenden lassen wenn man dann noch die Effekte vom AmigaText steuern könnte wäre es noch besser!

Interface

Parameter Eingabe

Es sollte überall wo Eingaben erforderlich sind die auch per Tastatur machen können (z.B. für die Rotation bei den Vektors). Und nicht nur über die kleinen Peiltasten rechts daneben.

Sprite Order

Es waere hilfreich, wenn man die Reihenfolge der Sprites noch oben und unten verschieben kann (mir all den Einstellungen des Sprites, so wie beim Storyboard die Effekte). Der Hintergrund dafuer ist wie sprites angezeigt werden. Ein Sprite in einem hoeheren „Slot“ wird ueber Sprites mit niedrigeren „Slot“ Positionen angezeigt. Wenn das fuer eine Scene wichtig ist und man die ganzen Einstellungen schon gemacht hat, dann ist es immer nervig und Muehsam die Sprites manuell umzusortieren, besonders durch das Limit der Sprites im generellen (sie Suggestion drueber).

Fehlermeldungen

Wenn eine datei fehlt oder zu gross ist und man das intro laufen lassen will oder kompilieren, dann popped OSDM ne Fehlermeldung raus die man bestaetigen muss. OSDM macht dann aber trotzdem weiter. Die wahl zwischen „Ok“ und „Cancel“/„Abort“ waere nicht schlecht, weil man ja meistens das problem erst einmal beheben will bevor man die demo ausfuehrt oder kompiliert.

Aja.. wenn er meckert das was zu gross ist, dann zeigt er an, wie gross die gewaehlte datei ist, aber nicht welche groesse es nicht ueberschreiten darf. Der waere in der selben meldung auch ganz hilfreich. Eigentlich sogar noch wichtiger als die info wie gross meine ausgewaehlte datei ist, weil das weiss ich ja normalerweise auch schon selber.

Extras

 
 suggestions.txt · Zuletzt geändert: 2013/04/05 08:33 (Externe Bearbeitung)
 
Falls nicht anders bezeichnet ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Driven by DokuWiki