DGL https://delphigl.com/forum/ |
|
BroodTech Game Engine https://delphigl.com/forum/viewtopic.php?f=13&t=10806 |
Seite 1 von 2 |
Autor: | yunharla [ Mi Apr 03, 2013 09:32 ] | ||
Betreff des Beitrags: | BroodTech Game Engine | ||
BroodTech Game Engine Die BTGE ist eine Grafik Engine und Script Interpreter, speziell für klassische Textspiele. Den Kern bildet dabei eine "Konsole" für die Text Aus- und Eingaben. Diese "Konsolenanwendung" wird in der hauseigenen Scriptsprache geschrieben und diktiert den gesamten Programmablauf. Ueber den "draw"-Befehl kann das Bild auf verschiedene Weise geteilt werden um einen Bereich für grafische Ausgabe zu schaffen. Hierfür koennen Sprites aus Bild- oder 3D-Daten geladen und animiert werden. Bisher Implementiert: - TextScript - Dark Radiant .map loading - Texture loading - Garbage Collection - Midi loading \m/ Noch zu erledigen: - Radiosity Shader (~30%) - Animationen (~20%) - Erweiterung von TextScript (never ending story ) zum Schluss noch ein Screenshot vom CSG System
|
Autor: | yunharla [ Mo Apr 08, 2013 14:45 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Mal ein kleines Update vom Wochenende: Scripte - Neben normaler Texteingabe steht nun auch die "bind {key} {Funktion}" Anweisung zur Verfügung. Auf diese Weise kann man zum Beispiel auch die Cursor Tasten verarbeiten. Renderer - GLSL support - Deferred Sharing wurde eingebaut. - Dazu noch: Ich habe begonnen einen Raytracer zu implementieren. Dieser soll dann die Lichtpunkt für Instant Radiosity erzeugen. - Frame Updates prüfen nun das Datum von verwendeten Dateien, und lädt diese bei Aktualisierungen neu. |
Autor: | yunharla [ Di Apr 16, 2013 19:56 ] | ||
Betreff des Beitrags: | Re: BroodTech Game Engine | ||
Renderer Die Präzision der Texturen vom Render-To-Texture wurde erhöht. Dadurch können nun auch größere Maps gut dargestellt werden. Radiosity wurde rausgeschmissen da es zu crappy aussah und zu viel Performance gefressen hat. Dafür gibts nun hübsche Spotlichter Scripte Der Befehl "move" (Variablen Zuweisung) kann nun auch Terme verarbeiten. Der Befehl "free" (Bildschirm löschen) hat nun noch einen optionalen Boolean Parameter. Über diesen kann man bestimmen ob Grafik oder Text gelöscht wird. Default ist sozusagen "jein", also beides.
|
Autor: | yunharla [ Do Apr 18, 2013 20:21 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
hab gerade einen Compiler für eine einfachere Form der Scripte geschrieben. Dieser übersetzt die C ähnlichen Scripte in die 11 Textbefehle der Engine. Code:
Die Library umfasst derzeit folgende Funktionen: print(string, ... of string) ==>Textausgabe sleep(number) ==>N-Millisekunden warten when(string,string) ==>Eine Regex über den ersten String matchen landscape(string) ==>.map Datei laden und im vertikalen Modus ausgeben portrait(string) ==>.map Datei laden und im horizontalen Modus ausgeben clrscr(); ==>Grafische Ausgabe löschen clrtxt(); ==>Textausgabe löschen string readkey(); ==>Taste auslesen string readln(); ==>Zeile auslesen string read(number); ==>N-Tasten auslesen |
Autor: | yunharla [ Do Mai 16, 2013 17:49 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Die letzten Tage habe ich an einen Nachfolger für eine meiner Bibliotheken, namens libcrpt, gearbeitet. Diese woche ist nun die libcrpt2 fertig geworden und die letzten beiden Tage habe damit verbracht sie in die Engine einzubauen. Dadurch können nun der bisherige Interpreter, Mapparser und die kommenden Scripte endlich vereinheitlich werden. Der Mapparser ist schon erledigt und die Gamescripte umfassen schon jetzt: Schleifen (while,do-while,for,foreach) Branching (if,else,switch,goto,return,label,usw. ) Funktionen Variablen Blockstatments alle möglichen Expressions Storageclass (static, ref, const, extern) Ellipsen Anonyme Funktionen Garbage Collection Fiber Void Bool Integer Float String Delegaten (\m/) Try Catch When (wie bei VB) Fault Throw blah blah blah ... typedefs fehlen leider noch um die wirklich coolen Dinge zu machen naja stellt euch einfach vor C# wäre mehr C als Java.... |
Autor: | yunharla [ Fr Jul 19, 2013 17:13 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
So der Prototyp ist fertig und wird nun nach Objective-C (gnu-runtime) uebertragen. Die letzten Tage habe ich erst einmal massive bug-fixes und refactoring an der general obj-c lib vorgenommen (release kommt) bald und den boehm-gc compeliert (koennen diese Linuxpunker nicht mal nen funktionierenden installer oder sowas schreiben?). Ansonsten ist von der Engine selbst schon ein sehr grosser Teil konvertiert worden. So pi mal Daumen fehlen also nur noch: -die objective-c runtime -der script-interpreter -der 3D-Modus achja und das Projekt wird Open Source (Schnapps Lizenz) |
Autor: | yunharla [ Mi Jul 31, 2013 09:31 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Update Time *wuuuuuush* : Ich habe die letzten Tage damit begonnen die Objective-C Runtime zu implementieren und libobjc rausgeschmissen. Zur Zeit unterstuetzt meine Version die grundlegenden OOP Features wie Klassen, Instanzen und Vererbung (voll geil das man den Kram selbst schreiben kann ). Des Weiteren ist die Speicherverwaltung auch etwas einfacher da alle nicht-konstanten Pointer zusammen mit der Instanz selbst freigegeben werden. Grob gesagt kann man also schon ziehmlich gut damit arbeiten. Fuers erste fehlen noch Kategorien, Protokolle und Properties. Achja bei einen kleinen Experiment hat sich uebrigens eine meiner Vermutungen bestaetigt. Es ist naemlich moeglich waerend der Laufzeit einen Wrapper um jeden Funktionsaufruf (innerhalb der Runtime) zu legen. Ich bin mir noch nicht ganz sicher ob ich das wirklich nutzen will (ellipse nach ellipse halt -.-), aber es koennte zu ein paar wirklich coolen Features fuehren. [edit] achja wer will kann Zugang zum GIT bekommen, einfach PM an mich dann. |
Autor: | yunharla [ Do Sep 19, 2013 12:31 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Ok ich war in letzter Zeit etwas knapp mit Updates (zuviel Mechwarrior ), das soll sich aber nun ändern. Ich habe mich nun doch gegen den Garbage Collector entschieden. Es wäre einfach zuviel Arbeit für ein mehr oder weniger instabiles Feature gewesen. Dafür gibt es aber nun eine einheitliche Speicherverwaltung für Objective C und normale C Typen. Das tolle daran ist dass hier auch gleich alle inneren Referenzen freigegeben werden wenn ein Objekt gelöscht wird, außer wenn der Compiler oder Programmierer diese als Strong-Pointer gekennzeichnet hat. Des Weiteren sind die Funktion "strex" und der "heap" Datentyp nun fertig. "strex" ist für die Evaluation von Ausdrücken in String-Form zuständig und somit der wohl wichtigste Bestandteil des Interpreters. Beim Design habe ich mir folgende Regeln aufgestellt: -Alles ist eine Zahl vom Typ Double,Long Integer oder Boolean. -Alle Nicht-Zahlen und nicht Operatoren sind externe Funktionen die Zahlen zurückgeben. -Alle unären Operatoren stehen vor dem Operanden, also z.B. nur ++i und kein i++ Wenn nun z.B. ein String-Literal kommt dann muss dieser von einer, zuvor registrierten Funktion, in eine Addresse umgewandelt werden. Mindestens genauso wichtig wie die "strex" Funktion ist die Heap Struktur. Diese dient vor allen dazu Addressen zu verwalten und orientiert sich von der Funktionsweise an das gute alte "malloc" und "free". Einen Wrapper wie bei der normalen Speicherverwaltung sollte ohne Probleme möglich sein (man muss ja so oder so Reflection einbauen). |
Autor: | yunharla [ Mi Aug 13, 2014 22:02 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Lange ist es her das sich hier mal was getan hatte. Heute habe ich endlich mal wieder etwas Zeit gefunden. Und wie das so ist fand ich meinen Code mittlerweile eher suboptimal Für die neue "Version" habe ich erst einmal das Projekt in Netbeans, statt DevCpp aufgesetzt. Für Objective-C ist es zwar genauso gut, dafür ist aber der normale C Code wesentlich besser. Und im Gegensatz zu Eclipse muss man keine große Magic zum Verwalten der Code-Dateien machen. Nachdem das in 2h erledigt war (fragt lieber nicht), habe ich nun erst einmal die Runtime ins neue Projekt geholt. Dabei habe ich auch gleich einmal etwas aufgeräumt und so weiter. Morgen nach der Arbeit geht es dann weiter mit der Allgemeinen Basis-Klasse. Dabei will ich vor allen Speicherverwaltung etwas aufpolieren um mehr als brutale dynamische Allokation zu machen. Zum Schluss noch der Quellcode der neuen Runtime: Code:
|
Autor: | yunharla [ Do Aug 14, 2014 22:22 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Ok habe jetzt die "Object"-Klasse fertig. Ich habe mich hier dazu entschieden die Speicherverwaltung komplett von "Außen" abzuwickeln. Sprich die Klasse selbst übernimmt keinerlei Allokation bzw. Deallokation. Stattdessen gibt es nur Funktionen zum (De-)Initialisieren von Puffern. Das hat den großen Vorteil das man zum Beispiel Objekte auf den Stack legen kann. Code:
|
Autor: | yunharla [ Sa Aug 16, 2014 22:02 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
So noch mal kurz ein kleiner Nachtrag zur Speicherverwaltung. Ich habe mich nun dazu entschlossen das ganze Projekt per semi funktionaler Programmierung umzusetzen. Sprich alle Objekte existieren nur solange wie der aktuelle, oder der vorherige bei "return", Stack-Frame einer Funktion: Zuerst habe ich mir einmal die "alloca" Implementierung von "libiberty" angeschaut. Hier wird zuerst ermittelt in welche Richtung sich der Stack ausbreitet. Basierend auf der Stack-Richtung, kann der Allokator jetzt ein Offset zum "root"-Frame ermitteln. Alle vorherigen Allokationen die ein größeres Offset haben können dabei freigegeben werden. Jetzt braucht man nur noch einen Mechanismus der ein Objekt zurückgibt. Dazu muss man einfach die jeweilige "Variablen" zum nächst höheren Offset verschieben. Code:
|
Autor: | yunharla [ Do Aug 28, 2014 07:54 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Gestern Abend habe ich mal wieder mit dem Boehm Garbage Collector rumgespielt. Und siehe da, das Ganze laeuft jetzt stabil (muss wohl ein Fehler im alten Code gewesen sein). Noch dazu ist die Speicherverwaltung fast genauso schnell wie die vorher beschriebene Stack-Variante. Also habe ich kurzer Hand die Stack-Version rausgeschmissen und durch den GC ersetzt. Das Ganze funktioniert jetzt ungefaehr wie folgt: alloc (Klasse, extra_size) -klassen GC-type laden fuer Klasse-Name --Wenn GC-type NULL ist, dann erstelle einen neuen GC-type fuer die Klasse -GC_malloc_typed(Klasse->instance_size,extra_size,GC-type) -memset auf 0 -Klassen Zeiger setzen und fertig |
Autor: | yunharla [ Di Sep 16, 2014 20:16 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Und mal wieder ein paar kleinere Updates: - "Static" Klasse für statische Klassen - Superklassen werden jetzt direkt in der Klasse gespeichert statt nur der Name. - Kategorien [edit] achja ganz vergessen: Code:
|
Autor: | yunharla [ Do Okt 09, 2014 20:50 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Mal wieder ein kleines Update: ich nutze jetzt meinen Mini Collector zur automatischen Speicherbereinigung. Im Gegensatz zur der im Thread geposteten Version hat meine Version einige zusätzliche Features: -Range Checks um zum Beispiel Pointer Arithmetik zu unterstützen. -De- und Initialisierung finden in den Startup Funktionen statt. Also zum Beispiel WinMainCRTStartup. -Finalizer und Class Finalizer -OpenMP Beschleunigung -Der GC-thread wird jetzt über ein "Join" beendet statt nur terminiert -C++,C und Objective-C Support Die Static-Klasse ist jetzt die Module-Klasse. Die Module rufen bei Benutzung automatisch die Load-Methode auf und registrieren Unload als Class-Finalizer. Dies erlaubt mir jetzt relativ entspannt das Fenster-System und dynamische Bibliothek (wie OpenGL) zu laden. Außerdem fliegt die Dynamic Klasse raus, da auch Module Instanzen brauchen (z.B. für GL-Extensions). Außerdem habe ich jetzt meine Objective-C Toolchain auf C11 und 64bit geupdated |
Autor: | yunharla [ Do Dez 18, 2014 00:04 ] |
Betreff des Beitrags: | Re: BroodTech Game Engine |
Hallo Allerseits, Es ist mal wieder Urlaub- /Ferienzeit und das bedeutet natürlich endlich mal wieder Zeit für die wichtigen Dinge im Leben: OpenGL Die letzten Tage habe ich damit verbracht die gesamte Engine mal wieder komplett umzuschreiben. Herausgekommen ist nun eine solide Basis welche die, meiner Meinung nach, besten Elemente der bisherigen Arbeit vereint. Der wohl wichtigste Punkt dabei ist der neue Multithreading Support und damit verbunden der Umstieg von Objective-C auf C++. Oder besser gesagt den Syntax-Sugar durch Objective-C, denn vieles funktioniert tatsächlich noch genauso. Sprich Objekte erhalten Nachrichten anstelle von direkten Funktionsaufrufen. Der Große Unterschied liegt nun darin das ich den kompletten "Aufruf" in einer Queue zwischenspeichere. Der Dispatcher entscheidet dann automatisch, ob die Queue sofort (z.B. wenn eine Rückgabe erwartet wird) oder zu einen späteren Zeitpunkt abgearbeitet wird. Auf diese Weise kann ein Objekt sehr leicht von mehreren Threads benutzt werden ohne das man sich große Gedanken um die Synchronisation machen muss. Würde man ein ähnliches Verhalten mit Objective-C erziehlen wollen müsste man auf Asm zurückgreifen oder den Compiler nachbearbeiten. Beides war für mich keine Option, also Umstieg. Das neue Macro-Design der Engine sieht nun wie folgt aus: Abstract Thread - Send Message - Process Message Main-Thread -Alles Starten und Beenden. -Schleife für den Input und co. ->Events an den Client senden. Client-Thread - Interaktion mit der Szene ->Commands an den Renderer senden. ->Events an den Server senden. Renderer-Thread -Commands verarbeiten Server-Thread -Aufbau / Update der Szene ->Events an den Client senden. GC-Thread -Speicher scannen und aufräumen. |
Seite 1 von 2 | Alle Zeiten sind UTC + 1 Stunde |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |