Beschreibung:

Dies soll meine plattformunabhängige, freie, Pascal SDL/OpenGL Engine werden.

Im Prinzip soll sie so viel wie möglich bereitstellen, ohne dabei unglaublich "aufgeblasen" zu sein. Man sollte im Prinzip nur die Features nutzen können, die man auch braucht.

geplante Features:

SDL-Management
OpenGL-Management
TextSuite
Virtual File System

Repository:

https://github.com/ev1313/EVEngine

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ich habe während ich die SDL-Header übersetzt habe mir Gedanken über die "Zukunft" der EVEngine gemacht. Insbesonderen darüber, ob die Delphi-Integration
1. sinnvoll und
2. zu schaffen ist

Letztendlich bin ich zu dem Schluss gekommen, dass es nicht ordentlich umsetzbar ist, insbesonderen unsinnvoll wäre. Wenn überhaupt würde es sich zum GUI-Design

lohnen, allerdings wäre es einfacher und effektiver einen eigenen Designer dafür zu erstellen. Darum habe ich den ersten Post gekürzt, er enthält jetzt nur noch eine

Kurzbeschreibung und Links.

Trotzdem hatte ich natürlich noch viiiele weitere Ideen und habe die wichtigsten aussortiert, die ich jetzt Schritt für Schritt angehen werde:

Zunächst einmal habe ich die Engine in 2 Teile gespalten: OpenGL und SDL

Ersteres wird extern verwaltet werden. Es wird zu den sogenannten Utils gehören, dazu gleich mehr.

Letzteres wird die eigentliche Engine:

Eine zentrale Klasse (ähnlich wie TApplication in Delphi) verwaltet alles: SDL, Windows, Events und den Main-Thread. Die Window-Klasse widerum ist ebenfalls so ähnlich

wie die TForm in Delphi aufgebaut. Ein größeres Problem dabei ist, dass man ja irgendwie die Eigenschaften übergeben muss. Eine Möglichkeit wäre alle im Konstruktor

als Parameter zu übergeben. Meine Lösung wird aber in einem Settings-Record bestehen:

Es gibt jenen Settings-Record, in dem die Settings gespeichert sind und ein paar prädefinierte Settingskonstanten vom Typ jenes Records, die dann ein paar übliche

Werte enthalten. So kann man dann die Settings bequem übergeben:



Hoffe natürlich, dass dieses Konzept auf Zustimmung stößt

Nun zu den sogenannten Utils:

Diese Utils werden völlig losgelöst von dem Rest der Engine sein, also jedes einzelne wird "stand-alone" ohne jegliche anderen Sachen außer vllt. SDL, OpenGL, oder

anderen Externen Lib's laufen. Hier meine bisherigen Ideen für Utils:

1. OpenGL-Manager

Der OpenGL-Manager ist im Prinzip eine Klasse für alles

Jede einzelne Instanz dieser Klasse verwaltet einen eigenen Context, dieser wird allerdings nicht von der Klasse selbst erstellt, sondern der "Anwender" (eig.

Programmierer, der die Unit benutzt) erstellt ihn und die Klasse erledigt den Rest. Somit kann man die Klasse auch ohne SDL verwenden, also in die eigene VCL-Lösung

integrieren, o.Ä.

Verwalten wird sie:

VA, VBO, VAO

Da VA's meines Wissens nicht mehr benutzt werden sollen wird es wohl letzlich darauf hinauslaufen, dass sie komplett gestrichen werden. (ja, die Klasse wird auf dem

höchstmöglichen OpenGL-Niveau sein )

Es wird wohl Methoden wie "CreateVBO" geben, mittels derer man dann ein VBO und gleich dazu ein VAO erstellen kann, da das VAO meines Wissens fest an ein VBO gebunden

ist. (Oder? klingt etwas unlogisch, könnte mich mal wer aufklären, bitte?) Das kann dann mittels BindVBO gebunden und mittels DeleteVBO gekillt werden.

FBO

Dasselbe in grün für FBO's. Create,Bind,Delete - mehr sollte nicht notwendig sein.

Shader

Shader sollen einfacher zu handhaben sein.

Ich überlege noch, ob ich Shader und Program-Objekte trennen sollte. Macht es in irgendeinem Fall Sinn mehr als einen Vertexshader auf ein Program-Object zu packen?

(Aufklären, bitte!)

Ansonsten wird es einfach zu handhaben sein, Create,Bind,Delete - wie bei den anderen Objekten auch. Aber was mit den:

Uniforms/UBO

Meine Grafikkarte hat meines Wissens ein Limit von <100 UBO's. Darum habe ich mir überlegt: (auch aus Gründen der Abwärtskompatibilität)

Eine UBO-"Emulation" - man übergibt der Klasse ganz normal die Daten die man normalerweise mit den UBO-Befehlen übergibt, diese werden aber nur direkt an die Graka

geschickt (means in ein UBO gespeichert), wenn man das auch will, bzw. wenn noch genug "UBO-Plätze" auf der Graka frei sind. Ansonsten werden sie in der Klasse

gespeichert und es werden die normalen glUniformXX-Befehle verwendet.

State Cache

Sollte selbsterklärend sein...

Texturen

Eine Texturenverwaltung, vllt. sogar intelligent...? Falls es möglich ist, baue ich dieses Feature ein, dass mal im Forum angesprochen wurde, in DX "Tiled Resources". Mal schaun, wie man das in OpenGL machen kann.

2. Virtual-File-System

Es soll ein simples, aber extrem modulares und erweiterbares VFS werden, also geeignet für jeden Anwendungszweck. Es gibt im wesentlichen 3 Klassen:

TVFS - Die Haupt-Verwaltungsklasse, verwaltet:

TVFSFile - Eine virtuelle Datei und:
TVFSFolder - Einen virtuellen Ordner

Die Hauptverwaltungsklasse kann Dateien und Verzeichnisse von überallher laden, aufbauend auf folgendem System:

Es gibt zwei verschiedene Methodentypen zum Laden von Dateien und Ordnern:



Mit diesen kann man dann Bibliotheken erstellen mit unterschiedlichen Laden-Funktionen. Man übergibt immer ein Array von diesen Funktionen an die Hauptklasse, diese

werden dann alle nacheinander aufgerufen, solange bis eine "TRUE" zurückgibt.

Gesonderte Speichernfunktionen wird es natürlich, orientiert an den Ladenfunktionen, auch geben.

3. TextSuite

Die TextSuite von LossyEx funktioniert nicht mehr mit SDL2 und ich hab keine Lust mich durch die Bibliothek zu wühlen, darum schreibe ich eine eigene (vorallem um des

Lehrzwecks Willen (jeden Tag einmal den Genitiv verwenden, erfüllt ))

Zunächst gibts nur Funktionen zum Laden von Fonts und Zeichnen von Texten. Die Texte sind natürlich vorerst nur in 2D und werden mittels SDL_TTF erstellt. Ein Feature

will ich aber haben, drum gibts: Rotierte Texte.

Es wird die Möglichkeit geben einen Text entlang einer Bezier-Kurve auszurichten. (Brauch ich für schöne Landkarten, aber mein Spiel will ich jetzt noch nicht verraten

)

4...

fällt mir grade nicht mehr ein, aber falls ihr noch Vorschläge habt - wofür gibts den Meinungsthread?

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Da ich die Engine (vorerst wohl nur den OpenGL-Manager) für mein Informatik-Zeugs brauchen werde, hab ich schon mal den OpenGL-Manager halbwegs ... nicht fertiggestellt, aber angefangen

Folgende Sachen verwaltet er:

VBO
IBO
Shader/Program-Objects
UBO's
Texturen

Ich mache mir gerade Gedanken wie ich das Log-System letztendlich mache. Ursprünglich wollte ich, dass jede Klasse von der Hauptklasse TEVApplication verwaltet wird, damit alle "Log-Messages" (die Log-Funktion wird jeweils beim Owner aufgerufen, bis sie irgendwann von TEVApplication verarbeitet wird) verarbeitet werden können.

Wenn ich aber alles unabhängig von dem SDL-Teil machen will, geht das nicht. Darum könnte ich vllt. das Log-System auslagern in eine eigene Klasse, was ich persönlich aber blöd finde. Mal sehen, ich muss eh endlich dieses **** Labyrinth fertig kriegen.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Ja, ich hab hieran durchaus lange gearbeitet, immer wieder etwas. Ich kann nicht schlafen, darum schreibe ich hier mal wieder was zu EVEngine.

Zunächst einmal hab ich mich letztendes dazu entschieden die Dokumentation mit pasdoc zu basteln. Hab noch diverse andere Tools, u.A. pas2dox mit Doxygen ausprobiert und mich dann doch für ersteres entschieden. Es ist zwar nicht ganz so leistungsfähig wie Doxygen, aber es erfüllt seinen Zweck, ist auf Pascal optimiert und man muss nichts haxxen.

Mittlerweile hab ich sogar zwei laufende Demos, die sogar recht nett aussehen. Bei der Hauptklasse, TEVApplication habe ich mich für einen ähnlichen Weg wie die Lazarus Form entschieden:



Eine einzige globale Instanz schien mir der beste Weg zu sein, vorallem da SDL auch nur einmal initializiert werden sollte.

Window's sollen überladen werden und kriegen dann die Events von EVApplication zugeliefert, so auch das Mainloop-Event (ein Event, das jeden Schleifendurchgang in der Mainloop einmal an alle Windows gesandt wird).

OpenGL Contexte sollen nicht überladen werden, sie sind weiterhin immer von einem Window abhängig (SDL macht das halt so).

Das Loggingsystem ist in EVApplication geregelt, eine globale Methode Log() verweist auf EVApplication.Log(). Momentan gibts zur Identifikation nur einen Timestamp und einen Errorlevel von Info bis Critical. Falls letzterer zu hoch ist wird weiterhin automatisch eine Exception gethrowt. Letztere mach ich später dann noch als Zusatzparameter auswählbar, außerdem gibts vllt. noch unterschiedliche Submodullogs mit möglicherweise separaten Logfiles oder so.

Es gibt für VBO/IBO's eine BufferObject Klasse, für VAO's eine VertexArrayObject Klasse, die beide ziemlich intuitiv zu bedienen sein sollten.

Für Shaderprogramme gibts eine Klasse, die sich ums Laden und Linken kümmert. Besonders stolz bin ich auf meine Uniform Klasse. Sie erkennt automatisch via OpenGL den Typ der Uniform und sucht sich selbst die passende glUniform Methode raus. Dann kann man die Daten einfach via Write-only Property (wer hätte gedacht, dass man sowas mal brauchen würde?) und passenden Pointer an OpenGL übergeben:



Man kann weiterhin verschiedene Shader als Locations angeben (solange alle denselben Typ haben). Beim Update werden dann automatisch alle Shader geupdated (ich glaube allerdings, dass das momentane Handling eher suboptimal ist, wegen dem ganzen Shaderneubinden und so, da fällt mir hoffentlich noch was ein :X). Außerdem muss ich noch UBO's und die neue GL 4.4 Extension einbauen.

Momentan arbeite ich an der GUI, danach sind die Klassen für Assimp dran. Für letzteres hab ich neue, aktuelle Header geschrieben, ebenfalls zu finden in meinem Repository.

Die GUI hat jedoch Vorrang und braucht auch einen Editor, ihr werdet hoffentlich diesmal etwas häufiger & früher von mir hören/lesen

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Hab übrigens bereits vor einer Woche oder so EVTextures geschrieben. Basiert ist das ganze auf glBitmap, allerdings stark modifiziert. ~ alle selbst definierbaren Sachen sind rausgeflogen, inklusive des eigenen OpenGL Zeugs. Dazu auch alle Alternativen Loader, es wird nur noch SDL_image genutzt, dazu in der aktuellen 2er Version. Außerdem sind ein paar Bugs im SDL Teil gefixt, ich werd das ganze über die Zeit vollständig dokumentieren und einige neue Features hinzufügen. Als erstes ist wohl der Texturatlas dran, damit ich das für die TextSuite verwenden kann.

Bei der GUI werd ich RTTI nutzen, um sie speichern und laden zu können, ich nutz dann einfach das LFM Format.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Momentan ersetze ich EVTextures durch eine eigene Texturklasse und class helper für die einzelnen Formate.

Derweil hab ich viele kleine Tweaks an der OpenGL Klassensammlung vorgenommen, u.A. hab ich die Uniformklasse in die Shaderklasse integriert, was das Shaderladen nun ziemlich einfach macht. Weiterhin gibt's nun auch eine Uniform Buffer Object Klasse mit teilweiser Integration in den Shader, die auch das UBO Handling extrem vereinfacht.

Weiterhin hab ich eine momentan schon ziemlich gut funktionierende Assimpwrapperklasse geschrieben. Momentan kann sie mittels Assimp Modelle laden und texturiert rendern. Am Materialladen arbeite ich gerade noch, Vertices, Normalen und Texturkoordinaten klappen allerdings bereits. Ich müsste eigentlich noch das Speichermanagement optimieren, das schiebe ich allerdings vorerst auf

Mit dem momentanen Stand bin ich eigentlich ziemlich zufrieden, sobald die Texturklassen gewrappt sind ist der grundlegende Frameworkteil für simple OpenGL Demos eigentlich schon fertig. Vielleicht präsentiere ich nach der Prüfungszeit (im März) ja mal das Spiel, an dem ich arbeite

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)