[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.
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

[Projekt] Mein Stalker-Build

Beitrag von Krishty »

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) 17340 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, 01:13, insgesamt 2-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
marcgfx
Establishment
Beiträge: 2050
Registriert: 18.10.2010, 23:26

Re: [Projekt] Mein Stalker-Build

Beitrag von marcgfx »

Du bist ein richtiger Masochist, aber auch ein guter Texter. Es macht Spass dein Leiden nachzuempfinden!
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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, 01:16, insgesamt 1-mal geändert.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von xq »

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
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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) 17310 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
Schrompf
Moderator
Beiträge: 4831
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Schrompf »

Sehr geil! Beeindruckend! Aber bei Deinem Hang (Wahn) zur Perfektion ist so ein Vorsatz doch tödlich, oder?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
joggel

Re: [Projekt] Mein Stalker-Build

Beitrag von joggel »

:P
Wunderbare Lektüre <3

Die Übersetzung des russischen Kommentars ist schon...."interessant"^^
gdsWizard
Establishment
Beiträge: 237
Registriert: 04.02.2005, 09:12
Benutzertext: www.gamedevstudio.com
Echter Name: Thomas Mittelsdorf
Wohnort: Meiningen
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von gdsWizard »

Wirklich sehr beeindruckend...Alles was Du machst.
Benutzeravatar
starcow
Establishment
Beiträge: 522
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von starcow »

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
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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:
Standardqualität
Standardqualität
2x2-fach Supersampling durch übergroßes Fenster
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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von xq »

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
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

(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: 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: 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: 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: 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: 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
joggel

Re: [Projekt] Mein Stalker-Build

Beitrag von joggel »

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)
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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
Chromanoid
Moderator
Beiträge: 4252
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: [Projekt] Mein Stalker-Build

Beitrag von Chromanoid »

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
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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
Top-OR
Establishment
Beiträge: 330
Registriert: 02.03.2011, 16:32
Echter Name: Jens H.
Wohnort: Esslingen/Dessau
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Top-OR »

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
Thoran
Establishment
Beiträge: 224
Registriert: 15.05.2009, 12:51
Wohnort: Stuttgart
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Thoran »

Sorry, dass ich hier kurz Offtopic reinkrätschen muss. @Top-OR lies mal Deine PNs.
Wer Rechtschreibfehler findet, darf diese gerne behalten.
Mein Entwicklertagebuch
Aktuelle Projekte: Universum: Domination (ehemalig AlphaOmega),Universum: Sternenjäger, PixelWars: Highscore-based Top-Down-Spaceshooter
Spieleengine Unreal 5
Benutzeravatar
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

Habe endlich eine Version fertig kompiliert bekommen:
bin.7z
(4.23 MiB) 690-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
mrz
Beiträge: 79
Registriert: 07.08.2008, 14:34

Re: [Projekt] Mein Stalker-Build

Beitrag von mrz »

FYI:
Die S.T.A.L.K.E.R. Reihe gibts bei gog.com z.Zt vergünstigt.
Benutzeravatar
starcow
Establishment
Beiträge: 522
Registriert: 23.04.2003, 17:42
Echter Name: Mischa Schaub
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von starcow »

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
Krishty
Establishment
Beiträge: 8227
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von Krishty »

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
xq
Establishment
Beiträge: 1581
Registriert: 07.10.2012, 14:56
Alter Benutzername: MasterQ32
Echter Name: Felix Queißner
Wohnort: Stuttgart & Region
Kontaktdaten:

Re: [Projekt] Mein Stalker-Build

Beitrag von xq »

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?
War mal MasterQ32, findet den Namen aber mittlerweile ziemlich albern…

Programmiert viel in ⚡️Zig⚡️ und nervt Leute damit.
Antworten