[PROJEKT] FooFX - Game Engine
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
[PROJEKT] FooFX - Game Engine
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.
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.
Imaging-Software und bald auch Middleware: http://fd-imaging.com
Re: [PROJEKT] FooFX - Game Engine
Das klint innovativ. :)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
Böse Frage:[*]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.
Wieso wrappst Du das extra nochmal?
:D C++ ? ^^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.
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: [PROJEKT] FooFX - Game Engine
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.Böse Frage:
Wieso wrappst Du das extra nochmal?
Jap. :)Das klint innovativ.
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. :PC++ ? ^^
Imaging-Software und bald auch Middleware: http://fd-imaging.com
Re: [PROJEKT] FooFX - Game Engine
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? :)
Ich verkaufe diese feinen Lederjacken.
-
- Establishment
- Beiträge: 191
- Registriert: 01.03.2009, 19:22
- Echter Name: David N.
Re: [PROJEKT] FooFX - Game Engine
Diesbezüglich vielleicht interessant, wenn nicht bereits bekannt: http://theses.fh-hagenberg.at/thesis/Meisinger10
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: [PROJEKT] FooFX - Game Engine
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.
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.
Imaging-Software und bald auch Middleware: http://fd-imaging.com
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: [PROJEKT] FooFX - Game Engine
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.
Imaging-Software und bald auch Middleware: http://fd-imaging.com
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: [PROJEKT] FooFX - Game Engine
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!
Sobald das Grafik-Modul fertig ist, zeige ich auch mal was!
Imaging-Software und bald auch Middleware: http://fd-imaging.com
-
- Establishment
- Beiträge: 191
- Registriert: 01.03.2009, 19:22
- Echter Name: David N.
Re: [PROJEKT] FooFX - Game Engine
Du schreibst eine JavaScript-Engine selbst? Wäre es nicht um Größenordnungen einfacher, etwas Fertiges wie V8 einzubetten?
- Artificial Mind
- Establishment
- Beiträge: 802
- Registriert: 17.12.2007, 17:51
- Wohnort: Aachen
Re: [PROJEKT] FooFX - Game Engine
Wenn V8 in Haskell geschrieben wäre, bestimmt.
-
- Establishment
- Beiträge: 201
- Registriert: 07.07.2010, 13:00
- Kontaktdaten:
Re: [PROJEKT] FooFX - Game Engine
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".
Edit: Mit "fertig" meinte ich eher "vorübergehend fortgeschritten genug und lauffähig".
Imaging-Software und bald auch Middleware: http://fd-imaging.com