[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) 6336-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
Establishment
 
Beiträge: 6562
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
Establishment
 
Beiträge: 1133
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
Establishment
 
Beiträge: 6562
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.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1175
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
Establishment
 
Beiträge: 6562
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) 6306-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
Establishment
 
Beiträge: 6562
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: 3747
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"^^
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1346
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
Establishment
 
Beiträge: 301
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
Establishment
 
Beiträge: 233
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
Establishment
 
Beiträge: 240
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
Establishment
 
Beiträge: 6562
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
Establishment
 
Beiträge: 6562
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
Establishment
 
Beiträge: 6562
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.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1175
Registriert: 07.10.2012, 14:56

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 12.04.2018, 21:43

Fun Fact 1:

Ich habe das Projekt zwar weitestgehend auf die 2010er Version von Direct3D 9 portiert (es lief ursprünglich mit einer deutlich älteren Version; 2004 oder 2006 oder so), aber ich muss die Oktober-2006-Runtime trotzdem mitinstallieren.

Die Entwickler haben überall den Datentyp half benutzt, und der ist mit dem 2010er SDK nicht kompatibel. Tatsächlich ist der Oktober-2006-Shader-Compiler der letzte, der den Datentyp noch unterstützt. (Bevor er zehn Jahre später für D3D 11.1 wieder eingeführt wurde.) Darum kompilieren sie ihre Shader immer mit D3DXSHADER_USE_LEGACY_D3DX9_31_DLL, darum braucht es die Oktober-2006-Runtime.


Fun Fact 2:

D3D gibt keinen Fehler aus, wenn die Runtime nicht installiert ist. Einfach E_FAIL beim Kompilieren des Fehlers ohne Fehlermeldung oder Debug-Output. Hat mich eine ganze Stunde gekostet :roll:


Krishty hat geschrieben: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

Ich bestätige das hier mal. Das ganze Spiel hängt zyklisch von sich selber ab. Ich wollte das aufräumen und hab’s vorerst nicht geschafft. Ich muss nun bei Änderungen am Renderer bedenken, ihn zweimal zu kompilieren (einmal, damit die anderen Bibliotheken gegen ihn gelinkt werden und einmal, damit er gegen die anderen Bibliotheken gelinkt wird).

Ich sollte das demnächst unbedingt visualisieren, damit ich auch selber mal verstehe, was man da machen könnte.
Zuletzt geändert von Krishty am 12.04.2018, 21:57, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.04.2018, 11:55

(Ich möchte meinen verbesserten Build hier bald hochladen, aber dafür muss ich Abhängigkeiten zerpflücken. Dauert noch. Bis dahin …)


Vertikale Synchronisation

Ein Problem mit S.T.A.L.K.E.R., das mich immer sehr gestört hat: Das Spiel läuft immer auf maximaler Render-Rate und ohne VSync.

Es gibt einen Menüeintrag, um VSync einzuschalten – aber der funktioniert nicht.

Im Spiel selber hat man deswegen Tearing. Sobald man ins Hauptmenü kommt, dreht die GPU auf wie ein Fön und rendert mit 10.000 fps.

Die Entwickler haben das auch mit dem sechsten Patch nicht in den Griff bekommen.

Ein Glück, dass ich Direct3D-Experte bin!

vs.png



Wir suchen also zuerst die Stelle, an der das Direct3D-Device initialisiert wird – mit einem Aufruf an CreateDevice().

Code: Ansicht erweitern :: Alles auswählen
xr_3da\Xr_input.cpp(106): CHK_DX( pDI->CreateDevice( guidDevice, /*IID_IDirectInputDevice8,*/ device, NULL ) );
xr_3da\HW.cpp(193):void CHW::CreateDevice(HWND m_hWnd)
xr_3da\HW.cpp(333): HRESULT R = HW.pD3D->CreateDevice(DevAdapter,
xr_3da\HW.cpp(341): R = HW.pD3D->CreateDevice( DevAdapter,
xr_3da\HW.h(38): void CreateDevice(HWND hw);
xr_3da\Device_create.cpp(92): HW.CreateDevice(m_hWnd);
xr_3da\xrGame\xrD3D9-Null\IDirect3D9.cpp(124):HRESULT xrIDirect3D9::CreateDevice (UINT Adapter,D3DDEVTYPE DeviceType,HWND hFocusWindow,DWORD BehaviorFlags,D3DPRESENT_PARAMETERS* pPresentationParameters,IDirect3DDevice9** ppReturnedDeviceInterface)
xr_3da\xrGame\xrD3D9-Null\IDirect3D9.cpp(126): APIDEBUG("xrIDirect3D9::CreateDevice");
xr_3da\xrGame\xrD3D9-Null\IDirect3D9.h(56): HRESULT __stdcall CreateDevice( UINT Adapter,D3DDEVTYPE DeviceType,HWND hFocusWindow,DWORD BehaviorFlags,D3DPRESENT_PARAMETERS* pPresentationParameters,IDirect3DDevice9** ppReturnedDeviceInterface);
Das Ergebnis ganz oben ist nutzlos (bezieht sich auf ein Input-Device, also Maus oder Tastatur).

Die drei ganz unten sind ebenfalls nutzlos, denn xrD3D9-Null ist der Dummy-Renderer für Dedicated Servers.

Die Aufrufe mit dem HWND sind Wrapper.

Bleiben diese beiden Aufrufe in xr_3da\HW.cpp (333):

Code: Ansicht erweitern :: Alles auswählen
    // Refresh rate
    P.PresentationInterval = D3DPRESENT_INTERVAL_IMMEDIATE;
    if( !bWindowed )       P.FullScreen_RefreshRateInHz    = selectRefresh    (P.BackBufferWidth, P.BackBufferHeight,fTarget);
    else                   P.FullScreen_RefreshRateInHz    = D3DPRESENT_RATE_DEFAULT;

    // Create the device
    u32 GPU        = selectGPU();    
    HRESULT R = HW.pD3D->CreateDevice(DevAdapter,
                                      DevT,
                                      m_hWnd,
                                      GPU | D3DCREATE_MULTITHREADED,    //. ? locks at present
                                      &P,
                                      &pDevice );
   
    if (FAILED(R))    {
        R = HW.pD3D->CreateDevice(DevAdapter,
                                  DevT,
                                  m_hWnd,
                                  GPU | D3DCREATE_MULTITHREADED,    //. ? locks at present
                                  &P,
                                  &pDevice );
    }
    if (D3DERR_DEVICELOST==R)    {
        // Fatal error! Cannot create rendering device AT STARTUP !!!
        Msg                 ("Failed to initialize graphics hardware.\nPlease try to restart the game.");
        FlushLog            ();
        MessageBox          (NULL,"Failed to initialize graphics hardware.\nPlease try to restart the game.","Error!",MB_OK|MB_ICONERROR);
        TerminateProcess    (GetCurrentProcess(),0);
    };
    R_CHK        (R);


… und das Übel ist direkt in der ersten Code-Zeile: Sie setzen D3D_PRESENT_PARAMETERS::PresentationInterval immer auf D3DPRESENT_INTERVAL_IMMEDIATE (so bald wie möglich anzeigen).

Vielleicht wollten sie die Funktion SelectPresentInterval() etwas weiter unten aufrufen? Die ist aber auch nicht ganz richtig:
Code: Ansicht erweitern :: Alles auswählen
u32     CHW::selectPresentInterval      ()
{
        D3DCAPS9        caps;
        pD3D->GetDeviceCaps(DevAdapter,DevT,&caps);

        if (!psDeviceFlags.test(rsVSync))
        {
                if (caps.PresentationIntervals & D3DPRESENT_INTERVAL_IMMEDIATE)
                        return D3DPRESENT_INTERVAL_IMMEDIATE;
                if (caps.PresentationIntervals & D3DPRESENT_INTERVAL_ONE)
                        return D3DPRESENT_INTERVAL_ONE;
        }
        return D3DPRESENT_INTERVAL_DEFAULT;
}

  • Falls VSync aus ist (!psDeviceFlags.test(rsVSync)), und der Treiber unterstützt Anzeigen ohne VSync (caps.PresentationIntervals & D3DPRESENT_INTERVAL_IMMEDIATE), wird ohne VSync angezeigt.

  • Falls der Treiber synchronisiertes Anzeigen unterstützt (caps.PresentationIntervals & D3DPRESENT_INTERVAL_ONE), wird stattdessen das benutzt. Hmmm. D3DPRESENT_INTERVAL_DEFAULT wäre hier definitiv die bessere Wahl gewesen.

  • Wenn VSync an ist, oder der Treiber gar nichts unterstützt, wird D3DPRESENT_INTERVAL_DEFAULT genutzt. Auch das ist eine schlechte Wahl. Der Unterschied zwischen D3DPRESENT_INTERVAL_DEFAULT und D3DPRESENT_INTERVAL_ONE ist laut MSDN:
    https://msdn.microsoft.com/en-us/library/windows/desktop/bb172585(v=vs.85).aspx hat geschrieben:D3DPRESENT_INTERVAL_DEFAULT uses the default system timer resolution whereas the D3DPRESENT_INTERVAL_ONE calls timeBeginPeriod to enhance system timer resolution. This improves the quality of vertical sync, but consumes slightly more processing time.

Also einigen wir uns auf:
Code: Ansicht erweitern :: Alles auswählen
u32 CHW::selectPresentInterval() {
        D3DCAPS9 caps;
        pD3D->GetDeviceCaps(DevAdapter, DevT, &caps);
        if(psDeviceFlags.test(rsVSync)) { // VSync in den Optionen eingeschaltet?

                if(caps.PresentationIntervals & D3DPRESENT_INTERVAL_ONE) // Qualitativ hochwertiges VSync unterstützt?
                        return D3DPRESENT_INTERVAL_ONE;
                else
                        return D3DPRESENT_INTERVAL_DEFAULT; // fallback auf improvisiertes VSync (immer unterstützt)

        } else { // VSync aus?

                if(caps.PresentationIntervals & D3DPRESENT_INTERVAL_IMMEDIATE) // Anzeige ohne VSync unterstützt?
                        return D3DPRESENT_INTERVAL_IMMEDIATE;
                else
                        return D3DPRESENT_INTERVAL_DEFAULT; // fallback (immer unterstützt)

        }
}
… bauen das in die Device-Erzeugung ein:
Code: Ansicht erweitern :: Alles auswählen
P.PresentationInterval = selectPresentInterval();


Und – ganz wichtig! – auch in CHW::Reset() etwas weiter oben, damit nach Ändern der Option nicht eine Kopie des ursprünglichen, falschen Codes die Kontrolle übernimmt.

… und siehe da: VSync funktioniert! 80 fps im Menü und im Spiel. Schaltet man den Knopf in den Option aus, ist alles beim alten.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon joggel » 14.04.2018, 12:42

Ick freu mir das du es hier veröffentlichen willst.
Ich habe früher S.T.A.L.K.E.R echt gerne gespielt und fand es auch damals von der Grafik echt beeindruckend.
Bin gespannt :)

Achso: und Glückwunsch zum vsync-fix (y)
bald mit neuem Avatar
Benutzeravatar
joggel
Establishment
 
Beiträge: 1346
Registriert: 06.11.2007, 19:06
Wohnort: Dresden

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 14.04.2018, 23:24

Krishty hat geschrieben:Ich sollte das demnächst unbedingt visualisieren, damit ich auch selber mal verstehe, was man da machen könnte.


Ich präsentiere hiermit die Abhängigkeiten der S.T.A.L.K.E.R.-Teilprojekte untereinander:

Abhängigkeiten Stalker.png


Anmerkungen:
  1. xrCore war wahrscheinlich das allererste, was programmiert wurde. Enthält Speicherverwaltung und so. Ist quasi überall drin.
  2. xrGame.dll dürfte die EXE der Betas gewesen sein. Als ihnen auffiel, dass sie den Renderer wechseln mussten, schoben sie den ganzen EXE-Code in DLLs und führten eine neue EXE ein.
  3. ode.dll (Open Dynamics Engine) und openal32.dll (OpenAL) sind komplett Fremdcode. xrLUA.dll und xrXMLParser.dll sind größtenteils Fremdcode, sie haben aber (leider) einige Veränderungen vorgenommen.
  4. Ich weiß nach einem Jahr noch immer nicht, was xrCDB.dll tut.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Chromanoid » 15.04.2018, 00:50

Hehe. Sehr interessant. Danke!

BTW wusstest Du, dass das Trefoil falsch herum ist? Das hat mich schon damals ziemlich aufgeregt (siehe auch https://en.wikipedia.org/wiki/File:S.T. ... s_logo.jpg). Das wird immer von den Künstlern falsch herum gemacht, weil es anders herum irritierend wirkt (was es ja auch soll)...
Benutzeravatar
Chromanoid
Christian Kulenkampff
Moderator
 
Beiträge: 3720
Registriert: 16.10.2002, 19:39
Wohnort: Lüneburg
Alter Benutzername: atr_23

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 15.04.2018, 01:26

Ehrlich gesagt … nein. Cannot be unseen!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 22.04.2018, 14:22

Zu den Abhängigkeiten oben: Das sind viele nutzlose DLLs. Und schlimm sind DLLs eigentlich nicht, aber in S.T.A.L.K.E.Rs Fall sind die Schnittstellen extrem fett: Sie haben einfach jede (!) Funktion, die irgendwie wo anders gebraucht werden könnte, __declspec(dllexport) deklariert. xrGame.dll exportiert einige tausend (!) Funktionen und Klassen.

Für den Optimizer ist das eine Katastrophe, denn der kann keine nicht-referenzierten Sachen rausschmeißen (__declspec(dllexport) sagt: Behalt es, jemand könnte es dynamisch laden wollen!) und auch keine Garantien über Funktionsparameter treffen.

Ich habe also einfach den ganzen Quelltext von xrGame.dll in XR_3DA.exe gekippt. Das ging auch ohne große Probleme (zwei statt einem Precompiled Header, naja … und ein Bisschen die Initialisierungsreihenfolge aufgeräumt). Das Programm ist von 7 MiB auf 6.25 geschrumpft und hat nur noch einige hundert Exporte. Performance … keine Ahnung, habe nicht gemessen.

Beim Säubern neuer Compiler-Warnungen fiel mir auf, dass überall #pragma warning genutzt wurde, um Warnungen zu killen. Auch recht üble Sachen wie rvalue-an-const-Referenz. Habe alles rausgeschmissen.

Dann fiel mir auf, dass oft #pragma optimize eingesetzt wurde, um bestimmte Code-Teile auf Größe statt Geschwindigkeit zu optimieren. Das habe ich ebenfalls rausgeschmissen. Die Größe ist so drastisch gestiegen, dass ich wieder bei der Größe der original-Spieldateien bin.

Und irgendwie habe ich einen Black Screen ohne Ton. Irgendwas muss kaputtgegangen sein. Möglicherweile war die Optimierung aus, weil der Optimizer was kaputtmacht?
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Top-OR » 23.04.2018, 17:45

Krishty hat geschrieben:... Und irgendwie habe ich einen Black Screen ohne Ton. Irgendwas muss kaputtgegangen sein. Möglicherweile war die Optimierung aus, weil der Optimizer was kaputtmacht?


Ich habe eben deinen neusten Post gelesen und muss sagen: Was du da beschreibst, klingt für mich wie der totale Horror.

Im Grunde das ganze Projekt. Jemand wie ich hätte nichtmal den Mut, zu versuchen, diesen Kruscht überhaupt zu kompilieren bzw. aufzuräumen.
Ich hätt bei jedem kleinen Handgriff Angst, was kaputt zumachen.

Aber ich finds cool, dass du dich da durchfriemelst. Ich lese das (und schaudere) sehr gerne ...
--
Verallgemeinerungen sind IMMER falsch.
Benutzeravatar
Top-OR
Jens H.
Establishment
 
Beiträge: 318
Registriert: 02.03.2011, 17:32
Wohnort: Esslingen/Dessau

Re: [Projekt] Mein Stalker-Build

Beitragvon Thoran » 25.04.2018, 09:37

Sorry, dass ich hier kurz Offtopic reinkrätschen muss. @Top-OR lies mal Deine PNs.
Wer Rechtschreibfehler findet, darf diese gerne behalten.
Mein Entwicklertagebuch
Aktuelles Projekt: "Arbeitsttitel AlphaOmega"
Spieleengine SilverCore
Benutzeravatar
Thoran
Establishment
 
Beiträge: 191
Registriert: 15.05.2009, 12:51
Wohnort: Stuttgart

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 28.04.2018, 00:12

Top-OR hat geschrieben:Jemand wie ich hätte nichtmal den Mut, zu versuchen, diesen Kruscht überhaupt zu kompilieren bzw. aufzuräumen.
Ich hätt bei jedem kleinen Handgriff Angst, was kaputt zumachen.

Aber ich finds cool, dass du dich da durchfriemelst. Ich lese das (und schaudere) sehr gerne ...
Ach, ich seh’s als großes Puzzle … sehr großes Puzzle :) Und so komme ich einem echten Spiel näher als mit meinen eigenen Engines.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 12.05.2018, 10:50

Habe endlich eine Version fertig kompiliert bekommen:
bin.7z
(4.23 MiB) 45-mal heruntergeladen

  • ihr braucht eine S.T.A.L.K.E.R.-Installation; macht ein Backup eures bin-Ordners und nutzt stattdessen den aus dem Archiv
  • ihr müsst vc_redist.x86.exe installiert haben
  • wahrscheinlich müsst ihr die Konfiguration neu durchführen, weil die user.ltx (User-Einstellungen) nun nicht mehr unter C:\s.t.a.l.k.e.r. - shadow of chernobyl landet, sondern unter %APPDATA%\s.t.a.l.k.e.r. - shadow of chernobyl
  • Avast und AVG finden die Dateien verdächtig; schaltet das also vorher ab (für Avast habe ich mittlerweile ein Whitelisting-Login, das darf ich aber hier nicht nutzen, weil ich nicht die Rechte an S.T.A.L.K.E.R. besitze)
Änderungen:
  • FIXED: window isn’t fixed to top-left corner any more (also fixes task bar interference)
  • CHANGED: window now opens centered
  • FIXED: splash screen doesn’t freeze the system any more
  • FIXED: on ALT+TAB, mouse now becomes visible again
  • FIXED: v-sync button works now
  • FIXED: cursor position is now stored when leaving and re-entering UI (e.g. inventory)
  • FIXED: one-second system freeze on startup
  • CHANGED: config is now written to %APPDATA%\s.t.a.l.k.e.r. - shadow of chernobyl instead of C:\s.t.a.l.k.e.r. - shadow of chernobyl (fixes countless problems with missing C: drive)
  • CHANGED: improved shadow map resolution from 1536² to 8192²; moved level of detail farther away
  • CHANGED: migrated from April 2006 DirectX SDK to August 2007 (for DirectPlay 8) and June 2010 (for D3DX 9)
  • CHANGED: removed sprite cursor and replaced with Windows cursor
  • CHANGED: updated toolset to Visual Studio 2017.7
  • CHANGED: removed bloat (shader debug information, needless vftables, security cookies, duplicate data, needless virtual inheritance)
  • CHANGED: raised bone limit from 64 to 128 (fixes some assertions with high-detail models)
  • CHANGED: updated OpenAL (latest version 1.1 fom 2009)
  • CHANGED: removed EAX
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon mrz » 20.05.2018, 15:35

FYI:
Die S.T.A.L.K.E.R. Reihe gibts bei gog.com z.Zt vergünstigt.
mrz
 
Beiträge: 39
Registriert: 07.08.2008, 14:34

Re: [Projekt] Mein Stalker-Build

Beitragvon starcow » 21.05.2018, 10:01

mrz hat geschrieben:FYI:
Die S.T.A.L.K.E.R. Reihe gibts bei gog.com z.Zt vergünstigt.

Tatsächlich! Vielen Dank für den Hinweis! (-:

@Kristhy
Weiss eigentlich die S.T.A.L.K.E.R Fan-Gemeinde um dein Vorhaben?
Dein Projekt dürfte da Begeisterungsstürme verursachen. :mrgreen:

Wirklich interessantes und cooles Projekt :daumen:
Hat ja beinahe was von "Restaurations-Arbeit wertvollen Kulturguts" ^^
Die hätten dich wohl damals im Team gebraucht ;-)
Freelancer 3D- und 2D-Grafik
mischaschaub.com
Benutzeravatar
starcow
Establishment
 
Beiträge: 240
Registriert: 23.04.2003, 17:42

Re: [Projekt] Mein Stalker-Build

Beitragvon Krishty » 21.05.2018, 10:14

starcow hat geschrieben:Weiss eigentlich die S.T.A.L.K.E.R Fan-Gemeinde um dein Vorhaben?
Dein Projekt dürfte da Begeisterungsstürme verursachen. :mrgreen:
Nee, die wissen nichts davon – aber es gibt zahllose andere Gruppen, die den Quelltext haben. Für S.T.A.L.K.E.R. – Lost Alpha wurde die Engine z.B. um D3D 10-Fähigkeit erweitert. DIe Begeisterungsstürme über meine paar Optimierungen halten sich also in Grenzen ;) Mir geht’s vor allem darum, es spielbar zu halten in den nächsten 10, 20 Jahren. Das ist ja erfahrungsgemäß schwer ohne Quelltext.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
 
Beiträge: 6562
Registriert: 26.02.2009, 12:18
Benutzertext: state is the enemy

Re: [Projekt] Mein Stalker-Build

Beitragvon MasterQ32 » 21.05.2018, 10:28

Mir geht’s vor allem darum, es spielbar zu halten in den nächsten 10, 20 Jahren. Das ist ja erfahrungsgemäß schwer ohne Quelltext.

Löblich! Ich muss die Spiele unbedingt auch mal noch spielen... Und da hat man ja gleich noch nen kleine Modernisierung dabei!

Du hast ja schon die Shadow Map hochgedreht, wie viel Aufwand wäre es, ne Option für SSAA oder MSAA einzubauen? Müsste wesentlich mehr Aufwand sein, oder?
Duct tape is like the force. It has a light side, a dark side, and it holds the world together.
Benutzeravatar
MasterQ32
Felix Queißner
Establishment
 
Beiträge: 1175
Registriert: 07.10.2012, 14:56

Nächste

Zurück zu Vorstellungsbereich

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron