In OpenGL geht das standard Koordinatensystem von -1 bis 1 auf allen Achsen. Der Punkt (0, 0, 0) ist die Mitte des Fensters. Außerdem habe ich vorher falsche Informationen gegeben. Die Z-Koordinaten für die Dreiecke generiere ich über random.nextFloat() was in Java einen Wert aus dem Intervall [0.0, 1.0) zurück gibt.
Status: Beginn der Arbeiten an der neuen Engine
-
-
Zitat
In OpenGL geht das standard Koordinatensystem von -1 bis 1 auf allen Achsen. Der Punkt (0, 0, 0) ist die Mitte des Fensters. Außerdem habe ich vorher falsche Informationen gegeben. Die Z-Koordinaten für die Dreiecke generiere ich über random.nextFloat() was in Java einen Wert aus dem Intervall [0.0, 1.0) zurück gibt.Hm, was für einen Sinn die negative z-Achse hat sei jetzt mal dahingestellt, ich frag mich auch warum man das bei DirectX überhaupt anpassen kann. Glaube es hatte was damit zu tun wenn du in unterschiedlichen Sortierungen und Pässen nah und weit entfernte Objekte getrennt renderest um Z-Artefakte zu vermeiden, in 3D-Spielen halt...
Übrigens, wo wir schon beim Thema sind, hast du eine gute Lösung dafür gefunden wann und wie du den Vertex-Buffer für die Sprites vergrößerst? Ich meine, bei so einer Test-App ist es ja ganz leicht,a ber bei einer dynamischen Szene wo diesen Frame noch 250 Sprites da sind, und 10 Schritte weiter geht am schön gemappten Markplatz die Post ab und es sind auf einmal 1000 da... derweil hab ich einfach den Buffer so groß wie nur entfernt nötig angelegt, möchte da aber trotzdem Ressourcen sparen. Wie hast du das gelöst?
-
Der Buffer bei mir wächst dynamisch mit dem Bedarf.
Ich kann eine Anfangsgröße und ein Vergrößerungsverhalten definieren. Es gibt aber auch Standardwerte dafür falls man nichts definiert. Im Moment lasse ich den Buffer jeweils auf die doppelte Menge wachsen und neuen Platz auf der Grafikkarte anfordern.
Das ist kein Problem, da es in OpenGL sogar empfohlen wird komplett neuen Platz anzufordern anstatt die alten Werte zu überschreiben, da somit die Grafikkarte noch mit den alten Werten zuende arbeiten kann und man selbst gleichzeitig neue Daten einspeist. Orphaning nennt man dieses Prozedere. Allerdings verwende ich es im Moment nur um neuen Platz zu allokieren, nicht um die eigentlichen Daten periodisch zu übertragen.Außerdem blickt man in OpenGL normalerweise (im 3D Bereich) die negative Z-Achse herab.
-
Zitat
Das ist kein Problem, da es in OpenGL sogar empfohlen wird komplett neuen Platz anzufordern anstatt die alten Werte zu überschreiben, da somit die Grafikkarte noch mit den alten Werten zuende arbeiten kann und man selbst gleichzeitig neue Daten einspeist. Orphaning nennt man dieses Prozedere. Allerdings verwende ich es im Moment nur um neuen Platz zu allokieren, nicht um die eigentlichen Daten periodisch zu übertragen.
Also in DX wird das absolut nicht empfohlen, dafür ist die D3DUSAGE_DYNAMIC flag da, wenn man jedes Frame neue Buffer anlegt bekommt man enorme Performance-Probleme, wieder ein gravierender Unterschied. Das Problem was ich dabei habe ist der Zeitpunkt des Vergrößerns des Buffers. Ich weiß zu beginn des Frames und auch des Draw-Vorgangs nicht, wieviele Sprites es werden, da der Sprite-Renderer in mehreren Plätzen verwendet wird. Ich könnte also irgendwann während dem ausführen eines Sprite-Befehls draufkommen "oh shit, der buffer ist zu klein". Mir fällt da keine gute Lösung dazu gerade ein, ehrlich gesagt - ich könnte das Rendern von allen Sprites die über den Buffer gehen in diesem Frame blockieren, das könnte aber zu grafischen Artefakten führen... hast du vielleicht eine bessere Idee für mich?
-
Mein erster Rat bei soetwas ist immer einmal im Internet danach zu suchen. Du bist sicher nicht der erste, welcher solch ein Problem hat. Es gibt auch sicher ein Support-Forum für DirectX fragen. Ich habe sehr viele Fragen in diversen OpenGL Support-Foren gestellt bis ich zu meinem derzeitigen Engine-Stand kam.
-
Zitat
Mein erster Rat bei soetwas ist immer einmal im Internet danach zu suchen. Du bist sicher nicht der erste, welcher solch ein Problem hat. Es gibt auch sicher ein Support-Forum für DirectX fragen. Ich habe sehr viele Fragen in diversen OpenGL Support-Foren gestellt bis ich zu meinem derzeitigen Engine-Stand kam.Ja, das mach ich normal sowieso falls mir selber keine Lösung einfällt, bin eh recht aktiv im Gamedev.net-Forum, da kommen fast immer gute Antworten. Wollt halt zuerst schauen ob du nicht, da wir schon beim Thema waren, nen Input hast.
-
Mit DirectX kenne ich mich überhaupt nicht aus. Wie du gesagt hast, hier scheint es sich um ziemliche Unterschiede zu halten. In OpenGL ist es überhaupt kein Problem einfach neuen Speicherplatz zu beantragen.
In dem hochgeladenen Testprogramm, zum Beispiel, beginne ich mit Platz für nur 200 Dreiecke und arbeite mich langsam vorwärts indem der Speicherplatz verdoppelt wird. Auf 1 000 000 sind das eine ganze Menge Neu-allokationen. -
Zitat
In OpenGL ist es überhaupt kein Problem einfach neuen Speicherplatz zu beantragen.
Bleibt dabei der Inhalt des neuen Buffers erhalten? Es ist auch nicht wirklich ein Problem in DX neuen Speicherplatz zu reservieren, nur muss ich dazu einen neuen Buffer anlegen, mit der neuen Größe. Und die Daten des alten Buffers kann ich nicht direkt in den Neuen übetragen, d.h. ich müsste diesen Frame mit mehreren Buffern rendern, oder nochmal alle Sprite-Befehle durchgeben. Naja, ich schau mal was die Leute auf Gamedev zu sagen haben.
-
OpenGL übernimmt nicht direkt die alten Werte aus dem Buffer. Du kannst natürlich die alten Werte mit einem entsprechenden Befehl selbst lesen und dann in den neuen hineinschreiben.
Ich habe aber jederzeit einen Buffer auf Anwendungsseite, welcher ebenfalls alle Daten nocheinmal speichert. -
Zitat
Du kannst natürlich die alten Werte mit einem entsprechenden Befehl selbst lesen und dann in den neuen hineinschreiben.
Ich habe aber jederzeit einen Buffer auf Anwendungsseite, welcher ebenfalls alle Daten nocheinmal speichert.Das geht in DX nur wenn du den Buffer vorher mit einem enstprechenden Flag markierst, was ihn potentiell langsamermacht (weil sonst garantiert ist dass der Buffer nie von Anwendungsseite benötigt wird und deshalb optimiert verarbeitet werden kann). In DX11 kannst du außerdem nicht gleichzeitig von einem Buffer auf CPU-Seite lesen und schreiben. Aber die Idee mit dem zusatz-Buffer auf Software-Seite klingt ganz interessant, das würde das Problem weitestgehend lösen. Sowas hab ich gemeint, das ist API unabhängig, werd ich mal ausprobieren, danke.
-
Den Buffer auf Softwareseite benötige ich sowieso um die Daten zu übertragen. Anstatt den Buffer jedesmal neu zu erstellen wenn er benötigt wird halte ich einfach jederzeit einen Buffer bereit. Dieser Buffer kann dann natürlich auch noch für andere positive Effekte eingesetzt werden.
In OpenGL kann man die Buffer ebenfalls markieren, dass man sie nicht lesen will, oder, dass sie nichtmehr verändert werden. Allerdings bedeutet das nicht, dass es auch wirklich so ist. Immerhin sind die Regeln von OpenGL nur Empfehlungen. Jeder Hardwarehersteller kann sich entscheiden sie umzusetzen oder nicht. Ganz allgemein wird oft gesagt, dass man diesen Flags nicht ganz trauen sollte in OpenGL. Aber natürlich kann es nicht schaden sie trotzdem zu verwenden.
-
Ich habe auch einen kleinen Feature-Test erstellt. Vielen möchtest du es dir einmal ansehen.
Das interessanteste dabei wären wohl die Unterschiede zwischen den Texturfiltern. Mit der Taste T kann man im Programm die verwendete Textur umstellen. Die erste Textur benutzt einen linearen Texturfilter und 100 Mipmap Stufen, während die zweite Textur einen Nächster-Nachbar-Filter verwendet und keine Mipmaps benutzt.Man kann das angezeigte Bild außerdem frei drehen, skalieren, bewegen, die Farbe beeinträchtigen und den Shader zu einem Schwarz-Weiß-Shader wechseln.
Hier der Downloadlink: http://www.file-upload.net/download-81466…ndows-.zip.html -
Zitat
Das interessanteste dabei wären wohl die Unterschiede zwischen den Texturfiltern. Mit der Taste T kann man im Programm die verwendete Textur umstellen. Die erste Textur benutzt einen linearen Texturfilter und 100 Mipmap Stufen, während die zweite Textur einen Nächster-Nachbar-Filter verwendet und keine Mipmaps benutzt.
100 Mipmapstufen?? Da normal jede Mipmap um die Hälfte kleiner ist als die Vorversion, meinst du wohl eher 8? Oder ist das eine GL einstellung?
-
Jede Mipmap wird um die Hälfte kleiner, 100 sind zwar nicht nötig wie du sagst, ich habe aber dennoch für den Test 100 Mipmap Stufen eingestellt. Es geht maximal in die Tausender, weitere Stufen kosten nichts mehr ab einem gewissen Punkt. Und bei einem einzigen Bild auf dem Bildschirm kümmert es sowieso recht wenig.
-
Zitat
Jede Mipmap wird um die Hälfte kleiner, 100 sind zwar nicht nötig wie du sagst, ich habe aber dennoch für den Test 100 Mipmap Stufen eingestellt. Es geht maximal in die Tausender, weitere Stufen kosten nichts mehr ab einem gewissen Punkt. Und bei einem einzigen Bild auf dem Bildschirm kümmert es sowieso recht wenig.Eingestellt = 100 Stufen für das Bild erstellt, oder bloß die Kapazität für die API so eingestellt? Zumindestens im 3D-Bereich kosten Mipmaps so gut wie gar nichts, nichtmal Speicherplatz, sofern man das DDS-Format verwendet (DDS mit mipmaps ist immer noch ca. 50% kleiner als eine png-Datei, und wird auch schneller verarbeitet). Im Gegenteil, Mipmaps beschleunigen das Rendern sogar, wegen optimalerem Sampling. Im 2D-Bereich sind Mipmaps sowieso großteils überflüssig, es sei denn du stellst öfters exterm verkleinere Sprites dar.
-
Die Mipmaps sind nicht wirklich nötig für 2D, da hast du recht, ich verwende sie auch nur in diesem kleinen Test. Einfach nur um die Engine zu testen.
Ob deine Grafikkarte wirklich 100 Mipmap Stufen erstellen wird liegt nicht in meiner Hand. Die Dokumentation sagt aus, dass es nicht nötig ist Mipmaps mit einer Größe von weniger als 2x2 Pixel zu erstellen. -
Ein kleines Update des aktuellen Standes,
in letzter Zeit habe ich zwar weniger aktiv der portierung von Terranigma auf meine Engine gearbeitet, die Engine selber hat aber einige Verbesserungen und Erweiterungen erhalten, gerade was Performance und GUI anbelangt. Außerdem habe ich begonnen den Editor umzusetzen. Auf dem anhängten Screenshot sieht man zwar die Verwendung für eine 3D-Applikation, aber im Prinzip bleibt das Layout gleich. Da wo jetzt der Turm ist, wäre beim 2D-Equivalent die Map zu sehen. Da das ganze Plugin-gestützt ist, muss ich erstmal entsprechenden Support für den Editor ins 2D-Plugin einbauen. Dazu würde dann eben noch das Fenster für die Tiles kommen. Die "Entity"-Ansicht auf der rechten Seite bleibt gleich, und auch der Entity-Erzeugungsdialog wäre vom Prinzip derselbe, nur gäbe es dann halt andere Komponenten auszuwählen (Position mit zwei Komponenten, Sprite, Animation, ...). Dabei ist es möglich, nur die Komponenten zu wählen die man für diese Art von Entity braucht. Beim Rpg-Maker hatte jedes Event alles - Grafik, Animation, Bewegung, Eventcode - hier kann ich einfach weglassen, was ich zur Performanceoptimierung im Maker mit einem Script mühsam per Hand entfernen musste. Was man hier nicht sieht, wird es auch die Möglichkeit geben, sich Templates, also Vorlagen für bestimmte Arten von Entities anzulegen - zB. Teleporter, Türen, Gegner, etc... damit wird mir auch eine Menge Arbeit abgenommen.
Im "Entity-Explorer" auf der rechten Seite ist es auch möglich, sich alle Entities der Map anzusehen und zu bearbeiten, ein Feature dass ich beim Maker auch hin und wieder vermisst habe. Man kann dort einzelne Komponenten löschen und hinzufügen, und später eventuell auch die Entities gruppieren, ähnlich einer Ordnerstruktur im Windows Explorer. Im Attribut-Fenster darunter kann man die Eigenschaften der Komponenten bearbeiten, das ist im Moment noch nicht implementiert, weil ich dafür auch erstmal eine Schnittstelle für die Plugins brauche. Ebenfalls bereits vorhanden ist das Asset-System zum Verwalten von Texturen, Materialien, Meshes, etc... das man zwar für die meisten 2D-Anwendungen eher weniger brauchen wird, aber da das Asset-System zentral und unabhängig vom Typ des Spiels ist, war es mir wichtig dass dieses erstmal implementiert ist (siehe Screenshot 2)
Im Moment bin ich gerade noch am Einbauen von letzten wichtigen "Widgets" - Contextmenüs, Tabs, Window-Docking-Areas, etc... und am verfeinern der API für den Editor, mit dem die Plugin-Anbindung passiert. Sobald dies geschehen ist, werde ich die Terrangima-Nahen Plugins entsprechend aufrüsten, und anfangen die Anfangsequenz in Krysta nachzubauen.
-
So, ein neues Update, die letzten Wochen habe ich weiterhin vor allem damit verbracht Kleinigkeiten bis hin zu größeren Sachen am Gui/Editor, und die Editor-Anbindung der Plugins anhand meiner 3D-Plugins getestet. Nun hab ich aber auch beim 2D-Bereich etwas nachgezogen, und die bisher vorhandenen Systeme die für Terranigma 2 verwendet werden soweit vorhanden in den Editor integriert. Außerdem ist es dem Editor jetzt möglich, tatsächlich Projekfiles zu laden/speichern, inklusive der ewaigen Plugins, damit ist es nun möglich für mich angenehm mit multiplen Projekten zu arbeiten, und ich kann theoretisch tatsächlich anfangen den Content aus dem RPG-Maker zu porten. Aber erstmal bisschen was fürs Auge:
Screenshot 1 (EditorEntities) zeigt, wie ungefähr das Editor-Interface aussehen wird. Wie im 3D ist auf der linken Seite die Spiele-Ansicht, worüber man auch die Map editieren wird. Oh, die Maps/Tilemap hab ich noch nicht integriert, deswegen sieht das ganze noch etwas unspektakulär schwarz aus. Was man hier auch noch nicht erkennt, ist dass es dem Editor problemlos möglich ist, Animationen direkt abzuspielen, wie bei Ark hier, oder dem Kristallnebel. Tatsächlich dürfte sich sogar mit einigen Modifikationen auch ein direkter Playtest ohne Start des Programms realisieren lassen, mit interaktiver bearbeitung/pausierung/forsetzung (ein Traum), aber da müsste ich doch erstmal auf Scripting umsteigen (bin ich ehrlich gesagt noch nicht bereit dazu, da will ich erstmal paar andere Sachen noch polieren), oder den ganzen Game-Code ebenfalls als Plugin schreiben. Wird sich noch im Laufe der Zeit zeigen.
Auf der rechten Seite sehen auch die 3D weniger Interessierten jetzt, worum es beim Entity-Component-System geht. Unten rechts ist das jetzt befüllte Entity-Attribute-Fenster. Statt diesem Pop-Up-Dingens vom Maker werden die Entities in diesem Fall über ein klassisches Eigenschaften-Fenster bearbeitet. Das erlaubt in der Theorie einen flüssigeren Arbeitsablauf, und leichtere Massen-Verarbeitung von Entities. Dazu ebenfalls nochmal den Entity-Explorer zu betrachten, in dessem gerade aufgeklappten Kontent-Menü man z.B. direkt zu einer Entity springen kann, praktisch gerade bei großen Maps.
Oh, wenn ich gerade davon rede. Ich habe mir einige Neuerungen für die Map-Bearbeitung einfallen lassen, die Ideen sind mir beim 3D-Editor gekommen. Statt ständig über die rechte/untere Bildlaufleiste scrollen zu müssen, wird man bei mir durch drücken von zB. ALT + Mausbewegung die Karte verschieben können. Hab ich soweit auch implementiert, und auch wenn noch der Tilemap-Editor fehlt, fühlt sich das ganze schonmal gut an, und sollte auch den Arbeitsablauf flüssiger machen.Screenshot 2 (EditorAttach) zeigt das grundlegende Interface zum Erstellen einer Entity. Mag am anfang etwas verwirrend sein, es fehlen auch noch ne Menge beschriftungen, und werd es eventuell noch Umstrukturieren. Aber vom Prinzip lassen sich so ganz einfach verschiedenste Arten von NPCs über Map Fog etc... erstellen. Wie erwähnt wird es aber trotzdem auch die Möglichkeit geben, Templates zu erstellen, damit ich ständig wiederkehrende Elemente wie z.B. NPC, Türen, Truhen, etc... instant erstellen kann. Auch muss man im Vergleich zum Maker nicht extra auf dem "Event-Layer" sein, dieser Dialog kann immer aufgerufen werden. Auch wird man Entities weiterhin durch Rechtsklick auf die Map anlegen können, ob auch auf Druck von Enter, ist noch ungewiss - denn ich habe bis jetzt keine 32x32-Grid, wird eventuell zuschaltbar sein, muss aber schauen wie sich das dann im Endeffekt zusammenspielt.
Screenshot 3 (EditorTextures) zeigt nochmal im Detail des Grafik-Auswahl-Interface. Es fehlt noch immer die Suchleiste, mit der sich extrem schnell bestimmte Grafiken finden lassen. Jedoch schon zu sehen, dass Texturen nicht per Datei referenziert werden, sondern mit dem Namen. Infos wie Dateiname, Größe, Format etc.. wird unten angezeigt. Drag&Drop fehlt mir noch (also dass man Grafiken aus dem Explorer in das Fenster reinziehen kann), dafür sieht man bereits jetzt, dass der Editor anpassbar ist (siehe der Bildschirm-füllende Entity-Explorer hier). Das ist mir besonders wichtig, beim Rpg-Maker hätte ich mir schon teilweise gewünscht das Tileset auszublenden/verschieben zu können, etc...
Nun, soweit erstmal dazu, werd vmtl neue Screenshots posten wenn ich das Map-System für den Editor hab, weils einfach schön aussieht, und dann sieht man weiter
EDIT: So, hier wie versprochen. Sieht doch ganz nett schon aus, jetzt brauch ich nur noch die Editierfunktionen für die Maps (wobei das ja sogar weniger Priorität hat, da ich zuerst eh die Maps aus dem Rpg-Maker 1:1 übernehmen kann). Jedenfalls brauch nicht noch was um die Maps gut zu speichern, zu kategorisieren etc... , das hier ist grad nur n schneller hack der lediglich eine ganz spezielle Map laden kann.
-
Update,
entgegen meiner ursprünglichen Einstellung hab ich mich doch dazu entschieden, direkt Scripting zu implementieren. Dazu verwende ich Angelscript, eine an C++ angelegt, streng typisierte und an sich ziemlich schnelle Sprache. Entgegen dem RPG-Maker werde ich das Scripting hauptsächlich zum definieren von Gameplay-Elementen benutzen, technische Sachen wie die Darstellung der Maps etc.. wird weiterhin über Plugins erfolgen. Die Scripte werden daher meist in Form einer Script-Componente an bestimmte Entities angehängt. In weiterer Folge werde ich aber auch ein Event-System einbauen, dass hier aber nur diesem Zweck dient, nämlich Ereignisse im Spiel mit einer GUI scripten zu können. Die Events und das Gui werden definitiv über Scripte erweiterbar sein, wie genau ich das ganze aber Integrieren werde, ist noch unklar. Scripte können direkt im Editor kompiliert werden, und spucken in diesem Fall entsprechende Fehlermeldungen aus, und die Scripte können auch direkt im Editor laufen gelassen werden. Weiters wird es auch für mich möglich sein, sowohl im Spiel als auch im Editor, direkt Scriptbefehle auszuführen, um einmalige Tasks auszuführen, z.B. das Ändern aller Gegner auf der Map
Und lauter solche Sachen.
In der nächsten Zeit ist deshalb meine Hauptaufgabe vor allem sich die genaue Scriptstruktur zu überlegen, wie das ganze mit der Applikation zusammenspielt, und die wichtigen Klassen von der Applikation mit AngelScript zu registrieren. Ich hatte ja vorher Lua probiert, bloß musste da für jede einzelne Funktion ein Wrapper geschrieben werden, und hier kann ich immerhin fast alle funktionen direkt anbinden.
Im Anhang noch eine Übersicht über so ein Script, noch in der 3D-Umgebung (die nutz ich immer erst zum Features testen), ohne Syntax-Highlighting, und ingame sind die Scripte auch noch nicht editierbar, da muss ich erstmal die Multizeilen-Textbox fertig stellen...
-
Soo,
nach langer Zeit gibts mal wieder ein neues Update. Obwohl ich in den letzten Monaten wenig direkt an Terranigma gearbeitet habe, gingen die Arbeiten an der Engine weiter. Obwohl vieles davon vor allem den 3D-Sektor betroffen hat, haben auch viele Änderungen Einfluss auf Terranigma. Mir fällt jetzt auf die Schnelle gar nicht mehr alles ein, aber wurden eingebaut:
- OpenGL4-Support, als zusätzliche API neben DirectX9 und DirectX11. Damit steht auch zukünftig einer portierung auf Linux etc... nicht mehr viel im Weg.
- EIn Scenensystem, ist etwas generischer als die "Maps" vom Rpg-Maker. Tilemaps etc.. werden per Extention geladen. Damit kann ich schonmal die ganzen "Maps" praktisch laden & verwalten.
- Geometry-Shader für die Sprite-Darstellung (in DirectX11 oder OpenGL4), sorgt im Prinzip auf aktueller Hardware für eine kleine Beschleunigung bei der Sprite-Darstellung, kommt an sich eh fast nur bei mir im Editor zur Geltung, wenn die gesamte Map angezeigt wird.
- Settings: Im Prinzip generalisierte Variente von den Settings die ich im Rpg-Maker eingebaut hatte, diesesmal kann ich dann auch weitere Einstellungen leichter einbauen, wie z.B. Audiolautstärke.
Teil von meiner fehlenden Motivation war vielleicht, dass ich nicht den richtigen Einstiegspunkt vor Augen hatte, und von der Gesamtheit der verbleibenden Arbeit etwas erschlagen wurde. Deshalb habe ich es mir jetzt vorerst als Ziel gesetzt, den gesamten Prolog inkl. Intro zu portieren. D.h. noch kein Kampfsystem etc... , das kommt dann sobald ich soweit bin. Im Moment Arbeite ich deshalb an:
- Lokalisierung: Ich möchte gleich mit so wenig Aufwand wie möglich mehrere Sprachen unterstützen, deswegen habe ich mir (so gut wie fertig) ein System geschrieben mit dem ich Strings in mehreren Sprachen per XML-File laden kann, und dann einfach die gewünschte Sprache umschalten kann. Bedeutet, die Texte liegen auch nicht ganz im "Reintext" vor, aber immerhin in Form eines Textfiles, und nicht versteckt im RPG-Maker.
- Visual-Scripting: Cutszenes, Gespräche und dergleichen sind kein guter Einsatz von regulärem Scripting. Mir kommt aber das reguläre Event-System vom Rpg-Maker etwas zu rigide, unübersichtlich und veraltet vor, deswegen habe ich mich dazu entschieden eine sogenanntes "Visual Scripting"-System einzubauen. Wie funktioniert soetwas? Für Bilder einfach mal google fragen (hab selber noch nichts grafisches), aber von der Funktionsweise ist es so wie das Event-System vom Maker, bloß werden die einzelnen "Commands" unabhängig voneinander angelegt. Über Inputs & Outputs lassen sie sich dann verknüpfen, alles über eine grafische Benutzeroberfläche. Dient vor allem der besseren Benutzbarkeit, auch wenn die Möglichkeiten im Endeffekt doch größer sein sollten. Bester Punkt: Lässt sich mit neuen Commands dynamisch erweitern, per Plugin oder Script, d.h. ich kann einfach schnell einen "Climb"-Command erstellen, und hab dann eine generische Möglichkeit das Klettern zu verwalten, ohne bei jeder Änderung einen "Call Script" bearbeiten zu müssen. Daraus bestand nämlich im Endeffekt beim Maker die meiste Arbeit, weil so gut wie jedes Event irgendeinen CallEvent-Code hatte. Auch meine Events lassen sich wieder durch Scripts spezialisieren, dafür wird jedoch immer eine Klasse verwendet, von der bestimmte Methoden aufgerufen werden. Damit bleibt es auch wieder generalisierbar, und es passiert nicht dass irgendwo im Event selber ein Code steht den ich jedesmal kopieren muss.
Auf der direkten Game-Seite baue ich gerade die Textbox und das Anzeigen/Animieren von Bildern ein, um damit erstmal das Intro nachzubauen. SPC-unterstützung folgt dann auch noch, damit ich weiterhin die 64kb-Musikfiles mit Top-Qualität und Looping-Einstellungen nutzen kann (würde ne eigene Lib/DLL dafür bevorzugen, zur Not wieder über WINAMP). Dabei sollten dann die Fade-Out-Einstellungen auch besser passen, das war ja noch ein Kritikpunkt bis jetzt, und ist mir beim Testen letztens auch sehr negativ aufgefallen.
Also, alles in allem geht es weiter, ich poste Screenshots/Ergebnisse wenn sie vorliegen. Bis dahin werde ich aber vor allem noch den Editor auf die ganzen Features ausbauen müssen, denn ohne Editor ist das ganze relativ unangenehm zu machen (XML-files handbearbeiten ist für ein so großes Projekt nicht gut geeignet).
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!