16. Februar 2012

Hallo. Heute gibt es mal wieder etwas eher Privates: Es ist interessant, mit welchen Mitteln man seinen PC beschleunigen kann. Der beste Trick besteht natürlich darin, sich einfach einen neuen zu kaufen. Das mache ich normalerweise auch alle drei Jahre. Mein aktueller PC läuft nun im vierten Jahr und er gefällt mir so gut, dass ich mir noch keinen neuen zulegen möchte. Ich kann bisher auch noch alles problemlos zocken, einschließlich Battlefield 3. Das wäre auch gelacht, wenn nicht, denn mit zwei 3-GHz-Kernen, 4 Gig RAM und einer GTX 260 mit zusätzlichen 800 MB steht man auch heute noch ganz gut im Strumpf. Klar, vier oder mehr Kerne sind noch geiler und eine 560 Ti geht einfach viel derber ab; und mehr RAM ist immer geiler. Und ich merke natürlich schon, dass ich nicht mehr die krasseste Grafik einstellen kann; und hin und wieder ruckelt es doch — was aber weniger an der Grafikkarte selbst liegt. Zum Beispiel hat Battlefield 3 die Eigenschaft, fast ständig Unmengen an Stuff nachzuladen (zumindest bei mir). Das führt dann häufig zu einem unflüssigen Spielgeschehen. Das ist schon sehr frustrierend, wenn man über’n Haufen geballert wird, bevor man den eigentlichen Feind überhaupt zu Gesicht bekommt. Oder man möchte nur kurz um die Ecke luken und genau in dem kritischen Moment, als man gerade seine komplette Blöße preisgibt, fängt die Festplatte an zu bollern und man weiß schon, dass man das nicht überstehen wird. Kennt ihr das auch?

Dann kommen jetzt die Tricks ins Spiel, mit denen man doch noch einiges mehr herausholen kann, ohne dreckig zu übertackten oder solche Späße. Ich habe einfach mal meinen PC ausgestaubsaugt und insbesondere die Lüfter vom Staub befreit. Sagenhaft, womit der PC einem diese Aktion dankt: weniger Abstürze, weniger Hänger, geschmeidigere Performance. Ich meine, dieser “Trick” ist nicht neu und eigentlich kennt ihn jeder. Aber mal im Ernst: Wann macht man das denn tatsächlich mal?

Der nächste Trick, der dann gegebenenfalls vielleicht doch etwas Geld kostet, besteht darin, Festplattenspeicher-lastige Spiele und vor allem die Auslagerungsdatei nicht auf klassischen Festplatten (Hard Disk Drives, HDD), sondern auf Solid State Drives (SSD) laufen zu lassen. Zack! Im Fall von Battlefield 3 bedeutet das für mich beispielsweise, dass, erstens, das Spiel nur einige wenige Sekunden braucht, um zu laden, und, zweitens, ich im eigentlichen Spielgeschehen nahezu keine Hänger mehr habe, weil wieder irgendetwas nachgeladen werden muss, was bei Battlefield 3 (zumindest bei mir) fast ununterbrochen geschieht. Die Menge, die nachgeladen werden muss, hat sich jetzt natürlich nicht geändert; aber ich bekomme einfach nichts mehr davon mit. Ich bin begeistert! Wenn ich jetzt einmal abgeknallt werde, liegt es an meiner Unfähigkeit und nicht daran, dass wieder mal im denkbar ungünstigsten Moment eine Unmenge an Stuff nachgeladen wird. So macht das Zocken Spaß!

Die hier aufgelisteten “Tricks” erheben keinen Anspruch auf Vollständigkeit. Nein, nein. Sie stellen nur die Maßnahmen dar, die ich erfolgreich und zufrieden angewendet habe, um mir ein nahezu frustfreies Battlefield-3-Zocken zu ermöglichen. Tschau.

Feuer mit Fleisch

28. Juli 2011

Ich habe Urlaub und weil Cyber und Elsa so gerne Feuer mit Fleisch essen, wollte ich den beiden zu Ehren heute das schärfste Feuer mit Fleisch für mich kochen, dass ich je zustande gebracht habe. Obwohl ich bestimmt viermal mehr scharfes Zeug drangetan habe als sonst, war es witzigerweise gar nicht wirklich schärfer. Ganz offensichtlich hatte ich schon immer die kritische Menge erreicht oder spätestens jetzt überschritten, ab der es einfach nicht mehr schärfer wird. Das bedeutet, dass ich schon immer das schärfste Feuer mit Fleisch gekocht habe, das es je gegeben hat und je geben wird. Das schärfste! Schon immer! Versteht ihr? Wahnsinn!

Kleiner Entwicklungsrückblick

15. November 2010

Manchmal finde ich mich selbst etwas frustriert, wenn ich darüber nachdenke, wie lange ich bereits an dem Projekt Cyber E-Razor rockt die Galaxis arbeite und wie lange ich vermutlich noch daran arbeiten werde. Nämlich sehr lange. Das liegt vor allem an zwei Gründen, da mache ich mir nix vor: Zum Einen ist das halt einfach extrem aufwändig, so ein Projekt umzusetzen — und das auch noch alleine. “Normalerweise” entwickeln hunderte von Menschen über viele Jahre an einem Spiel und bringen einen Arbeitsaufwand ein, den ich alleine in mein Projekt stecke. Das führt uns zu Punkt zwei, denn zum Anderen ist es so, dass ich nicht nur das eigentliche Spiel Cyber E-Razor rockt die Galaxis erfinde und erbaue, sondern alles auf dem Weg dorthin selbst programmiere. In den Augen einiger Leute dürfte das relativ dämlich wirken. Aber bei diesem Hobbyprojekt geht es — wie schon an der einen oder anderen Stelle angesprochen — ja gar nicht (nur) um das fertige Produkt, was am Ende (hoffentlich) dabei rauskommt. Sondern bei diesem Hobbyprojekt ist der Weg das eigentliche Ziel. Und wenn man sich diesen Weg mal vor Augen hält, ist der tatsächlich gar nicht so unproduktiv. Im Gegenteil: Eigentlich habe ich im Rahmen der Entwicklung von Cyber E-Razor rockt die Galaxis und der zu Grunde liegenden “Engine” viele kleine bis mittelgroße oder sogar große (Teil-)Projekte erarbeitet und teilweise bereits fertig abgeschlossen. Mit Frust mischt sich dann vielleicht doch ein wenig Stolz, wenn ich mir die folgende Liste anschaue:

  • Eine umfangreiche Mathebibliothek für die Rechnung mit und Transformation von Vektoren und Matrizen;
  • Eine eigene Programmiersprache inklusive Schnittstelle zu C++;
  • Eine Physik-Engine für die Interaktion von Starrkörpern;
  • Ein DirectX-Wrapper-Framework mit Ressourcenverwaltung und Zusatzfunktionalität;
  • Ein XML-System zum Lesen, Schreiben, Verarbeiten und Generieren von XML-Bäumen;
  • Ein umfangreiches konfigurierbares GUI-System.

Im Moment bin ich noch auf der Suche nach einem “neuen” Werkzeug zum Zählen der Code-Zeilen etc. Denn das vorherige Visual-Studio-Addin kann ich leider bis auf Weiteres nicht mehr benutzen. Es müssten mittlerweile ca. 150.000 Zeilen (gesamt) sein. Bis bald.

Bald geht es endlich mit dem World-Editor weiter…

24. September 2010

So, Freunde! Es ist zwar wahr, dass hier nicht gerade viel passiert und dies leider auch ein wenig die tatsächliche Entwicklung widerspiegelt, die im Hintergrund stattfindet. Jedoch bin ich nicht ganz untätig. Das geplante und bereits schon einmal angesprochene XML-System ist fertig und bereits integriert: GUI-Elemente müssen jetzt nicht immer zwangsläufig im eigentlichen Code programmiert werden, sondern lassen sich nun über eine Spezifikation in XML definieren. Lediglich für die Logik muss dann noch ausführbarer Programmcode her, der aber gerne alternativ zu C++ auch in Ernie-Script verfasst werden kann.

Ansonsten beschäftige ich mich gerade mit einer kleinen Zusatzkomponente, die es unterstützt, mehrere kleinere Grafikdateien zu laden und diese möglichst “platzsparend angeordnet” in eine große Textur zu packen. Den Grund hierfür erkläre ich euch natürlich: Fakt ist, dass ein ständiger Wechsel des “States” der Grafikkarte enormen negativen Einfluss auf die Performance nimmt. Das bedeutet, je seltener der Zustand der Grafikkarte geändert wird — z.B. durch das Wechseln der aktuellen Textur oder Setzen von Shader-Optionen —, desto schneller läuft das gesamte Spiel. Also bietet es sich an, häufig verwendete Pixelgrafiken gebündelt in eine Textur bzw. ein paar wenige Texturen zu packen, weil somit die aktuell gesetzte Textur nicht unbedingt gewechelt werden muss, wenn verschiedene Grafiken dargestellt werden sollen. Gut, gar kein Problem: Ich nehme mir ein Bildbearbeitungsprogramm und klatsche die Grafiken einfach neben- und untereinander in diese Textur in Form einer größeren Pixelgrafik. Blöd wird es erst, wenn plötzlich unvorhergesehen viele neue Grafiken hinzukommen. Jedesmal muss die Textur manuell bearbeitet oder vielleicht sogar eine weitere Textur angelegt werden. Das muss ja nicht nur über ein beliebiges Bildbearbeitungsprogramm mühselig aktuell gehalten werden, sondern entsprechende Texturen und die Koordinaten der einzelnen Bilderchen innerhalb der Texturen müssen im Programmcode gepflegt und verwaltet werden. Der Trick ist also, dies alles zu automatisieren.

Insbesondere für den World-Editor, der ja seit ca. einem Jahr die eigentliche Hauptbaustelle darstellt, werden viele kleine Bilderchen benötigt, die die verschiedensten Bearbeitungs- und Einstellungsmöglichkeiten repräsentieren — vergleichbar mit den Toolbars und Shortcut-Leisten üblicher Computerprogramme, wie sie wohl so gut wie jeder kennt. Wenn es jetzt bald losgeht, dass ich hier zack-auf-zack neue Features dem World-Editor hinzufügen werde, dann muss ich mich so nicht mehr um eine geeignete Organisation der kleinen Grafiken kümmern. Das passiert alles automatisch. Die Grafiken bleiben dann sogar in ihren Originaldateien erhalten und sind leicht austauschbar und vor allem erweiterbar.

Hierfür muss ich jetzt noch ein paar Zeilen Code schreiben. Ganz trivial ist die Lösung des Problems übrigens nicht. Das Stichwort hierzu ist “Bin-Packing” bzw. “2D-Bin-Packing”, wofür es eine überschaubare Anzahl an ganz vernünftigen Ansätzen, aber leider keine “Killer-Lösung” gibt. Das Problem ist nämlich NP-hart und selbst die Branchen, in denen die Kohle steckt, haben mit dem Finden einer jeweils geeigneten Lösung zu kämpfen — z.B. um ein möglichst optimales Design eines Mikrochips zu realisieren oder einen LKW möglichst “geeignet” zu beladen, wofür jeweils Bin-Packing-Algorithmen angewendet werden. Ich bediene mich jedoch einer relativ einfachen Variante des 2D-Bin-Packings. Entsprechende Funktionalität kann ich ja bei Bedarf später noch optimieren.

TIGHT GANG!!

Aktueller Status

01. März 2010

Ja, es ist schlimm, es ist schlimm! Es ist sehr schlimm! Aber ich komme im Moment einfach nur sehr selten dazu, überhaupt am Projekt weiterzuarbeiten. Und das obwohl ich eigentlich gehofft hatte, die Wintermonate verstärkt hierfür nutzen zu können. Schade. Bevor ich am World-Editor weiterbastle, muss ich noch das GUI-System ein wenig aufpolieren. Ansonsten würde ich mich tot programmieren, wenn es um den Bau der einzelnen Fenster für die verschiedenen Einstellungen etc. geht. Hierfür habe ich nun einen kleinen Entwicklungsschritt zwischengeschoben: Ich erstelle gerade ein kleines System zur Behandlung von XML-Dateien bzw. von XML-Bäumen generell. Diese sollen dann nämlich der Spezifikation von GUI-Komponenten dienen, was eine enorme Erleichterung bei der Verwaltung dieser bedeuten dürfte. Denn der Programmierer (ich) muss sich dann nicht mehr um die Speicherverwaltung der Objekte, Verschachtelung verschiedener GUI-Elemente, korrekte Positionierung und so weiter kümmern. Das steht dann einfach nur alles in einer übersichtlichen XML-Datei, fertig. Die konkrete Logik hinter den GUI-Elementen (Buttons, Drop-Down-Menüs, etc.) muss dann natürlich noch programmiert werden, das ist klar. Bis die Tage.

Beleuchtungsmodell

04. Dezember 2009

So Freunde, heute gibt es mal wieder einen eher technisch-konzeptionellen Beitrag. Ich habe mir in den Träumen einiger Nächte Ansätze zum Beleuchtungsmodell überlegt. Ich könnte natürlich auch auf gängige Standardmodelle zur Beleuchtung der Szene zurückgreifen, jedoch bringen diese neben ihren Vorteilen auch individuelle Nachteile mit sich und wären vor allem viel zu komplex für mein Vorhaben. Nicht, dass ich diese Komplexität nicht zu meistern wüsste, aber es muss ja beispielsweise gar keine komplexe 3D-Szene beleuchtet werden. Die Struktur der Szene bleibt ja größtenteils zweidimensional, auch wenn einige der Objekte auf 3D-Modellen basieren.

Da bietet es sich ja vielleicht an, auf ein laufzeitlastiges Standardverfahren zur “Per-Objekt-Beleuchtung” zu verzichten, bei der jedes Objekt pro beeinflussender Lichtquelle gerendert werden müsste (also mehrmals). Anstelle dessen könnte anhand der Lichtquellen eine “Light-Map” erstellt werden, die dann quasi in einem nachgelagerten Schritt über die ansonsten fertige Szene gelegt wird, um die gesamte Szene auf einen Schlag und nicht Objekt-weise zu beleuchten. Neben der geringeren Laufzeit und Komplexität wäre ein weiterer Vorteil, dass die Anzahl der Lichtquellen theoretisch beliebig groß sein könnte. Dieser Ansatz existiert in ähnlichen Zügen zwar auch bereits und ist unter dem Begriff Deferred Shading bzw. Deffered Lighting bekannt, der in heutigen modernen A-Klasse-Computerspielen häufig Anwendung findet. Jedich ist es erstens eben nicht genau dasselbe und zweitens ist Deferred Shading für 3D-Szenen konzipiert. Es bietet also Möglichkeiten, auf die ich verzichten kann, weil ich sie für meine 2D-Szenen gar nicht benötige. An sich ist das von mir erarbeitete Konzept ein völlig eigenes, wobei ich mir aber ein paar Ideen bei anderen Beleuchtungstechniken und insbesondere Deferred Shading abgekuckt habe.

Allerdings sind meine Überlegungen noch nicht zu 100% abgeschlossen. So schwanke ich noch zwischen zwei Alternativen zur Mischung der unbeleuchteten Szene mit der Beleuchtung der Lichtquellen. Beide Alternativen erwarten als Input (unter anderem) die unbeleuchtete aber ansonsten fertige Szene in einer Textur. Dann könnte ich zum Einen für jede Lichtquelle die Szene-Textur mit den jeweiligen Lichteigenschaften mischen und in den eigentlichen Grafikspeicher schreiben, indem ich die so berechneten Werte sukzessiv (je Lichtquelle) im Grafikspeicher aufsummiere, bis — nach Verarbeitung aller Lichtquellen — die komplette Szene fertig beleuchtet ist. Zum Anderen könnte ich die Lichtquellen und vielmehr deren Lichteinflüsse zunächst — wie bereits weiter oben kurz unter dem Stichwort “Light-Map” angedeutet — in eine weitere, separate Textur zeichnen. Die Textur der unbeleuchteten Szene und die der Light-Map müssten dann nur noch übereinandergelegt und entsprechend gemischt werden. Hat beides seine Vor- und Nachteile, die ich noch nicht komplett gegenüberstellen konnte. Vielleicht probiere ich beides einmal aus oder kombiniere sogar beide Ansätze irgendwie. Schließlich könnte ich ja auch noch zwischen Hintergrund- und Vordergrundbeleuchtung unterscheiden und jeweils andere Beleuchtungstechniken anwenden.

Projektstatistik 11/2009

30. November 2009

So, auch diesen Monat gibt es wieder eine Projektstatistik, schließlich tut sich im Moment ja wieder einiges, obwohl ich nicht die allermeiste Zeit habe. Aber da ich ja nun angefangen bin Spiel-spezifischere Komponenten zu entwickeln, bin ich im Moment sehr motiviert, so dass ich auch zwischendurch mal einfach ein paar Zeilen code. So sind im Laufe des Novembers ca. 6.000 Zeilen hinzugekommen (knapp 2.000 Zeilen reiner Code). Aber seht selbst. Hier ist die aktuelle Tabelle:

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
132.662 56.419 41.473 3.866 30.904 101.758
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Dann habe ich da noch eine erfreuliche Nachricht für euch: Ich wurde schon das eine oder andere Mal gefragt, ob man mal einen Blick auf den Sourcecode werfen dürfe oder auch, ob es sich um ein Open-Source-Projekt handelt. Tja, dazu kann ich bisher ehrlich gesagt selber noch nicht allzu viel sagen, weil ich noch gar nicht weiß, wohin das Projekt noch führt und wie es sich weiterentwickelt. Ausführbaren Code veröffentliche ich also noch nicht, aber ich habe nun eine Dokumentation generieren lassen unter Zuhilfenahme des wirklich tollen Tools Doxygen, wodurch ein sehr guter Überblick über die gesamte Engine und die bisher fertigen bzw. angefangenen Teile des eigentlichen Spiels gegeben wird und die eine Art Dokumentation der API der Engine darstellt. Folgt hierfür einfach diesem Link: Der Code. Viele werden damit wahrscheinlich nix anfangen können, weil es viel zu technisch ist. Aber ich denke, es ist dennoch eine ganz interessante Sache.

Bis die Tage, Freunde.

Geburtstag

27. November 2009

Heute ist ein ganz besonderer Tag, denn Elsa und Cyber haben wieder beide Geburtstag. Cyber spricht ja nicht gerne über sein Alter, aber Elsa wird heute 30. Ein kluger Kopf mit entsprechenden Hintergrundinformationen kann somit auch auf Cybers Alter schließen.

Sehr viel über die beiden zu berichten gibt es darüberhinaus leider nicht, außer natürlich, dass beide enorm auf viele teure Geburtstagsgeschenke abfahren, das ist ganz klar. Aber das wissen ja eh alle.

Mein Geschenk an Elsa und Cyber ist ein Materialeigenschafteneditor. Dieser ist dazu da, um Texturen verschiedener Art mit Farben und Shadern zu kombinieren und diese Kombinationen als “Materialen” zu speichern. Die über den Materialeigenschafteneditor gepflegten Materialien können dann verwendet werden, um sie einzelnen Objekten in der Spielwelt zuzuweisen. Die Texturen der Materialien nehmen dabei verschiedene Rollen ein, z.B. gibt es eine Textur, die die eigentlichen Pixelinformationen des jeweils darzustellenden Objekts enthält. Weitere, optionale Texturen enthalten Informationen über die Oberflächenbeschaffenheit (z.B. in welcher Richtung das Licht reflektiert wird). Die Texturen werden dann mit spezifizierten Farben gemischt, um generische Texturen individuell wiederverwenden zu können. Über die Auswahl einer konkreten Shader-Combo wird angegeben, in welcher Art und Weise die Textur- und Farbinformationen dann letztlich zur Darstellung kombiniert werden.

Es ist mir etwas peinlich, denn der Materialeigenschafteneditor ist noch gar nicht ganz fertig. Aber das merken Elsa und Cyber heute sowieso nicht, hahaha. Also hab ich noch ein wenig Zeit. Aber hier ist ein erster Screenshot:

World-Editor: Erster Screenshot

06. November 2009

Heute gibt es den ersten Screenshot vom World-Editor zu sehen. Besonders umfangreich ist das Werkzeugarsenal des World-Editors bisher noch nicht. Aber das wird es erstens bald sein und zweitens kann man bereits “Blöcke” platzieren, auf denen Cyber dann später rumlaufen und -springen wird, sowie von der Undo/Redo-Funktionalität Gebrauch machen:

Im Screenshot mag der Inhalt des World-Editors noch recht langweilig aussehen. Das liegt daran, dass die “Welt” im World-Editor auf Basis ganz simpler Techniken visualisiert wird und das bislang noch ohne individuelle Texturen der Blöcke. Erstens, weil es wenig sinnvoll ist, den World-Editor mit raffinierten Rendering-Techniken auszustatten, weil, zweitens, durch die schlichte Darstellung der Überblick erhalten bleibt und so der Anwender nicht durch ein völlig überladenes Grafikgeballer in den Wahnsinn getrieben wird. Schließlich müssen die “Welten” ja wie auf einem Reißbrett regelrecht konstruiert werden. Hübsch aussehen müssen sie erst später, wenn Cyber sich in ihnen rumtreiben wird. Dann werden sie mit anderen Techniken und ausgefeilten Raffinessen dargestellt. Das sieht dann richtig geil aus — hoffentlich! Yeah, Baby!

Projektstatistik 10/2009

31. Oktober 2009

Im September hatte ich leider wieder nicht allzu viel Zeit, daher gab es auch keine entsprechende Projektstatistik. Ich habe lediglich hier und da ein paar Bugs beseitigt, wenn ich mal ne halbe Stunde oder so Zeit hatte.

Aber da ich mich diesen Monat nicht so viel um meine Freundin kümmern musste, hatte ich viel Zeit, mich meinem besonderen Kumpel Cyber zu widmen. Dafür muss ich halt wieder näxten Monat dran glauben. Vielleicht kann ich sie aber mit Schmick und Schmunke abspeisen. ;)

Hier ist die aktuelle Tabelle:

Zeilen gesamt Nur Code Nur Kommentare Code mit Kommentaren Leerzeilen Nicht-Leerzeilen
126.601 54.118 39.421 3.651 29.411 97.190
100 % 43 % 31 % 3 % 23 % 77 %

(Zur vorigen Tabelle geht es hier.)

Hui, da hat sich jetzt doch so einiges getan seit August: Ca. 3.000 Codezeilen sind hinzugekommen. Das ist nicht schlecht, finde ich. Die Debug-Konsole ist fertig und mit dem World-Editor bin ich auch bereits angefangen. Ein aktueller Screenshot der geöffneten Debug-Konsole ist hier zu sehen:

Der World-Editor wird natürlich raffiniert sein und auch so Sachen wie Undo/Redo-Funktionalität unterstützen. So ein System muss volles Rohr ausgeklügelt und von vorne bis hinten durchgeplant sein, sonst fliegt einem alles um die Ohren. Der World-Editor wird also ein sehr großer Brocken, den ich zu bewältigen habe. Hier gehe ich aber Schritt für Schritt vor: Zunächst wird man nur einzelne “Blöcke” platzieren können, auf denen Cyber herumlaufen und -springen können soll. Dann kommen Items (einsammelbare Gegenstände) hinzu. Später auch noch Monster und geskriptete Ereignisse (basierend auf Ernie-Script). Das Ganze muss dann noch mit Grafik hinterlegt werden können, was auch keine einfache Sache sein wird. Puh, aber ich freue mich!