[Projekt] Mein Stalker-Build

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.

[Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.03.2017, 00:32

S.T.A.L.K.E.R. – Shadow of Chernobyl war eine riesen Enttäuschung. Nichtsdestotrotz habe ich mich in die Stimmung verliebt, und auch elf Jahre nach Release mache ich sporadische Spaziergänge durch die apokalyptische Landschaft. Die entspannen mich irgendwie.

Was mich aber nicht entspannt, sind Bugs – das weiß jeder, der den Jammer-Thread verfolgt. Und die hat SoC auch nach vier Patches noch satt. (Spezifisches später.)

Mein guter Vorsatz für 2016 war: Alles ändern, was mich stört – statt nur drüber zu jammern. SoCs Quelltext ist geleakt, das waren also beste Voraussetzungen. Ich bin’s angegangen.


Disclaimer: Ich werde mich oft über die Quelltextqualität beschweren. Das Projekt war jedoch viele Jahre in Arbeit – unter finanziell und personell schwierigen Bedingungen. So sehr ich auch stänkere, ich hätte es selber nicht besser hinbekommen.


Kompilieren

Shiiiiit. Der Quelltext ist auf kurz nach dem letzten Patch datiert (wahrscheinlich der Zeitpunkt, an dem alle Arbeiten eingestellt und der Nachfänger begonnen wurde). Und die native Entwicklungsumgebung war … Borland C++. Sie dürften während eines Patches auf Visual C++ 2003 umgestiegen sein, also war es nicht komplett aussichtslos. Ich habe einfach mal alle Projektdateien in eine Solution gehauen und losgelegt.

stalker_solution1.png
stalker_solution1.png (9.96 KiB) 1966-mal betrachtet

Erstes Problem: Die Hälfte davon hat nichts mit dem eigentlichen Spiel zu tun. Da sind Projekte wie
  1. der Multiplayer-Server (mir egal)
  2. die GameSpy-Multiplayer-API (mir egal)
  3. der Level-Editor, Actor Editor, Shader Editor, Particle Editor, … (mir egal)
  4. ein Endkundenprogramm zum Design eigener Charakter im Online-Modus (interessant, aber MFC-Alptraum)
  5. eine Version der Engine zum statischen Linken (das Spiel selber ist aus zig DLLs ausgeliefert; Gründe später)
  6. der Absturzdialog, der Absturzberichte via E-Mail an den Publisher schickt (weg damit)
Abhängigkeiten gibt es auch zu genüge:
  • die Physik-Engine (modifizierte Open Dynamics Engine)
  • zlib (wo ist das NICHT drin?!)
  • boost, loki, und STLPort (sie haben wirklich ALLES ausprobiert!)
  • SDKs für Maya, 3DStudio Max, … (für die Editoren)
Das Vorgehen war also:
  1. das XR_3DA-Projekt kompilieren (so heißt die EXE, die das Spiel startet)
  2. warten, bis sich der Linker über eine Abhängigkeit beschwert
  3. falls die Abhängigkeit wie eines der Projekte heißt, das Projekt ebenfalls kompilierbar machen – sonst nach der richtigen Drittbibliothek suchen
  4. GOTO 1
Dem Quelltext sieht man an, dass das Spiel über zehn Jahre in Entwicklung war und etliche Male umgeschrieben wurde. Nachdem ich die #defines für Visual C++ (statt Borland) gefunden habe, ging es aber relativ schnell. Visual C++’s Abwärtskompatibilität zu Anno dazumal war in diesem Fall total meine Rettung. Es gab ein paar hundert Fehler wegen Casts und Syntaxdetails, die sich seit Visual Studio 2003 geändert haben. Interna von STL-Containern hatten sich geändert; selber implementierte Container sind in den Standard aufgenommen worden und so. Im großen und Ganzen bin ich aber in der ersten Nacht ganz weit gekommen.

In der zweiten Nacht begegnete ich meinem Nemesis.


Jeder Traum endet mit einem Monster

stalker_a_star.png

Das – von template ganz oben bis zur geschweiften Klammer ganz unten – ist die Deklaration einer Klasse. Die Klasse an sich realisiert einen A*-Algorithmus, also Wegfindung für die KI. Und sie kompiliert nicht. Jede Spezialisierung schmeißt einen 30 Zeilen langen, aber ansonsten nichtssagenden Syntaxfehler.

Die etlichen Template-Parameter sind alles, was man an dem Pfad konfigurierbar machen kann. Z.B. will man bei menschlichen Gegnern pro Pfadknoten Deckungsmöglichkeiten und Gefahr abwägen, während Hunde einfach nur von A nach B rennen sollen. Dann übergibt man als entsprechenden Parameter einen Vertex-Typ mit Variable für Deckung oder eben nicht. Und diese Vertices will man wieder unterschiedlich allokieren, also macht man noch einen Template-Parameter für Vertex-Allokatoren, usw. Der Entwickler hatte wohl gerade Andrei Alexandrescus Policy-based Design durchgearbeitet und wollte wissen, wie weit man es treiben kann.

Es hat mich einen halben Tag gekostet, den Ficker zu finden. Der aktuelle C++-Standard erfordert ein zusätzliches template vor einem bestimmten geschachtelten Parameternamen. Die Details habe ich nun auch vergessen (ich hätte damals nicht gedacht, ein Post-Mortem zu schreiben).

Der Algorithmus wird – wie gesagt – für verschiedene Situationen spezialisiert. Jedes „Monster“ (eine Beschreibung für alle Lebewesen im Spiel – vom Spieler über andere Stalker und Monster bis hin zu Krähen) instanziert eine Version des Algorithmus zur Wegfindung. Dummerweise bedeutete das auch, dass ich das Schlüsselwort in hunderten Deklarationen nachtragen musste.

Als ich fast fertig war, hatte ich ein Déjà-Vu. Der Dateiname kam mir bekannt vor. Hmmm. Nachgeschaut, und – Scheiße an der Latte. Sie nutzen den Algorithmus in zwei verschiedenen Projekten, mussten aber irgendein Detail ändern, und haben dafür die dutzenden Dateien einfach kopiert. Ein erheblicher Teil der Dateien liegt als Duplikat mit marginalen Änderungen vor. Schlimmer konnte es wirklich nicht mehr werden.

Wurde es auch nicht! Ich hab’s zu 90 % kompilierbar gekriegt. Danach kamen noch Probleme mit den Allokatoren, aber das ging recht schnell:

SoC nutzt sieben oder acht verschiedene Algorithmen zur Speicherverwaltung. Von new über malloc() und direkte Borland-Aufrufe plus Placement new bis hin zu komplett eigenen Low Fragementation Heaps.

Ich habe einfach alle gelöscht und durch new ersetzt.


Moore’s Law, Schmoore’s Law

Das viele Kompilieren macht einen kirre. Ich habe so schnell wie möglich Visual C++’ Multi-Threaded Compiler aktiviert, aber trotzdem dauert ein Rebuild fast 15 Minuten mit acht Kernen à 3 GHz, und verbraucht über 3 GiB RAM. Im Jahr 2006 haben die Entwickler sicher den ganzen Tag kompilieren müssen.

stalker_rebuild.png

Warum ist das so? Weil nichts strukturiert wurde. Alles #include irgendwelche Monster-Header, und die wiederum andere, und letzten Endes landet alles bei boost. Vorkompilierte Header retten da auch nichts mehr (kompilieren teils fast eine Minute). Außerdem ist alles inline – damals konnten Compiler noch nicht global optimieren, und wollte man wichtige Funktionen inlinen, musste man eben tatsächlich ihren Quelltext #includen.

Ich schätze, dass die Projektstruktur mit den unzähligen DLLs ein verzweifelter Versuch ist, nicht immer alles neu kompilieren zu müssen. (Mit Strukturierung hatte es jedenfalls nichts zu tun – dass die DLL xrGame.dll heißt, bedeutet nicht, dass da auch wirklich nur Spiellogik drin ist.)


Wird der Fenstermodus endlich richtig funktionieren? Werde ich meine 64-Bit-Version kriegen? Geduld! Nächstes Mal gucken wir, ob es überhaupt startet!
Zuletzt geändert von Krishty am 14.03.2017, 02:13, insgesamt 2-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon marcgfx » 14.03.2017, 01:00

Du bist ein richtiger Masochist, aber auch ein guter Texter. Es macht Spass dein Leiden nachzuempfinden!
Benutzeravatar
marcgfx
 
Beiträge: 1014
Registriert: 18.10.2010, 23:26

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.03.2017, 01:07

Danke! Hier noch ein paar Notizen aus meinem Tagebuch. Habe keine Zeit, das zu überprüfen – also behandelt sie als Hörensagen:
rofl die Engine hat sich selbst als Abhängigkeit eingebunden
und weil sie den Fehler nicht gefunden haben, haben sie einfach das Matheprojekt zum Master-Projekt gemacht
I can't even

#include "stdafx.h" // error: cannot open stdafx.h
#include "stdafx.h"

I don't always find my #includes -- but when I do, I do it twice!

Ich sehe jetzt die 3. oder 4. Funktion zum Testen, ob der Heap beschädigt ist … das schafft nicht gerade Vertrauen

ich liebe es, wie anfangs 8 FATAL ERRORs kommen, aber die Engine macht einfach weiter, weil, FUCK, wir müssen ausliefern


… und aus dem Disclaimer-Artikel:
Angeblich habe THQ schon vor einigen Monaten ein neues Studio gesucht, um das Projekt fertig zu stellen. Einem anonymen »Stalker«-Programmierer zu Folge sei das aber gar nicht möglich, da »der Code weitestgehend undokumentiert« sei, »sie würden nichts verstehen.«
Zuletzt geändert von Krishty am 14.03.2017, 02:16, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon MasterQ32 » 14.03.2017, 01:13

Ich bin gespannt auf die nächste Episode von "Krishty macht schon wieder geilen Scheiß und dokumentiert diesen.".

Aber irgendwie fehlt mir da etwas bei folgendem Satz:
Ach ja – die
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
MasterQ32
Felix Queißner
 
Beiträge: 923
Registriert: 07.10.2012, 14:56

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.03.2017, 01:19

MasterQ32 hat geschrieben:Ich bin gespannt auf die nächste Episode von "Krishty macht schon wieder geilen Scheiß und dokumentiert diesen.".

Aber irgendwie fehlt mir da etwas bei folgendem Satz:
Ach ja – die

Danke! Da sollte ein Rant kommen, aber nach Prüfung muss der auf falscher Erinnerung beruhen, und dann war der Satz weg :D

————

Noch einer zum Kompilieren:

#error Please disable exceptions...

Ja, man muss die Engine tatsächlich ohne Ausnahmebehandlung kompilieren. Für die STL-Container ist das natürlich ein Todesstoß. SoC war berüchtigt dafür, bei Out-of-Memory ganz hässlich abzustürzen, und ich weiß nun auch, warum. Übrigens: Google macht es genauso.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.03.2017, 01:53

Nein, so einfach startet das Spiel natürlich nicht.


Kein Russisch

Die erste Hürde ist, dass das Hauptarchiv des Spiels nicht geladen werden kann. Aber es liegt doch direkt da!

10 Sekunden (Fehlermeldung im Quelltext suchen, Haltepunkt weiter oben setzen, starten) später steht fest, warum: Die Spieldateien sind verschlüsselt, und die EXE hat den falschen Schlüssel. Oh. Ein kurzes Herumstochern später steht der Schuldige fest:

stalker_russian_build.png
stalker_russian_build.png (5.2 KiB) 1936-mal betrachtet

Die russische Version verschlüsselt ihre Archive anders als die Europäische. Und ich habe nunmal die Europäische gekauft, mit europäischer Verschlüsselung. #define auskommentieren, fertig.

Warum die russische Version anders ist? Keine Ahnung. Das Studio hat im russischsprachigen Raum selber vertrieben, und den restlichen Vertrieb an GSC Game World abgetreten. Vielleicht hängt es damit zusammen.


тупых американских

Kein gültiger Lizenzschlüssel? Doch, natürlich habe ich den! Nur nicht, wenn ich aus dem Debugger heraus im falschen Verzeichnis starte. Der Kopierschutz ist zum Glück nur drei Zeilen lang, raus damit. Ich hasse Bloat. Den Kommentar darüber sollte man unbedingt durch Google Translate laufen lassen!

Fun Fact: Dem Kopierschutz geht eine Prüfung auf vollen Speicher voraus. Damals war bekannt, dass ein bekannter Kopierschutz ganz einfach umgangen werden konnte, indem man ganz viel Speicher reserviert, bevor die Spiele starten.

Oh, xrRender_R1.dll und xrRender_R2.dll muss man auch kompilieren – man merkt’s leider erst beim Starten (hier hat die Code-Trennung ordentlich funktioniert!). Das sind die Renderer für D3D 8 bzw. 9.

Es folgt eine Handvoll nicht-kritischer Fehler (Beispiel: ich habe meine Spieldateien gemoddet, und ein Modell hat zu viele Bones), und dann … startet tatsächlich das Spiel.

stalker_runs.png

Das ist die Debug-Version mit Diagnostic Output im Renderer. Sie verschwindet hinter der Task-Leiste (Fenster nicht richtig platziert); ruckelt ganz furchtbar; Gegner spawnen im Boden; … aber nach vier Nächten ist das trotzdem ein riesiger Erfolg.

Danach habe ich eine Release-Version kompiliert. Die hat 30 Minuten lang optimiert (Yay!) und lief 15 % schneller als die ausgelieferte Version des Spiels (die Compiler-Verbesserung über zehn Jahre).


Danach habe ich viel aufgeräumt (viel banales Zeug gelöscht, vor allem in der Speicherverwaltung und Master-#includes), aber das ist egal. Nächstes Mal beheben wir die ersten Bugs.


Tagebuch:
irgendwo ein Makro auskommentiert, das ich nicht verstehe, damit die DLLs kompilieren … na wenn das mal gutgeht

lol, 6 GiB temporäre Dateien beim Kompilieren

Optimieren dauert in acht Threads 30 Minuten und frisst 4 GiB RAM

Gucke gerade, ob ich die Sonnenschatten verbessern kann … kein Witz:
  CRender::render_sun(light * fuckingsun) {

50 Leute haben zehn Jahre lang dran entwickelt
ich bin mit Refactoring nicht halb so schnell bin wie Ukrainer beim Tippen grauenvollen Codes
ich müsste 1000 Jahre leben, um das meinen Ansprüchen gerecht werden zu lassen
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Schrompf » 14.03.2017, 08:44

Sehr geil! Beeindruckend! Aber bei Deinem Hang (Wahn) zur Perfektion ist so ein Vorsatz doch tödlich, oder?
Häuptling von Dreamworlds. Baut an was Neuem. Hilft nebenbei nur höchst selten an der Open Asset Import Library mit.
Benutzeravatar
Schrompf
Thomas Ziegenhagen
Moderator
 
Beiträge: 3603
Registriert: 26.02.2009, 00:44
Wohnort: Dresden
Benutzertext: Lernt nur selten dazu

Re: [Projekt] Mein Stalker-Build

Beitragvon joggel » 14.03.2017, 08:46

:P
Wunderbare Lektüre <3

Die Übersetzung des russischen Kommentars ist schon...."interessant"^^
...
Benutzeravatar
joggel
 
Beiträge: 1157
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [Projekt] Mein Stalker-Build

Beitragvon scheichs » 14.03.2017, 11:34

wie immer wieder mega geil zu lesen!
scheichs
 
Beiträge: 200
Registriert: 28.07.2010, 20:18

Re: [Projekt] Mein Stalker-Build

Beitragvon gdsWizard » 14.03.2017, 13:12

Wirklich sehr beeindruckend...Alles was Du machst.
gdsWizard
Thomas Mittelsdorf
 
Beiträge: 203
Registriert: 04.02.2005, 10:12
Wohnort: Meiningen
Benutzertext: www.gamedevstudio.com

Re: [Projekt] Mein Stalker-Build

Beitragvon starcow » 14.03.2017, 15:01

Wahnsinn! Einfach faszinierend! Ich lese mit viel Begeisterung!
Für mich als Anfänger bist du sowas wie ein Code-Guru. :mrgreen:
Was hast du eigentlich für ein Hintergrund? Ich hab mich das schon öfters gefragt.

Gruss starcow

... und bitte weiter schreiben :daumen:
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
starcow
 
Beiträge: 187
Registriert: 23.04.2003, 17:42

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.03.2017, 23:09

Danke allerseits!

Schrompf hat geschrieben:Sehr geil! Beeindruckend! Aber bei Deinem Hang (Wahn) zur Perfektion ist so ein Vorsatz doch tödlich, oder?
Krishty hat geschrieben:50 Leute haben zehn Jahre lang dran entwickelt
ich bin mit Refactoring nicht halb so schnell bin wie Ukrainer beim Tippen grauenvollen Codes
ich müsste 1000 Jahre leben, um das meinen Ansprüchen gerecht werden zu lassen
Nein im Ernst – Ich kann das Spiel jetzt besser genießen :)

    Vorher: „Das ist bestimmt total chaotisch programmiert und hat 1000 Fehler.“

    Jetzt: „Das ist tatsächlich total chaotisch programmiert und hat 992 Fehler.“

starcow hat geschrieben:Was hast du eigentlich für ein Hintergrund? Ich hab mich das schon öfters gefragt.
Habe auf ZFX programmieren gelernt, aber nie ein Spiel fertiggekriegt. Bin dann in die CAD-Branche gegangen (mit meinen Ansprüchen bin ich da auch glücklicher als in der Spieleindustrie).
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 27.04.2017, 22:35

Intermezzo bis ich dazu komme, die Serie vernünftig fortzusetzen:

S.T.A.L.K.E.R. nutzt Deferred Lighting mit Direct3D 9. Weil man in D3D 9 nicht aus Texturen lesen kann, wenn sie Multisampling nutzen, bedeutet das: völliger Verzeicht auf Multisampling. Es flimmert wie bekloppt.

Ich hatte damals (2007?) einen Trick gefunden, Antialiasing durch Supersampling zu erzwingen: Der Engine in ihren INI-Dateien die doppelte Bildschirmbreite und -Höhe vorschreiben. Dann würde Windows das Fenster auf Bildschirmausmaße begrenzen, aber der Renderer würde weiter die hochaufgelösten Puffer nutzen. Wenn der Desktop Window Manager dann den viel zu großen Content in das viel zu kleine Fenster kopiert, nutzt er bilineare Interpolation -- also perfektes 2x2-Supersampling. Aber NUR im Fenstermodus und NUR, wenn Aero aktiv ist, und man muss viel von Hand einstellen.

Alte Schnappschüsse:
05WithoutAA.png
Standardqualität
05WithAA.png
2x2-fach Supersampling durch übergroßes Fenster

Okay. Da ich nun den Quelltext habe, wollte ich versuchen, das Supersampling sauber zu integrieren. Leider wird die Auflösung intern über ein Dutzend verschiedener Variablen verwaltet, und Shadow Maps haben offenbar eine separate Auflösung ... daher kam nur Bildschirmmatsch raus:
2017-03-11 shadow map downsampling 1.png
2017-03-11 shadow map downsampling 2.png

Das geübte Auge erkennt, dass beim Deferred Rendering der Shadow Buffer zu groß für den Color Buffer war. In Bewegung war das deutlicher und sah krass aus, aber ich habe es versäumt, ein Video aufzunehmen. Danach hab ich's aufgegeben weil Zeit und Leben.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 20.09.2017, 00:04

Nicht mein Build, aber thematisch passend: Ich habe Schnappschüsse von Stalkers geleaktem Build 1154 wiedergefunden.

Das Leak ist gerade 15 Jahre alt geworden. Wenn man sich die sanfte Farbstimmung ansieht, könnte man meinen, Shader und dynamische Beleuchtung seien eher Rück- als Fortschritt.

Escape07.png

Escape10.png

Escape01.png

Agroprom02.png
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
 
Beiträge: 5973
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon MasterQ32 » 20.09.2017, 01:25

Wow, echt stimmig. Der Brückenszene fehlt es zwar doch arg an Polygonen, aber sieht generell sehr toll aus, die Fabrik ist schon verdammt stimmig
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
MasterQ32
Felix Queißner
 
Beiträge: 923
Registriert: 07.10.2012, 14:56


Zurück zu Vorstellungsbereich

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron