You are currently browsing the monthly archive for November, 2008.
Fortschritt:
Viele viele Wartungsarbeiten (Kommentare, Strukturierung, Datei- und Klassennamen geändert).
Das erste Fenster steht jetzt. Der Windows-Callback sowie das Fenster selbst wird nun im Kernel initialisiert, in einer gekapselten CWindow-Klasse (spätere Implementationen für Linux/Mac stehen so offen).
Es gibt nun eine Functor-Utility, die Funktionspointer verwaltet. Im Callback wird nun eine Array aus Functors durchiteriert und somit die Nachrichten abgearbeitet.
Fertig ist nun auch der Input-Task, der bisher Nachrichten zu Maus und Joystick verarbeitet und in Strukturen speichert.
Ein Modelloader ist nun auch fertig, implementiert mit Hilfe der Nehe-Tutorials, jedoch mit ein paar nützlichen Änderungen. Ein Texturmanager ist gerade in Arbeit.
Probleme:
Der Texturmanager sollte nicht an OpenGL gebunden sein, was natürlich Probleme mit de r loadTextures-Funktion gibt. Die Texturen selbst müssen also im Renderer geladen werden, was dann aber Abhängigkeiten zum Texturmannager schafft. Wie ich das Ganze mache muss ich mir diese Woche ausdenken.
ToDo:
Den Texturmanager fertig programmieren, endlich mein erstes Model zeichnen und einen Gamestate-Manager bauen. Falls noch Zeit ist auch noch den Soundmanager programmieren.
Danach (also nächste Woche) geht es dann an mein Hauptthema: Prozedural erzeugtes Gelände 
Auf lange Sicht kommt dann die Kollisionsabfrage und abstrakte Spiel-Objekte (wie Events, Sounds, Physik).
Fortschritt:
Der Kernel ist nun Komplett, und mit ihm Soundtask und Renderer. Zusätzlich gibt es einen GlobalTimer, der die Frames per Second berechnet und die Vergangene Zeit seit dem letzten Frame(was wichtig wird wenn es um Framerate-unabhängige Bewegung geht.)
Der Renderer ist so gekapselt dass man als CRenderingDevice (später) noch alternative Geräte nutzen kann (DirectX steht für das nächste Semester auf dem Plan).
Probleme:
Es gibt noch grundsätzliche Probleme beim Aufbau des Kernel. Es war mir nicht möglich GLUT zu nutzen, da das Toolkit seine Eigene Mainloop nutzt. Die Funktionalität einen Durchlauf nur einmal durchzuführen existiert zwar in FreeGlut, doch traten hier starke (Kompatibilitäts? – ) Probleme auf. Letztendlich muss ich also auf plain Open-GL zurückgreifen. Nun ist die Frage wo ich das Fenster verwalte und die (Windows-) Callbacks mit meinen eigenen Tasks in Einklang bringe ohne den Kernel in Abhängigkeit seiner Tasks zu bringen.
ToDo:
Bis nächste Woche muss das erste Fenster stehen. Der Input-Task muss fertig sein und wenn möglich auch schon die Weltobjekt-Hierarchie stehen (Drawable – Polygon – Mesh – Model). Ausserdem wird es Zeit den Resourcenmanager zu nutzen um eben diese Weltobjekte zu verwalten.
Fortschritt:
Der Settingsmanager ist komplett, es wurden mal alle Compiler-Warnungen weggecoded und die Dokumentation ausgefeilt. Zusätzlich gibt es noch einen Dator, der dazu da ist einfache Datentypen in String zu konvertieren und zurück(std::string ist das Interface des Settingsmanager).
Zu viel mehr hat es aufgrund von Krankheit leider nicht gereicht, aber die meiste “Verwaltungsarbeit” sollte jetzt hinter mir liegen.
Probleme:
Der Settingsmanager ist doch um einiges einfacher geworden als er werden sollte, da ich ein bisschen gehangen war und die Aufgabe nicht in Zeit ausarten lassen wollte. Anstatt den Manager jetzt die Datentyp-Umwandlungen regeln zu lassen und wieder mit Templates um mich zu werfen nutzt der Manager jetzt nur noch std::strings und um die Umwandlung in andere Typen(int, float…) muss sich der User kümmern.
Als kleine Hilfe habe ich Macros geschrieben welche Variablen mit Hilfe des Dators sehr schnell umwandeln umwandeln. Das Ganze schaut dann beispielsweise so aus:
int res = TO(int, someString);
ToDo:
Es geht weiter mit dem Kernel, der die Mainloop enthält und in dem Tasks registriert werden können. Danach geht es endlich an die eigentlichen Tasks, nämlich Sound, Grafik, Netzwerk und Eingabe.
Fortschritt:
Die Resourceklasse ist nun konventionell als Interface konstruiert – Schade, mein Ansatz wäre ziemlich cool gewesen – aber mir rennt die Zeit davon und die Lösung kommt mir nicht. Die Smart-Pointer stehen nun. Aber:
Probleme:
Garbage Collection macht nicht das was ich will: Aus irgendeinem Grund stürzt der Vorgang ab wenn ich meine MemPointer aufräumen will. Die Lösung kommt erst nach einem verlorenen Tag: Meine deadObjects-list ist eine Liste aus Pointern zu IMemObjects. Da kommen auch die SmartPointer rein. Die sind allerdings selbst keine Pointer -sondern liegen auf dem Stack. Kein Wunder also dass ich einen Assert-fail bekomme wenn ich versuche sie mittels delete zu löschen. Die Frage ist nun wie ich erkennen kann ob es sich um eine Stack- oder eine Heap-Variable handelt.
Auf die Lösung bin ich ein bisschen stolz: Ich überlade einfach den ‘new’ Operator und setze ein Flag, nun weiß ich ob ein Objekt auf dem Heap liegt. Das Flag wird beim löschen abgefragt, Objekte auf dem Stack werden NULL gesetzt die restlichen konventionell freigegeben.
ToDo:
Als nächstes ist der Settingsmanager und der Kernel dran. Ausserdem wird meine erste Resource erzeugt, eine Stringtable in die ich einige für Logging und Profiler nötige Strings ablegen kann.
