Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Di Mär 19, 2024 03:27

Foren-Übersicht » Sonstiges » Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 50 Beiträge ]  Gehe zu Seite 1, 2, 3, 4  Nächste
Autor Nachricht
 Betreff des Beitrags: [Game] Gael
BeitragVerfasst: Mi Apr 08, 2009 15:24 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
So liebe Community, erstmal ein herzliches Hallo an alle.

Wichtige Links

Einleitung
Ich hab mir seit ein paar Monaten ein paar Ideen durch den Kopf gehen lassen und bin zu dem Entschluss gekommen, mal wieder ein Großprojekt mit OpenGL zu starten.

Diesmal hab ich mir vorgenommen, ein Spiel zu erstellen - genau genommen ein First Person Shooter. Das Spiel an sich hat bisher keinen Namen - Gael ist nur der Name der Engine ([Ga]me [e]ngine [L]...), wobei ich noch nicht genau weiß, was das L bedeuten soll (Gael klingt besser als Gaen). Solange mir noch kein Name für das Spiel eingefallen ist, heißt es einfach auch Gael.

Spielkonzept
Das Wort Shooter klingt schon wieder viel zu brutal im aktuellen Deutschland, daher muss ich wohl etwas genauer sein. Das Spiel soll ein Multiplayer-Taktik-Shooter mit dem Motto Einer gegen Alle werden. Das Grundprinzip ist folgendes: In einem Spiel gibt es einen Dieb und mehrere Wächter. Zu Beginn einer Runde wählt der Dieb ein Ziel aus, welches er stehlen will. Dabei wird er sich zwischen mehreren Gegenständen in einer Map entscheiden müssen. Seine Wahl ist für die Wächter nicht sichtbar, so dass diese nicht wissen werden, wo diese sich am besten aufhalten können. Der Dieb muss zum erreichen eines Ziels mehrere Unterziele in fast beliebiger Reihenfolge abarbeiten. Fast bedeutet hier: man kann natürlich nicht eine Alarmanlage ausschalten, wenn man nicht weiß wo ;-). Der Dieb hat eine Runde dann gewonnen, wenn er das Primärziel erreicht hat, ansonsten haben die Wächter die Runde gewonnen.

Level
Da hab ich mir diesmal sehr viel vorgenommen. Also alle Levels werden nur drinnen sein und alles wird sich nachts abspielen. In den Levels wird es viele dunkle Gänge und nur wenig Licht geben. Viele Lichter werden noch an und ausschaltbar sein, wobei ich mir da noch nicht so genaue Gedanken gemacht habe. Insgesamt werden die Levels über mehrere Stockwerke verfügen und ich werde es versuchen, dass jedes Ziel über mehrere Wege erreichbar sein wird.

Waffen
Die Hauptwaffe des Diebes wird das Schleichen und das Verstecken in dunklen Ecken sein. Zusätzlich wird er noch ein paar Gimicks dabei haben, da er ja alleine ist.
Die Hauptwaffe der Wächter wird ihr Team sein. Zwar sind die Wächter mit Schusswaffen ausgestattet (der Dieb übrigens auch), jedoch wird das Schießen nicht sehr einfach sein. Zusätzlich kann ein Wächter nicht seine Waffe und gleichzeitig seine Taschenlampe in der Hand halten.

Spiel
Das Spiel will ich so gesalten, dass es nicht sinnvoll ist, sich ballernd durch die Maps zu kämpfen. Ich will es versuchen, dass die Wächter nur im Team und der Dieb nur durch Schleichen die besten Erfolge hat. Wahrscheinlich werd ich es so machen, dass es überhaupt keine tödlichen Waffen geben wird, sondern nur Beteubungswaffen.

Technik
Im Moment arbeite ich noch viel am Spieldesign, jedoch entwickle ich nebenbei schon an der Engine selbst. Im Moment bin ich sehr am Testen des aktuellen Frameworks, wobei mich im Moment das Real-Time-Shadowing sehr beschäftigt. Hier mal zwei Screenshots der aktuellen Technikdemo:
Bild Bild

Das Grundlegende Prinzip ist folgendes: Jede Map besteht aus einem oder mehreren Meshes. Jedes Mesh besteht aus mehreren Polygonen, die jeweils aus Dreiecken aufgebaut sind. Jedes Polygon hat ein zugewiesenes Material, in dem das komplette Erscheinen festgelegt ist. Ein Polygon enthält dabei nur die Daten, die dann vom Material benutzt werden (Position, Normale, TexCoords, ...).
Jedes Material enthält eine Liste von Texturen sowie spezielle Optionen wie Blending usw. Die Texturen an sich bestehen aus einer Textur-Klasse, in der die Wrap und glTexEnv usw. festgelegt werden. Die Texturen haben dann noch eine Unterklasse, in denen die eigentlichen Texturdaten verarbeitet werden.
Jedes Material hat mehrere CallBack-Events, an die sich Script-Methoden oder Statische Methoden binden lassen.
Dann gibt es noch eine VBO-Liste, in der alle VBOs angelegt werden. Für jedes Material wird ein VBO angelegt, wobei sich die Anordnung der Daten in jedem VBO je nach Material unterscheiden. Somit gibt es in einem VBO für ein Material ohne Texturen keine Texturkoordinaten.
Dann gibt es noch eine Shader-Library. Diese ist wie eine Art Baum aufgebaut. Für jeden RenderPass gibt es mehrere Äste, die dann wieder Anhand der Anzahl von Lichtern wieder aufgesplittet werden. Am Ende kommt man dann anhand das Materials auf den passenden Shader. Somit wächsle ich zwar relativ oft den Shader, jedoch brauch ich so keinen Mega-Shader, der alles kann - einem Material, welches keine Texturen hat, muss ich keinen Shader zuweisen, der auch Bump-Mapping verarbeitet.

Als Grafiklibrary benutze ich natürlich OpenGL, wobei ich durch den massiven Einsatz von Shadern eine OpenGL 2.0 Karte als Minimum vorraussetzen werden.

So, das wars für erste. Bin gespannt was ihr zu dem Konzept sagt und hoffe auf konstruktive Kritik.
Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Zuletzt geändert von littleDave am Sa Sep 05, 2009 16:24, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Apr 18, 2009 13:20 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
So, in den letzten 10 Tagen hab ich die Engine sehr überarbeitet. Jetzt ist es z.B. kein Problem mehr, mehrere Lichter in einer Szene zu haben. Dafür verwende ich einen einfachen Forward-Renderer mit glBlendFunc(GL_ONE, GL_ONE);. Jedoch bin ich dabei mir zu überlegen, ob ich nicht auf Deferred Shading umsteigen soll. Ich denke, dass ich am Ende viele Lichter haben will und keine Lightmaps verwenden will - schließlich will ich alles möglichst dynamisch machen. Jedoch bin ich mir dabei noch nicht sicher - wahrscheinlich werd ich ne weitere TechDemo erstellen, in der ich die Engine mal als Deferred Renderer ausprobiere. Jedoch muss ich mich dabei noch genauer mit dem Deferred Shading-Model auseinander setzen (um z.B. Lösungen für das Blending-Problem beim Deferred Shading zu finden).

Außerdem hab ich jetzt einen wichtigen Schritt gemacht: die Engine läd jetzt die Map aus einer Datei. Als Dateiformat hab ich im Moment XML genommen. Dadurch hab ich den Vorteil, dass ich nicht erst nen Editor erstellen muss, um eine Szene zu bearbeiten.

Zudem hab ich die Shader noch etwas überarbeitet. Das Parallax Mapping funktioniert jetzt korrekt und die Bump-Maps sind jetzt auch richtig. Zudem hab ich noch die Shader etwas optimiert, was eine sehr große Performance-Steigerung zur Folge hatte.

Meine aktuelle Planung schaut wie folgt aus:
Zuerst werd ich mal deferred shading ausprobieren. Jedoch erst mal als eine Art Nebenprojekt. Das heißt: wenn ich nicht gut vorran komme, werd ich das erstmal überspringen.

Danach werd ich mich an die Tools setzen, also einen Material-Editor, nen Level-Editor, nen Shader-Editor usw. Das wird eine ganze Weile in Anspruch nehmen, jedoch hab ich ja bereits für meine alte Engine nen Editor geschrieben und hab daraus einiges gelernt. Somit muss ich nicht bei 0 anfangen (von der Erfahrung her)

Zur Performance:
Aktuell hab ich auf ner ATI Radeon HD 3470 (Laptop) bei 1280x800, 3 Lichtern mit einer jeweiligen ShadowMap von 512x512, Soft-Shadows, Bump Mapping und Parallax Mapping ca. 25 bis 30 FPS. Dies liegt vor allem an den Shadern, wenn ich diese ausschalte hab ich konstante 60 FPS (mit VSync an, ohne hab ich nicht probiert). Aktuell hab ich ne CPU-Auslastung von ca. 5%, da ich alles per VBO zeichne und die Daten bei jedem Frame nicht erst über die CPU hochgeladen werden müssen.

Hier noch ein paar Screenshots aus der aktuellen TechDemo (alles RealTime-Rendering)
[url=http://gael.godlikesoft.de/2009/04/engine-progress/]Bild Bild Bild

Bild Bild Bild

Bild Bild Bild

Bild Bild[/url]

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Apr 30, 2009 17:43 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Ich bin's mal wieder.

in der letzten Woche hab ich nicht so viel Zeit für das Projekt gehabt, aber ich habe es dennoch geschafft, endlich Punktlichter einzubauen. Da meine Grafikkarte keine Depth-Cube-Maps unterstützt, wird bei Punktlichtern die Tiefenmap noch in 6 Texturen geschaufelt und dann später einzeln gezeichnet. Dabei grenze ich die gezeichneten Fragments mit Clipplanes ein, um nur den beeinflussten Bereich zu zeichnen. Im Moment arbeite ich daran, nicht mehr GL_ARB_shadow zu verwenden sondern versuche die Schatten im Shader zu berechnen. Dies funktioniert grundlegend zwar schon, jedoch hab ich noch ein Problem mit der Near-Clipping-Plane beim erstellen der Tiefentextur aus der Sicht der Lichtquelle. Wenn ein Objekt jetzt zu nahe an das Licht kommt, wird es nicht mehr in die Depth-Map aufgenommen und wirft somit auch keine Schatten. Ich schau mal, wie ich dass noch lösen kann (wahrscheinlich durch nen einfachen Offset im Depth-Shader, jedoch hab ich das noch nicht ausprobiert). Wenn ich dann nicht mehr GL_ARB_shadow verwende, kann ich auch Cube-Maps benutzen, wodurch der finale Zeichenaufwand für Point-Lights weniger werden dürfte.

Intern besteht ein Point-Light aus 6 Spot-Lights, die ich einzeln (de)aktivieren und verändern kann. Somit kann ich auch für jede Richtung ne andere Lichtfarbe verwenden (was jedoch relativ blöd ausschaut).

Was ich mir auch noch überlegt habe ist die Unterstützung von Glas, wobei die Farbe dann die Lichtfarbe beeinflussen soll. Ich hab mir noch keine genauen Gedanken gemacht, jedoch habe ich es wie folgt vor:

Als Tiefentextur wollt ich dann ich GL_RGBA16F, wobei ich die ersten 32Bit für die Tiefenwerte verwende und die zweiten 32 Bit für die Farbe des Lichtes. Im finalen Shader bereichne ich erst, ob das Fragment im Schatten liegt. Wenn nicht, multipliziere ich die Fragment-Farbe noch mit der Light-Farbe aus der Textur. Jedoch ist das noch nicht final, ist einfach nen Gedankengang von mir. Wenn jemand da ne gute Idee hat bzw. meine Idee bestätigen will - nur her damit.

Ich hab auch wieder nen kurzes Video für das Point-Light bei YouTube hochgeladen. Das Video hab ich hier verlinkt. Es ist leider nicht sehr gut, da ich schnell machen musste (war nur im Batteriebetrieb aufm Laptop)

Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Zuletzt geändert von littleDave am Sa Sep 05, 2009 16:25, insgesamt 2-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Mai 08, 2009 17:11 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Hallo,

so langsam kommt mein Framework ganz gut voran. Aktuell hab ich den Renderpfad erweitert, so dass ich jetzt Post-Scene-Effects einbauen kann. Als Versuchseffekt hab ich nen Blur, einen Bloom und einen Depth-of-Field-Filter eingebaut.

Die einzelnen Render-Passes sind eigene Objekte, die 3 Funktionen haben: Prepare, Render, EndRender. Die einzelnen Objekte sind komplett über nen XML-Konfigurationsfile einstellbar. Der Post-Scene-Filter ist auch ein Render-Pass, der intern nacheinander die einzelnen verlinkten RenderPasses in eine Textur rendert und diese dann per Full-Screen-Quad und einem Shader, der ebenfalls per Config eingestellt werden kann, auf den Bildschirm.

Der Depth-of-Field Effekt schaut sehr gut aus und die Szene wirkt dadurch realistischer und auch plastischer. Hier hab ich nen neues Video verlinkt. Am besten wirkt es, wenn ihr das Video im Vollbild und in High Quality anschaut. Der Cursor zeigt dabei den aktuellen Fokus des Betrachters. Umliegende Elemente mit unterschiedlichem Tiefenwert werden langsam unscharf.

Zudem hab ich den Parallax-Shader sehr verbessert. Der verursacht jetzt keine Artefakte mehr und die Schatten werden jetzt auch korrekt verschoben. Am besten sieht man das in dem Video, wenn man sich auf die Wände konzentriert.

Ich habe auch schon angefangen, einen Editor zu basteln - jedoch ist da bisher noch nichts so wirklich was bei raus gekommen.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Zuletzt geändert von littleDave am Sa Sep 05, 2009 16:26, insgesamt 2-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Jun 03, 2009 23:30 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Hallo,

seit dem letzten Post ist schon ne lange Zeit vergangen, daher wollt ich mal nen kleines Update bringen.

In den letzten Wochen bin ich leider nicht dazu gekommen, an der Engine groß weiterzumachen - ich hatte zu viel andere Sachen zu tun. Beim letzten Post hab ich ja schon geschrieben, dass ich mich bereits an einen Editor gesetzt habe. Nur irgendwie passt mein Konzept doch nicht so ganz, wie ich mir das vorgestellt habe.

Grundlegend kann der Editor schon was: Objekte erstellen (im Moment nur Dreiecke, Vierecke und Würfel), Materials und Shader binden und anzeigen und Objekte verschieben und rotieren. Jedoch macht mir das skalieren große Problem - irgendwo ist da noch der Wurm drinnen.

Das eigendliche Problem ist: wie stell ich das mit dem Licht an. Wenn ich im Editor bereits das Anzeigen will, wie es am Ende wirklich ausschaut, hab ich nen kleines Problem: ich müsste bei fast jeder aktion alle betroffenen VBOs neu erstellen - und das will ich nicht. Zudem ist es noch ein riesen Aufwand, die ganzen Optimierungen, die dann später eingebaut werden, immer wieder neu zu Berechnen (z.B. der Octree).
Die zweite Möglichkeit (so wie ich es aktuell mache): alle Objekte werden im Immediate-Mode gezeichnet - ohne Licht. Das ist sehr viel einfacher, jedoch ist es dann blöd, das Licht korrekt einzustellen. Zudem muss ich so in das Framework keinen Editor-Render-Pfad einbauen und ich hätte Render-Engine und Editor sauber getrennt.

Da ich mich aber vor dem Problem erstmal drücken wollte, hab ich noch was fürs Auge erstellt ;-) eine Night Vision Ansicht. Die Night-Vision ist dabei ein einfacher Post-Effekt, der nach dem DoF und nach dem Bloom-Shader ausgeführt wird. Zusätzlich hab ich noch ne bewegte noise-Textur, die das ganze etwas "video-artiger" erscheinen lässt - jedoch nur seeeehr schwach.

Die Night-Vision hab ich vor allem für den Dieb eingebaut, damit der sich dadurch besser in dunklen Ecken zurechtfinden und verstecken kann. Die Wächter werd ich erstmal nicht mit Night-Visions ausstatten - da könnt ich mir auch gleich den ganzen Aufwand mit den Lichtern sparen ;-). Jedoch wird die Night-Vision nicht nur von Vorteil sein. Ich habe mir z.B. überlegt, ob man Leute mit den Taschenlampen auch blenden kann - was ja in dunklen Umgebungen sehr schnell geht. Falls ich nen Weg finde, wie ich das einbaue, wird der Effekt mit aktiver Night-Vision noch viel schlimmer sein als ohne. Dadurch wäre man als Dieb komplett hilfslos, da man für einen kurzen Augenblick nichts mehr sehen würde.

Technisch wollt ich es folgendermaßen lösen: habe zwei floats - einen für die aktuelle Helligkeit und den anderen für die Licht-Intensität, an die sich das virtuelle Auge des Spielers gewöhnt hat. Liegen beide Werte sehr stark auseinander sieht man entweder alles weiß oder schwarz. Die aktuelle Helligkeit ändert sich sofort, die gewöhnte Intensität passt sich aber nur langsam neuen Lichtverhältnissen an. Was mir jetzt noch probleme bereitet: wie bekomme ich die aktuelle Helligkeit? Wenn da jemand nen guten Tipp hat, wäre ich sehr froh. Nen einfaches glReadPixel an der Bildschirm-Mitte find ich nicht so gut - es könnte sich ja genau dort eine winzige LED befinden, die den Raum fast nicht beleuchtet und man wäre trotzdem geblendet. Ich werd es auf jedenfall erstmal relativ einfach implementieren und schauen, ob es überhaupt sinnvoll ist, das so zu lösen.

Bevor ich es vergesse:
ich hab auch noch nen Video zu der Night-Vision erstellt - zu sehen gibt es das (wie immer) hier

Ich hoffe, es gefällt
Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 14, 2009 18:32 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Sodala, ich mach mal wieder nen Update, da sich relativ viel in den letzten Tagen geändert hat.

Zum Program selber: ich hab meine TechDemo mal von der Steuerung etwas angepasst. Die ganzen Lichter werden jetzt nicht mehr vom Programm bewegt - bis auf das erste. Das wird jetzt wie eine Taschenlampe oder eine Fackel automatisch beim Betrachter mitbewegt. Der Rest ist jetzt komplett statisch. Zudem hab ich die Steuerung jetzt geändert: ich kann jetzt nicht nur das Level drehen, sondern mich auch mit gewöhnlicher Shooter-Manier darin frei bewegen.

Wie ich im Meinungs-Thread schon gesagt habe, hab ich einen Model-Importer eingebaut. Das ganze läuft folgendermaßen ab: ich habe eine abstrakte Klasse, von der ich die Model-Loader ableite. Alle Model-Loader (im Moment nur einer: nen OBJ-Loader) registrieren sich in einer globalen Liste. Wenn ich jetzt ein Model laden will, dann frage ich zuerst jeden Modelloader in der Liste, ob er die Dateiendung verarbeiten kann. Wenn ja, dann erstelle ich eine Klasse des Model-Loaders und Lade dann die Daten. Da meine Engine komplett nur mit Streams arbeitet, könnte ich (wenn ich nen HTTP-Stream einbauen würde), auch Models direkt aus dem Internet laden, ohne dass ich irgendein Loader anpassen müsste.

Der Model-Import geschieht im Moment in 2 Schritten. In nem speziellen Model-Importer importiere ich zuerst das Model und speichere dann die Materials des Models. Diese bearbeite ich dann noch weiter, da ich z.B. noch Shader setzen muss. Im Hauptprogramm importiere ich das Model dann dymamisch ohne die Materials - die hab ich ja schon vorher importiert und werden somit schon vorher ganz normal geladen. Das ganze läuft sehr schnell und auch sehr flexibel: den Importern kann ich noch sagen, ob und wieviel er das Model noch skalieren, drehen und/oder verschieben soll. Natürlich kann ich pro Level beliebig viele Models importieren. Das ganze ist im Moment so weit ausgereift dass ich mir überlege, überhaupt kein Level-Editor zu basteln und mit bereits existierenden (z.B. Blender) einfach die Levels erstelle und diese dann importiere.

Nachdem ich dann ein Model mit einer relativ hohen Polygon-Zahl gefunden und geladen hatte, war die Performance nicht all zu gut. Ich hatte mit 2 Spot-Lights ca. 10 bis 15 FPS - mit einem Point-Light hatte ich ca. 7 FPS. Da hab ich mich nun endlich hingesetzt und mal nen Octree-Render-Pfad eingebaut. Somit zeichne ich jetzt wirklich nur die Sachen, die man sehen kann und ich zeiche auch nur die Lichter, die sichtbar sind. Jetzt kann ich das wirklich große Model trotzdem schnell zeichnen (natürlich nur, wenn ich nicht alles sehe). Der Octree hat noch keine Potential Visibility Sets, die ich aber noch einbauen werde. Damit ist es möglich zu sagen, welche Nodes von einem Node aus sichtbar sind. Somit kann ich dann Sachen beim Zeichnen weglassen, die sich hinter einer Wand befinden. Jedoch wird das noch ne Weile dauern.

Das Erstellen des Octrees ist noch nicht so wirklich optimiert. Für das Model mit 400.000 Vertice braucht der Octree-Generator ca. 3 bis 5 Minuten (hab nicht genau drauf geachtet). Jedoch ist das wirklich nur sehr unterste Priorität, da das ja nur ein mal pro Level berechnet wird.

Wer sich das Model mal anschauen will, kann sich ja mal das neuste Video anschauen (ist schon 4 Tage alt :oops:). Den Video gibt es hier

Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 28, 2009 17:13 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Sodala, ich meld mich mal wieder.

In den letzten Wochen bin ich mit dem Renderer der Engine ganz gut vorran gekommen. Wie im letzten Post schon gesagt, wollte ich für den Octree noch ein PVS einbauen - gesagt - getan ;-). Das Erstellen dieses Potential Visibility Sets dauert relativ lange und ist noch nicht ganz perfekt - jedoch ist das gerade für vielschichte Levels eine wichtige Erweiterung für den Octree.

Im PVS wird jeder Octree-Node gespeichert, der von einem bestimmten Node sichtbar ist (egal aus welcher Perspektive). Diese Liste wird dann mit dem Frustum-Check verknüpft. Somit werden alle Würfel, die nicht im View-Frustum und nicht verdeckt sind, nicht gezeichnet.
Alle Lichter verwenden den PVS ebenfalls: zuerst schaue ich, welches Licht einen vom Betrachter aus sichtbaren Würfel sehen. Falls das Licht keinen Node sieht, welches der Betrachter sehen kann, wird das Licht in diesem Frame nicht beachtet. Somit spare ich mir viel Render-Arbeit.
Der PVS wird mit ARB_Occlusion_Query berechnet. Ich zeichne zuerst das Level aus einer bestimmten Position in einem Octree-Node. Dann zeichne ich einfach normale Würfel um jeden anderen Octree-Node. Danach frage ich die Grafikkarte, wieviele Pixel von dem gezeichneten Node den Tiefentest bestanden haben und somit sichtbar sind. Wenn das mehr als 0 Pixel waren, ist der Würfel von der aktuellen Position aus sichtbar. Das mache ich natürlich nur einmal, da das Erstellen doch sehr lange dauert.

Weiterhin hab ich mich noch etwas mit meinen Shadern auseinander gesetzt und diese etwas verbessert. So hab ich jetzt z.B. nen etwas besseren Depth of Field Shader und nen guten Soft-Shadow Shader drinnen. Die Soft-Shadows erstelle ich per "Percentage-Closer Filtering".
Zudem hab ich jetzt noch eine Art "Shader-Qualitäts-Einstellung" eingebaut. Je nach dem, welche Shader-Qualität ich haben will, füge ich in die Shader-Sources bestimmte #define's hinzu. Für die simpelste Qualität z.B. #define GE_QUALITY_1, für die höchste #define GE_QUALITY_5. Das hab ich gleich versuchsweise in meinen normalen Render-Shader eingebaut und kann somit die Schattenqualität einstellen. Einen Vergleich hab ich in den Anhang gesetzt.

Damit ihr euch mein aktuelles Programm mal anschauen könnt, hab ich noch eine Tech-Demo erstellt - diesmal mit einer etwas besseren Steuerung. Dafür sind die Anforderungen an die Grafikkarte sehr hoch, da ich ein sehr polygon-reiches Model hinzugefügt habe. Die Steuerung könnt ihr im Programm anschauen, indem ihr einfach H drückt.
Das Programm könnt ihr mit der Datei app.config im Ordner config selbst einstellen - ist zwar nicht viel im Moment, aber wenigstens etwas.

Benutzung auf eigene Gefahr
Den Download der Tech-Demo findet ihr hier (ca. 4 MB)

PS: ich hoffe, das Logo beim Programmstart gefällt euch ;-)


Dateianhänge:
Dateikommentar: Mit Shadow-Filter
ShadowMap - PCF.png [195.44 KiB]
43-mal heruntergeladen
Dateikommentar: Ohne Shadow-Filter
ShadowMap - no filter.png [182.72 KiB]
36-mal heruntergeladen

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com
Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Jul 04, 2009 00:21 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Zur späten Stunde noch ein kurzes Update:

wie ich bereits im Kommentar-Thread gesagt habe, habe ich den Renderpfad auf HDR umgestellt. Das hab ich hauptsächlich deswegen gemacht, da der "Blenden" Effekt bei plötzlichem stärkeren Licht nicht so wirklich das Gelbe vom Ei war. Jetzt ist es so, dass man nicht mehr vom Licht so sehr geblendet wird, jedoch werden Details erst sichtbar, sobald sich das virtuelle Auge an die Helligkeit gewöhnt hat.

Ich hab dazu mal zwei Videos erstellt. Beim erstes ist das Level das gleiche wie in der Tech-Demo. Das zweite hab ich mit einem Model gemacht, was ich ebenfalls im Internet gefunden habe und schon sehr gut das eigendliche Design-Ziel darstellt.

Die Videos hab ich hier verlinkt.

Grüße und gute Nacht

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jul 21, 2009 21:27 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Lange ist her seit dem letzten Update :oops: aber es gab in letzter Zeit nicht viel zu sehen.

Erstmal vielen Dank an alle für den Award - der ist wirklich ein sehr großer Motivationsschub :-) :-)

Hier kommt mal der aktuelle Stand:
Aktuell arbeite ich an einem Editor, mit dem ich meine Levels erstellen und bearbeiten will. Der aktuelle Editor ist die dritte Version, da ich bei den anderen zwei sehr große Schnitzer drinnen hatte. Aber bisher bin ich mit dem Ergebnis sehr zufrieden.

Der Grundlegende Aufbau vom Editor ist wie folgt:
Grundlage ist ein einfaches Object - TGELObject (T Gael Level - ...). Dieses Objekt kann so viele Child-Objekte haben, wie ich will. Diese Child-Objekte sind wieder vom Typ TGELObject. Somit hab ich schonmal einen Objektbaum.

Jedes Objekt kann beliebig viele Vertice haben, die jedoch kein Primitive ergeben müssen (z.B. einen Würfel). Die Objekte werden mit einem Primitive-Creator gefüllt, der dann einfach die Vertice z.B. für einen Würfel in das Objekt schreibt. Bisher unterstützt der Editor Dreiecke, Vierecke, Würfel und Kreise. Zudem können alle eingebauten Model-Importer auch Objekte erstellen. Da ich eine Abstrakte Klasse für den Model-Importer habe, brauche ich nur einen Creator für den Editor - intern wird der richtige Importer für das ausgewählte Model automatisch gewählt.

Jedes Objekt kann nur ein Material haben. Wenn ich jetzt einen Würfel erstellen will, welches für jede Seite ein anderes Material haben will, ist das aber auch kein Problem (ist jedoch noch nicht eingebaut): Ich will folgendes machen: man kann später in einem speziellen Modus einzelne Dreiecke von einem Objekt auswählen und diese in ein neues Objekt verschieben. Dieses neue Objekt kann dann das gewünschte Material bekommen.

Der Editor ist als WYSIWYG-Editor ausgelegt - alle Änderungen sind sofort sichtbar und werden auch so dargestellt, wie der finale Renderer das Level zeichnen würde. Alle Lichter werden auch mit Schatten dargestellt. Das kann man am Parallax-Shader des großen Würfels in der Mitte erkennen und an der Schattenanpassung am äußeren Würfel. Der Renderer im Editor ist der gleiche, wie im Hauptprogramm. Nur die Post-Scene-Effekte (wie der DoF) und HDR+Blooming sind deaktiviert.

Hier mal zwei Screenshots (zum Vergrößern draufklicken)
Bild Bild

Zum Manipulieren der Objekte habe ich ein Control, welches drei Modi besitzt: verschieben, rotieren und skalieren. Zum ausführen der jeweiligen Aktion muss ich einfach nur mit der Maus auf die Achsen klicken und dann die Maus bewegen.

Wie gesagt, der Editor ist noch sehr am Anfang - ich kann noch keine Levels speichern geschweige denn Laden. Aber ein paar Grundlagen (Materials erstellen/bearbeiten, Texturen hinzufügen, ...) ist schon fertig.

An der Engine selber hab ich auch schon ein wenig weiter gemacht - hauptsächlich Bugfixes und Erweiterungen für den Editor. Jedoch habe ich bereits ein erstes Netzwerk-Interface und einen Protocol-Controller geschrieben. Zwar unterstüzt das interface TCP und UDP - jedoch hab ich bisher nur TCP getestet. Der Controller ist dabei die Schnittstelle zwischen dem Netzwerk-Interface und den einzelnen Commands. Er sorgt dafür, dass jeder Command vollständig vorhanden ist und reicht die Daten an die einzelnen Commands weiter.

So, das wars für erste. Zwar dauert das mit dem Editor etwas länger als geplant, jedoch bin ich noch gut im geplanten Zeitraum (aktuell GEPLANTER Release: in 1,5 bis 2 Jahren ;-) bzw. when it's done ;-))

Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jul 30, 2009 20:31 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Hallo,

wie im letzten Post schon gesagt werkel ich gerade an einem Editor rum. Mittlerweile hab ich die Grundprimitiven fertig - also Dreieck, Viereck, Würfel, Kreis, Kugel, Zylinder, Pyramide (über Zylinder), und Torus.

Zusätzlich hab ich noch nen Stairs-Creator als simples Model eingebaut. Damit kann man schon ganz schön viel machen ;-). Um euch das mal kurz zu zeigen, hab ich mal wieder nen Video erstellt. Dort zeig ich, wie ich einzelne Primitive bewege, skaliere, verschiebe und erstelle. Außerdem könnt ihr mal das Interface des Editors sehen - ist zwar nicht viel - jedoch steckt die meiste Arbeit bisher dahinter.

Auf der linken seite seht ihr oben den aktuellen Objektbaum und drunter ist das Properties-Feld. Für die Properties benutz ich das JvInspector-Control von den Jedi's.
Das Level, was ihr in dem Video seht (naja - sagen wir eher den Raum) hab ich in ca. 30 Minuten erstellt. Die Handauflage der Geländer und die senkrechten Geländer-Stangen sind alles Zylinder, die drei waagerechten Verbindungsstangen sind Würfel. Insgesamt nichts wirklich beeindruckendes, jedoch bin ich schon mal sehr stolz drauf :D

Das Video hab ich auf meiner Seite hier verlinkt.

Das für mich im Moment größte Problem ist aber ein anderes: Ich würd gerne dreiecksbasierte CSG (Constructive Solid Geometrie) einbauen - jedoch fehlt mir irgendwie total der Ansatz. Ich hab mir zwar schon ein paar Sachen überlegt, jedoch nach einmal drüber schlafen wieder verworfen, da ich was wichtiges vergessen hatte. Irgendwie dümpel ich damit so ein wenig rum, da mir nichts einfällt. Ich wollt jetzt deswegen erstmal keinen neuen Thread aufmachen, da ich noch nicht genug gesucht habe - außerdem würd ich es gerne nur einbauen (-> Copy & Paste ), da mir das Thema nicht so liegt und ich das Gefühl habe, zuviel Zeit damit zu verlieren. Falls sich jemand damit auskennt kann er ja mal ein paar gute Links zum Thema posten - ich würd mich auf jedenfall freuen

Grüße

EDIT
Ich hab heut noch ein wenig weiter gemacht: hier mal die Editor - Screenshots von heute: das komplette Level ist mir dem aktuellen Leveleditor erstellt.

(zum Vergrößern drauf klicken) (alles Realtime):

Bild Bild Bild Bild Bild Bild

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Aug 10, 2009 16:40 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Bevor ich morgen erstmal 2 Wochen ohne Laptop und co. in den Urlaub fahre (muss halt auch mal sein), wollt ich nochmal den aktuellen Status präsentieren.

Ich habe nun versucht, einzelne Map-Abschnitte, die mir so durch den Kopf gewandert sind, im Editor zu erstellen. Das geht wirklich ganz gut - ein paar kleinere Sachen sind zwar noch nicht so ganz in Ordnung, aber ich hatte keine größeren Probleme die Sachen darzustellen, wie ich sie wollte (im Kommentar-Thread hab ich ja schon zwei Screenshots gezeigt).

Ich hab mich auch mal wieder hingesetzt und mir meine Shader angeschaut und war überhaupt nicht zufrieden. Die werd ich mir nach dem Urlaub erstmal wieder vornehmen - vielleicht kann ich ja noch ein paar Sachen optimieren - mal schauen. Aber eins hab ich noch eingebaut - Specular-Licht. Dadurch konnte ich endlich etwas schöneren Mamor darstellen. Zwar ist es noch etwas übertrieben - aber es geht schon in die richtige Richtung - muss dafür ja nur ein/zwei Properties im Editor ändern.

Damit ihr mal wieder nen Video bekommt, hab ich noch mal eins für euch erstellt. Zu finden gibt es das Video hier. Das Specular-Light könnt ihr an den Mamorsäulen sowie am Boden sehen.

Natürlich könnt ihr weiterhin Kommentare posten, vielleicht komm ich ja in den zwei Wochen mal kurz dazu zu antworten 8).

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Sep 01, 2009 20:39 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Jetzt bin ich wieder zurück ausm Urlaub - schön braun gebrannt (also nicht nur Kellerbräune ;-)) und voller Tatendrang.

Wie ich im letzten Post geschrieben habe, wollt ich nach dem Urlaub mal die Shader überarbeiten - aber das hab ich jetzt erstmal gelassen, da mir im Urlaub ein paar Ideen zu einem anderen Teil der Engine eingefallen sind - es geht um die Script-Sprache.

Für meine letzte Engine hab ich ja bereits eine Script-Sprache geschrieben - jedoch war diese viel zu langsam und nicht wirklich erweiterbar. Daher hab ich schon vor längerer Zeit eine neue Script-Sprache angefangen, die ich dann in der Engine benutzen werde - und eben an dieser Script-Sprache hab ich mal wieder weiter gemacht.

Die neue Script-Sprache ist von Anfang an neu geschrieben und viel übersichtlicher aufgebaut. Auch hab ich den kompletten Code in viel mehr in einzelne Units aufgesplittet. Somit hat die neue Script-Sprache jetzt schon ca. 30 Units.

Das wirklich neue an dieser Script-Sprache ist, dass sie nicht mehr Pascal als Dialekt hat, sondern Object Pascal - und genau das (objekt-orientierte) hab ich in den letzten Tagen erfolgreich hinbekommen.

Wie muss man sich das jetzt vorstellen? - Ganz einfach. Ich kann, wie in Delphi (oder in FreePascal) eigene Klassen im Script definieren. Dabei können diese Klassen natürlich auch Variablen, Properties, Methoden, einen Constructor und einen Destructor haben. Die Methoden kann ich überladen und überschreiben, so dass ich auch wirklich von Klassen ableiten kann - und das alles in der Script-Sprache. Hier mal ein kleines Script:

Code:
  1. program Project1;
  2.  
  3. type
  4.   TTest1 = class(TObject)
  5.   public
  6.     constructor Create; override;
  7.     procedure Test1; virtual;
  8.   end;
  9.  
  10.   TTest2 = class(TTest1)
  11.   public
  12.     constructor Create; override;
  13.     procedure Test1; override;
  14.   end;
  15.  
  16. { TTest1 }
  17.  
  18. constructor TTest1.Create;
  19. begin                  
  20.   inherited;                
  21.   Console.WriteLine('TTest1.Create');
  22. end;
  23.  
  24. procedure TTest1.Test1;
  25. begin            
  26.   Console.WriteLine('TTest1.Test1');
  27. end;
  28.  
  29. { TTest2 }
  30.  
  31. constructor TTest2.Create;
  32. begin                          
  33.   inherited;
  34.   Console.WriteLine('TTest2.Create');
  35. end;
  36.  
  37. procedure TTest2.Test1;
  38. begin          
  39.   inherited;                      
  40.   Console.WriteLine('TTest2.Test1');
  41. end;
  42.  
  43. { Main }
  44.  
  45. var p: TTest1; // Der Basistyp
  46. begin            
  47.   p := TTest2.Create; // eine abgeleitete Variante davon
  48.   try          
  49.     p.Test1;  
  50.   finally
  51.     p.Free;
  52.   end;      
  53. end.
  54.  


Die Ausgabe in der Console schaut dann wie folgt aus

Code:
  1. TTest1.Create
  2. TTest2.Create
  3. TTest1.Test1
  4. TTest2.Test1


Wozu jetzt eine OOP-Script-Sprache?
Das kann auch schnell erklärt werden: ich will meine Engine so aufbauen, dass diese nur Methoden und Libraries zur Verfügung stellt. Diese Libraries werden dann ebenfalls der Script-Engine zur Verfügung gestellt. Zusätzlich definiere ich ein paar abstrakte Klassen, die dann im Script implementiert werden müssen. Dann wird die komplette Spiel-Logik komplett im Script und nicht fest ins Programm kompiliert sein.

Hier mal ein Beispiel, wie ich mir das gedacht habe: zuerst mal die fest definierte abstrakte Klasse in der Script-Engine:
Code:
  1. TGEGame = class(TGEScriptObject)
  2. public
  3.   procedure Initialize; virtual; abstract;
  4.   procedure MainLoop; virtual; abstract;
  5.   procedure Finalize; virtual; abstract;
  6. end;


Jetzt will einen einfachen Ego-Shooter mit der Engine schreiben. Also erstelle ich eine Klasse in der Script-Engine, die folgendermaßen aussehen kann:
Code:
  1. TGESimpleShooter = class(TGEGame)
  2. public
  3.   procedure Initialize; override;
  4.   procedure MainLoop; override;
  5.   procedure Finalize; override;
  6. end;


Die komplette Spiellogik wird dann in dieser Klasse als Script drinnen sein. Natürlich kann man auch noch andere Klassen erstellen. - z.B. verschiedene Trigger, die entwerder per Knopfdruck oder per Zone aktiviert werden (z.B. Actor läuft in Zone -> Licht geht an). Da man von der Script-Sprache kompletten Zugriff auf die Engine haben wird, ist es dann fast genau so, als ob ich die Spiellogik direkt in die exe schreiben würde - jedenfalls hab ich das so geplant.

Im Programm kann dann per Config-File eingestellt werden, welche Klasse für die Spiel-Mechanik geladen werden soll (in diesem Fall "TGESimpleShooter"). Ist die Klasse erstellt, schaut das Hauptprogramm (also die exe) nur noch so aus:
Code:
  1. program Gael;
  2.  
  3. var Engine    : TGEEngine;
  4.     pObject   : Pointer;
  5.     pInit     : Pointer;
  6.     pMainLoop : Pointer;
  7.     pDone     : Pointer;
  8. begin
  9.   Engine := TGEEngine.Create;
  10.   try
  11.     Engine.Initialize(ParamStr(0)); // Ordner initialisieren, Config auslesen, Context erstellen, usw....
  12.     pObject := Engine.Script.CreateClass(Engine.Script.CodeAccess.FindClass(Engine.Config.StartupClass)); // Script-Klasse erstellen
  13.     try
  14.       // Script-Methoden suchen
  15.       pInit := Engine.Script.CodeAccess.FindMethod('TGEGame.Initialization');
  16.       pMainLoop := Engine.Script.CodeAccess.FindMethod('TGEGame.MainLoop');
  17.       pDone := Engine.Script.CodeAccess.FindMethod('TGEGame.Finalization');
  18.  
  19.       // "Main Loop"
  20.       Engine.Script.Call(pInit, []);
  21.       while not Engine.Script.Done do
  22.         Engine.Script.Call(pMainLoop, []);
  23.       Engine.Script.Call(pDone, []);
  24.    
  25.       // Spiel ende <!-- s:-( --><img src=\"{SMILIES_PATH}/icon_sad.gif\" alt=\":-(\" title=\"Sad\" /><!-- s:-( -->
  26.     finally
  27.       Engine.Script.FreeClass(pObject);
  28.     end;    
  29.   finally
  30.     Engine.Free;
  31.   end;
  32. end.


Das klingt alles sehr schön, wird aber sehr schwierig werden. Aber wer nicht wagt, der nicht gewinnt ;-).

Das wars erstmal wieder
Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Sep 03, 2009 22:06 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Ich meld mich nochmal kurz.

Ich habe nun die Script-Engine in die Engine eingebaut und bereits die ersten Test-Scripts geschrieben - und ich muss sagen, es funktioniert bisher sehr gut :-).
Um euch zu das mal kurz zu zeigen, hab ich mal wieder ein Video erstellt. Dies habe ich hier verlinkt.

Leider ist die Qualität mehr als bescheiden - liegt leider YouTube :-?.

Aber ich kann ja kurz beschreiben, wie es ungefähr aufgebaut ist:
Rotierenden Lichter
Die beiden rotierenden Lichter sind Child-Elemente von einem Level-Object. Diesem Level-Object kann ich eine Script-Klasse zuweisen. Dabei muss diese Script-Klasse von der abstrakten Script-Klasse "TGERenderObject" abgeleitet sein. Diese Klasse hat die Property "Parent", die auf das eigentliche Objekt im Level verweist. Zusätzlich gibt es eine Methode "Render", die überschrieben werden muss. Die Methode ist dafür da, um z.B. das Objekt zu verschieben oder zu rotieren. In dem Test-Script wird das Objekt (und somit alle Child-Objekte) um die Y-Achse rotiert.

Das eigendliche Objekt in der Engine erzeugt dann die Script-Klasse und führt dann die Methode "Render" automatisch aus.

Flackerndes Licht
Das flackernde Licht ist eine Light-Script. Ein Light-Script muss von der Klasse "TGELightScript" abgeleitet werden. Diese Klasse hat die Methode "Update", die auch wieder überschrieben werden kann. Wie bei dem Basis-Level-Objekt führen die Lichter die Methode "Update" automatisch aus.

Natürlich kann ich eine Script-Klasse mehreren Objekten zuweisen - jedes Objekt bekommt dann seine eigene Instanz und somit seine eigenen Variablen. Natürlich kann ich von den eigenen Script-Klassen wieder ableiten.

Ich hoffe, es gefällt ;-)
Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Sep 09, 2009 19:47 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Ich wollt nochmal nen kurzes Update bringen - ich weiß, die kommen im Moment extrem oft - es geht halt gut voran ;-)

Da die Qualität des letzten Videos leider nicht sehr gut war, hab ich das gleiche Video nochmal neu auf YouTube hochgeladen - jedoch hab ich es vorher direkt in .flv konvertiert - und siehe da: die Qualität ist schon viel besser. Jetzt kann man wenigstens den Script-Quelltext lesen. Hier ist der direkte YouTube-Link des neuen alten Videos.

Ich habe heute noch ein paar Sachen geändert und noch ein Video erstellt - diesmal hab ich mal alles mal in Aktion aufgenommen. Die einzelnen Scripte hab ich übrigens innerhalb von 10 Minuten geschrieben. Hier ist der direkte YouTube-Link zum neuen Video.

Ich hoffe - es gefällt.

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Okt 05, 2009 20:35 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Mär 09, 2005 15:54
Beiträge: 372
Wohnort: München
Programmiersprache: Delphi, C#, FPC
Der letzte Post ist schon eine weile her, daher schreib ich mal wieder den aktuellen Stand auf.

Am Projekt selber hab ich bisher nicht weitergemacht, aber an einem Teilprojekt: der Script-Engine. Wie ich schon geschrieben habe, hab ich die erste Alpha-Version bereits in die Engine integriert, jedoch ist noch einiges zu tun.

Daher hab ich in den letzten Wochen nur an der ScriptEngine weiter gearbeitet. Ich habe vor allem viele Bugs beseitigt, aber auch ein paar nützliche Funktionen hinzugefügt. Zum Beispiel kann ich in der Script-Engine Helper-Klassen für alle Datentypen erstellen. Zudem kann ich bei Records [statische] Variablen und Funktionen hinzufügen. Außerdem unterstützt die ScriptEngine partielle Klassen (wie in .NET) und partielle Units.

Zudem kann ich Script-Funktionen "nativ" aus dem Programm heraus aufrufen (z.B. einem Event direkt ohne Wrapper-Funktion zuweisen). Bald kommen dann noch Funktionspointer in der ScriptEngine für Events und schon sollte man schon einiges in der Script-Engine programmieren können :-).

Die ScriptEngine ist ein ausgelagertes Teilprojekt, bei dem ich auch den Quelltext veröffentliche. Zu finden ist es entweder in der DelphiPraxis oder direkt auf SourceForge.net. Vielleicht kann die ja der ein oder andere verwenden ;-).

Wer noch mehr über die Script-Sprache erfahren will, kann sich meine Dokumentation mal herunterladen und anschauen.

Da die Script-Engine aber langsam fertig wird, werd ich dann langsam Anfangen, die API der Engine in der Script-Engine zur Verfügung zu stellen. Danach wird man dann langsam wirklich in der Lage sein, die ersten Spiele zu realisieren.

Wenn ich zwischendurch mal eine Verschnaufpause brauche, hocke ich mich mit Stift und Papier hin und mache das grobe Design für die erste Map. Was genau das wird bleibt noch ein kleines Geheimnis aber im Moment schauts schon (aufm Papier) nicht schlecht aus ;-)

Grüße

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 50 Beiträge ]  Gehe zu Seite 1, 2, 3, 4  Nächste
Foren-Übersicht » Sonstiges » Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.044s | 19 Queries | GZIP : On ]