ZFX + Developia

Moin,

um der Aufbruchstimmung und dem Trend in der Projektsparte zu fördern bzw. fortzusetzen, habe ich mich entschlossen eines meiner aktuellen Projekte vorzustellen. Nein, es ist nicht die Engine, die ich schon oft im Irc erwähnt habe, diese Engine werde ich wohl aus Scham wegen meinem C++-Code bzw. Drang zur Perfektion nie Open Source veröffentlichen. Auf der anderen Seite wird diese Engine aber auch kommerziell genutzt und ist nicht ganz nutzlos.

Beschreibung: Bei FooFX handelt es sich um meine langjährig konzipierte funktionale Game Engine, die komplett in Haskell entwickelt wird. Aufgrund der unterschiedlichen Paradigmen sind andere Konzepte nötig, die die Engine gestalten. FooFX an sich ist erstmal als Multimedia-Framework und Game Engine definiert, allerdings können durchaus Komponenten aus wissenschaftlichen Simulationen sowie Compiler-Bau enthalten sein.

Sprache: Haskell

Aktueller Release: Noch nicht veröffentlicht

Nächster Release: Version 0.1.0 im Oktober/September, je nach Gefühl

Plattformen:Linux( Höchste Priorität ), MacOSX/Windows( Geringe Priorität )

Über längere Zeit sind folgende Features geplant:

[*] Abstrahierte Rendering-Modul:
Dieses Modul ist wie Haskell selber sehr abstrakt und hat letztendlich nicht mehr viel mit einer spezifischen API oder einem spezifischen System zu tun. Ich will hier zum Beispiel Template Haskell( wie in C++, nur wesentlich mächtiger ) nutzen, um dynamisch zur Compilezeit Renderer generieren zu können. Beispielsweise müsste der Entwickler mit einer Pipeline angeben, wie sein Renderer aussehen soll:

type DeferredRenderer = (Renderables -> Framebuffer) -> (Lighting -> Framebuffer -> Framebuffer) -> (PostEffects -> Framebuffer -> Framebuffer) -> Framebuffer

Das würde zum Beispiel im abstrakten Sinne einen Deferred Renderer implementieren. Ich habe den Code vereinfacht geschrieben, damit er auch für Non-Haskeller lesbar ist. :) Ich bin noch nicht so weit mit den Konzepten für das abstrahierte Rendering-Modul, allerdings möchte ich ein bestimmtes Konzept verfolgen: Das Modul arbeitet nicht auf Basis von Typen bzw. bestimmten Strukturen, sondern arbeitet auf Basis von abstrakten Datentypen, die einfach nur bestimmte Verhaltensweisen implementieren. Es wird nicht von Funktion A angefordert, dass Parameter B eine Texture sein muss, sondern dass sich B wie eine Texture verhalten muss. Allerdings wird dies nur die oberste Schicht sein.

[*] System-Module:
Das System-Modul ist die Basis aller anderen Module und implementiert Basis-Objekt Verhalten sowie Multithreading. Ich möchte möglichst versuchen, dass jedes Modul der Engine multithreaded ist und auch dynamisch Single-Threaded laufen kann. Außerdem ist hier ein Feature untergebracht, dass relativ viele Datentypen per Template-Haskell in XML schreiben kann. Alle Daten in der Engine werden in XML gespeichert sein.
Außerdem enthält dieses Modul eher Haskell-untypische Features wie ein Event-System oder Exceptions.

[*]Algorithm-Module:
Das Algorithm-Module implementiert zum einen einfache Algorithmen auf Bilder bzw. Collision Detection und Vector/Matrizzen/Quaternionen-Mathematik. Außerdem ist einfache OpenCL Unterstützung geplant.

[*]Graphics-Module:
Das Graphics-Module setzt auf einem selbstentwickeltem OpenGL 4.1 Wrapper auf. Das Grafik-Modul baut auf modernen Techniken auf und wird ausschließlich OpenGL 4.1 nutzen. Ansonsten recht unspektakulär. Materialien sowie Effekte werden in XML gespeichert, wie der Rest auch.

Ich möchte nochmal darauf hinweisen, dass aktuell nocht nichts implementiert ist. Ich möchte diesen Thread für Anregungen und Feedback nutzen und natürlich auch Werbung für die beste Sprache der Welt machen.

Ich werde jetzt täglich immer etwas an FooFX weiterarbeiten und regelmäßig Bericht erstatten.

j.klugmann hat geschrieben: Beispielsweise müsste der Entwickler mit einer Pipeline angeben, wie sein Renderer aussehen soll:

type DeferredRenderer = (Renderables -> Framebuffer) -> (Lighting -> Framebuffer -> Framebuffer) -> (PostEffects -> Framebuffer -> Framebuffer) -> Framebuffer

Das klint innovativ. :)

[*]Graphics-Module:
Das Graphics-Module setzt auf einem selbstentwickeltem OpenGL 4.1 Wrapper auf. Das Grafik-Modul baut auf modernen Techniken auf und wird ausschließlich OpenGL 4.1 nutzen. Ansonsten recht unspektakulär. Materialien sowie Effekte werden in XML gespeichert, wie der Rest auch.

Böse Frage:
Wieso wrappst Du das extra nochmal?

Ich möchte nochmal darauf hinweisen, dass aktuell nocht nichts implementiert ist. Ich möchte diesen Thread für Anregungen und Feedback nutzen und natürlich auch Werbung für die beste Sprache der Welt machen.

:D C++ ? ^^

Böse Frage:
Wieso wrappst Du das extra nochmal?

Wrapper und Bindings werden beide von mir entwickelt. Das hat einen ganz einfachen Grund: Statemachines sind nicht in funktionalen Sprachen wie Haskell umzusetzen, insofern will ich direkt auf OpenGL-aufsetzend eine funktionale Grafik-API bauen.

Das klint innovativ.

Jap. :)

C++ ? ^^

Hach, C-Postinkrement ist doch nun wirklich nicht mehr auf der Höhe der Zeit. :P Nein, Haskell war gemeint, allerdings war das auch nicht richtig ernst. Das soll hier bitte nicht in einem Flame enden. :P

Hmm ich frag mich wie wohl Game Code in Haskel aussehen mag :o Haste da speziell zu deiner Engine schon Pläne so das du ein Beispiel zeigen kannst? :)

Diesbezüglich vielleicht interessant, wenn nicht bereits bekannt: http://theses.fh-hagenberg.at/thesis/Meisinger10

Von dem genannten Paper halte ich nicht viel, es nennt zwar viele Probleme, allerdings wird nicht viel zu ihrer Lösung beigetragen.

Fortschritt: Aktuell implementiere ich verschiedene Variationen von Tries und weiteren Container-Typen. Tries bieten bei string-basierter Organisation die beste Performance im Vergleich zu anderen Konzepten in Haskell. Alles was mit Pointern zu tun hat, fällt natürlich raus, da es in Haskell keine Pointer gibt. Nach den Container-Typen werde ich die Parsing-Lib angehen.

Kleines Update: Das Ressourcen-System ist fast fertig und kann unabhängig von der Datenquelle Daten lesen. Man kann seine Assets also auch durchaus per Http laden oder aber auf die klassische Variante. Das ganze Ressourcen-System bietet Möglichkeiten zum Streaming von beliebigen Datensätzen, schreiben als auch lesen kann asynchron vonstatten gehen. Aktuell gehe ich davon aus, dass ich nächste Woche mit dem Grafik-Modul beginnen kann.

Kleines Update: Ich habe mich an einen Javascript-Interpreter gemacht, der wohl auch bis Ende der Woche fertig sein wird. Mit Javascript soll ein Großteil der Spiele und Anwendungen entwickelt werden, nicht zuletzt kommt es mir ja auf die Entwicklungsgeschwindigkeit an. Javascript bzw. Scripting bietet da sehr gute Chancen, um möglichst schnell zu prototypen. Alternativ zur Interpretation von Javascript gibt es bereits einen halbwegs lauffenden Byte-Code Compiler bzw. Interpreter. Falls man also wirklich mit FooFX mal Anwendungen schreiben würde, könnte man Javascript vorkompilieren, das würde die Geschwindigkeit etwas erhöhen.

Sobald das Grafik-Modul fertig ist, zeige ich auch mal was!

Du schreibst eine JavaScript-Engine selbst? Wäre es nicht um Größenordnungen einfacher, etwas Fertiges wie V8 einzubetten?

Wenn V8 in Haskell geschrieben wäre, bestimmt.

Das Problem ist nicht, dass V8 nicht in Haskell geschrieben wurde, sondern eher, dass sich noch keiner dazu bereit erklärt hat, V8-Bindings zu bauen. C/C++ Bindings für Haskell sind mittlerweile sehr einfach, da man einen Großteil der Bindings mit Template-Haskell generieren lassen kann. Außerdem machen mir Compiler sehr viel Spaß, zusätzlich bin ich der Meinung, dass Haskell sehr für den Compiler-Bau geeignet ist.

Edit: Mit "fertig" meinte ich eher "vorübergehend fortgeschritten genug und lauffähig".