spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Guten Mittag,

ich stelle mal mein erstes Open Source Projekt vor.

https://github.com/shanegrueling/Ether

Ether löst ein paar Probleme die ich beim Programmieren mit JavaScript hatte. Zum Anfang wären da Includes. Native verfügt JavaScript über keine Lösung dafür und bestehende Bibliotheken hatten immer schwere Nachteile. Manche bestanden auf bestimmte Formate der Dateien, das Pflegen von Listen was wo inkludiert werden soll, erlaubten nur dynamisches inkludieren, was während dem entwickeln cool ist, aber beim veröffentlichen Performance einbußen bringt andere wiederum mussten IMMER mit einem extra Tool durchlaufen werden, bevor man sie testen konnte.

Kurz es gab nur Probleme und noch mehr als ich aufgeführt habe. Ether macht das anders. Wenn man Ether eingebunden hat wie beschrieben, steht unter Ether.include einige Funktionen bereit um Dateien einzubinden. Am wichtigsten ist Ether.include.JavaScript(). Damit kann man andere JavaScript Dateien einbinden. Diese werden dann dynamisch nachgeladen. Das ist natürlich schlecht für eine Veröffentlichung, weswegen Ether nicht nur aus der Bibliothek besteht, sondern auch noch aus der Ether.exe. Jagt man da das Programm durch, bevor man es veröffentlichen will, werden alle Verweise auf Ether gelöscht.
Außerdem werden die includes mit der passenden Datei ersetzt. Dadurch erhält man eine große Datei mit allem Quellcode.

Das nächste Problem war, das die Trennung von Debug und Release Code schwer war. Ich will in einem veröffentlichten Projekt kein if(debug) sehen. Das gehört schön in die Development Umgebung. Dafür stellt Ether unter Ether.debug.block die zwei Methoden start() und end() bereit.

Während der Entwicklung werden diese Methoden quasi ignoriert da sie nichts beinhalten, aber sobald der Quellcode durch Ether.exe gejagt wurde, werden diese Zeilen inklusive aller Zeilen dazwischen aus dem Quelltext entfernt. Damit enthält der Release Code keinerlei Debugzeilen mehr.

Ether verfügt noch über ein paar weitere schicke Features, die ihr auf der Projektseite sehen könnt. Die Entwicklung geht noch voran, da mir noch zwei Extensions fehlen, aber im großen ist das Featureset komplett.

Eigtl. will ich die für meine HTML5 Spiele benutzen, aber da ich starken Zuspruch erhalten habe die doch zu veröffentlichen, habe ich das nun getan. Vllt. finden sich tatsächlich Leute die das auch gebrauchen können.

Happy coding,
Môr

Okay, alles nacheinander.

Erstmal kannst du dir gar keinen Quellcode zerstören. Der Development Quellcode wird ja nicht gelöscht. Es wird ja eine neue Datei mit Releasecode angelegt.

Der Vorteil von Methoden ist, das ich sie noch erweitern kann. Es soll durchaus Leute geben, die Interesse daran haben zu loggen wenn bestimmte Debug Blöcke aktiviert werden.

Von Ether.exe wird der Quellcode immer genau an der Stelle eingefügt an der du den include hattest. Allerdings werden Ether.include.JavaScript immer in den globalen Namensraum geladen. Das ist eine gute Anmerkung und sollte ich dringend ändern. Danke.

Ansonsten muss man sich natürlich an eine eine korrekte Syntax halten. Ich habe keinen Interpreter geschrieben, sondern lediglich ein Tool um die Entwicklung angenehmer zu gestalten.

Edit:
Deine Anmerkung habe ich nun gefixt. Es wird in beiden Fällen nun in den global scope geschoben. Auch die Syntax bei Ether.debug.block.end() und -start() erlaubt jetzt belieblige Zeichenketten dazwischen. Wäre sowieso gekommen, sobald ich dort Logeinträge eingefügt hätte.

Danke für die Anmerkungen.

Zitat von »Sacaldur«

das Einbinden von Code finde ich bisher... naja...
es muss eine Methode sein, damit während des Debuggens der Code eingebunden werden kann
allerdings kann man einer Methode auch etwas anderes übergeben, als statische Zeichenketten (bei einer Methode könnte man früher oder später auch auf diese Idee kommen)
die Anwendung kann aber nicht auswerten, welcher Text eingefügt werden soll (spätestens bei tatsächlich variablen Dingen, wie Benutzereingaben oder der aktuellen Systemzeit dürfte das nicht mehr funktionieren)
allerdings kann ich keine besser Lösung nennen (vielleicht, weil es einfach keine bessere gibt? =/)

Das was du schreibst macht in diesem Fall doch gar keinen Sinn.
Die Includes funktionieren ähnlich wie in C++. Da gibt es auch nicht die Möglichkeit irgendwelche Variablen oder derlei zu laden. Du darfst diese includes eben nicht als dynamisches nachladen betrachten, es sei den du willst die gesamte Anwendung genau so ausliefern.

Die includes werden ja nur in der Debug Umgebung zur Laufzeit ausgewertet, aber eben in der Release Version nicht. Wenn man sich dessen bewusst ist, sollte man auf solche Ideen gar nicht erst kommen.

Ja, ich habe gerade einen eingefügt in den Quellcode. Wird beim nächsten push auch mit drauf geschoben. Für mich war es klar wie sie funktionieren, deswegen bin ich ja auch dankbar, wenn jmd. sowas schreibt.

P.S.: Viel mehr Spaß macht eh das benutzen, als den Teufel an die Wand zu malen.

Weiterer Tag, weiteres Vergnügen.
Der Profiler hat non ein vorgebautes Frontend bekommen. Dies ist allerdings leicht austauschbar, also kann jeder auch sein eigenes bauen und davor schalten. Deshalb liegt das Profiler Frontend auch nicht in Ether.js sondern in profiler.js. Diese muss dann natürlich inkludiert werden.

Angucken könnt ihr euch die neusten Fortschritte hier:

http://portalwelten.de/Ether/example/debug.html
(Getestet IE9, FF 5&6, Opera 11.52, Chrome 14, Safari 5.1)
& gitHub ist auch auf dem neusten Stand inkl. exe