Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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 )
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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:
// c-style comments
/* .____ .____
* | | ____ | |
* | | / _ \| |
* | |__( <_> ) |___
* |_______ \____/|_______ \
* \/ \/
*/
portrait("throne.map");
//Funktionen
void guessHallo(number counter){
string test = readln();
//if statements
when(counter,"^0")
return;
//blöcke
when(test,"^hallo"){
print("thats right!");
return;
}
print("thats wrong, please try again.");
//operatoren (gibts auch für strings ;))
guessHallo(counter -1);
}
guessHallo(5);
print("press any key to close");
readkey();
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
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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:
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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)
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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).
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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:
/*
BroodTech Objective-C Runtime
Created by Alex 'YunHarla' Schmidt
The following provides a more lightweight version of the objective-c
runtime I found with my MINGW installation. Since I'm no lawyer I just
include the original copyright, I found with it's source. If stuff
needs to be changed or if you have improvements / bug reports you can
send me an email at <info@broodtech.de>
GNU Objective-C Runtime API - Modern API
Copyright (C) 2010 Free Software Foundation, Inc.
Contributed by Nicola Pero <nicola.pero@meta-innovation.com>
This file is part of GCC.
GCC is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 3, or (at your option) any
later version.
GCC is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for more details.
Under Section 7 of GPL version 3, you are granted additional
permissions described in the GCC Runtime Library Exception, version
3.1, as published by the Free Software Foundation.
You should have received a copy of the GNU General Public License and
a copy of the GCC Runtime Library Exception along with this program;
see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
<http://www.gnu.org/licenses/>. */
#include <string.h>
#include <objc/runtime.h>
//the following types and definitions are taken directly from the
//original source... just with typedefs instead of just struct
//because most people i know may mistake it for a local variable otherwise.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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:
@interface Object {
Class class_pointer;
}
//sets the class pointer to the memory pointed to by buffer
//a class pointer must exist in order to class instance methods.
//This function has an overload with bound checks.
+(id) Init:(void*) buffer;
+(id) Init:(void*) buffer With:(size_t) size;
//Returns the objective-c class structure that is used to
//by class pointers in objects
+(Class) Class;
-(Class) Class;
//Returns the number of bytes an object
//requires to store the class pointer and all
//additional instance variables
+(size_t) Size;
-(size_t) Size;
//Checks if the current object is assignable to
//the class pointed to by cls
-(BOOL) IsKindOf:(Class) cls;
//Sets all bytes occupied to Zero. You may
//override this to do additional before the object
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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:
@interface Handle {
@private
Class class_pointer;
}
+(Class) Type;//gets the type of the current class
-(Class) Type;//gets the type of the current object
-(bool) Is:(Class) cls;//checks if the object is assignable to the given class
@end
@interface Dynamic {
}
+(id) Alloc;//allocates and returns an instance of a garbage collected object
-(void) Dispose;//automatically called when the object will be deallocated by the garbage collector or Dealloc method.
-(void) Dealloc;//manually deallocate the current object
@end
@interface Static {
bool isLoaded;
}
+(id) Current;//returns the instance for the static class
-(id) Load;//automatically called by the Current method and when the object is not loaded
-(void) Unload;//automatically called when the process terminates and marks the object as unloaded
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
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.
Mitglieder in diesem Forum: YaCy [Bot] und 3 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.