Reverse Engineering der NLT II

[HenneNWH]

Ich nenne nur: "MACTANS", "RAD" und "SPINNENNETZ".
Änderung der Heldennamen, Eingabe von Nummern.
Ohne Texteingabe ist SCHICK nicht schick.

[cmfrydos]

Da wären noch die Passwörter zu Beginn. Ich weiß gerade nicht, ob das auch für Schick gilt, aber in Riva nutze ich die Funktionstasten (F1–F12) doch sehr häufig, um in die verschiedenen Menüs zu kommen. Teilweise gibt es dafür auch keinen anderen Ersatz.
Und natürlich sind die Pfeiltasten zum Bewegen in Städten und Dungeons deutlich angenehmer als die Maussteuerung.

Wird die Steuerung, wie in Riva, denn auch fast ausschließlich über Interrupts gelöst? Das macht es etwas trickreicher, da es dort keine „globale“ Spielschleife gibt, sondern je nach Screen unterschiedliche, kleinere Schleifen, in denen man einen eigenen Input-Handler scharfstellen müsste, der dann wiederum an die registrierten Interrupt-Routinen weiterleiten müsste.

[HenneNWH]

Nix Interrupt, das wurde alles mit bioskey() gelöst. Use the Source.

[cmfrydos]

Ah, das erklärt, wieso ich noch nie über welche gestolpert bin.
Ich schaue nur sporadisch in den Code, mir fehlt aktuell leider die Zeit um die Entwicklungen genauer zu verfolgen. Auf jeden Fall super Arbeit!

[HenneNWH]

Wenn du nen Hinweis für irgendetwas konkretes brauchst: Frag ruhig nach.
Siebenstreich und sind in vielen Dingen fit und finden schnell raus wo etwas zu finden ist.

[Hirukan]

Um auf mobilen Geräten eine Tastatur einzublenden, könnte man verschiedene Gesten verwenden. Platform spezifische Branches möchte ich zwar gerne vermeiden, aber durch die unterschiedliche Auflösung hat man auf mobilen Geräten rechts und links ohnehin recht breite Trauerränder. Prinzipiell könnte man dort eine plattformspezifische Verzweigung einfügen und links und rechts einige Icons einblenden (z. B. für die F-Tasten, PgUp usw.). Alternativ könnte man diese Lösung auch auf allen Plattformen nutzen, sofern es die Auflösung zulässt.

Ich bin mir jedoch nicht sicher, ob solche zusätzlichen Features überhaupt erwünscht sind, da das Ergebnis dann offensichtlich nicht mehr vollständig originalgetreu wäre. Für mich persönlich wären solche Änderungen aber akzeptabel, da sie das eigentliche Spiel nicht verändern, sondern lediglich eine Bedienung ohne Tastatur ermöglichen.

[Hirukan]

Henne, du hast die ganze Vorarbeit geleistet für das Projekt. Hut ab Reverse Engineering bedarf unglaubliches Wissen, können und Geduld. Auch dass du an einem Projekt so lange entwickelst hast, zeigt eine enorme Hingabe.

Was sind nun die nächsten Schritte? Wo können wir helfen? Für mich, käme als nächster Schritt in Frage, die Sourcecode Dateien ein wenig zu organisieren. Denen einen Aussagekräftigen Namen zu geben, eventuell eine kleine Ordnerstruktur zu erstellen (graphics, audio, system, ...)?

Ist das Projekt schon so weit für so einen Schritt?

[siebenstreich]

Henne hat es mal sehr treffend als "digitale Denkmalpflege" bezeichnet. Ich schreibe mal meine persönliche Interpretation davon auf.

Projekt 1.
Rekonstruktion der Schicksalsklinge ausgehend von der originalen Binärdatei als C-Code.

Die grundlegende Zielsetzung ist, dass mit dem Original-Compiler und Linker exakt dasselbe Binary rauskommt.
Dies ist nach jahrelanger Arbeit von Henne i.W. abgeschlossen. Er hat dafür meine höchste Anerkennung, zum einen für sein technisches Grundwissen uns seine Fähigkeiten (der Ansatz mit der Dosbox ist schlichtweg genial!), und zum anderen für sein Durchhaltevermögen. Nur mit dieser Kombination war es möglich, dorthin zu kommen, wo wir heute stehen. Ich vermute, dass Henne eine fünfstellige Anzahl von Stunden an diesem Projekt gearbeitet hat. 

Es gibt noch eine weitere Ausbaustufe: In diesem reverse-engineering-Prozess fallen die Bezeichner (Funktionen, Variablen etc.) oft erstmal ziemlich kryptisch aus. Für einen schönen, verständlichen C-Code müssen diese Bezeichner geeignet umbenannt werden, was ein Verständnis der höheren Zusammenhänge im Programmcode erfordert (eine gute Kenntnis des Spiels ist hierfür sehr hilfreich). Hier habe ich mich ein wenig mit eingebracht. Den aktuellen Fortschritt würde ich als gut, aber noch nicht als perfekt bezeichnen.

Durch den rekonstruierten C-Code steht das Spiel gewissermaßen nackt da. Wir können prinzipiell alles im Quellcode nachlesen, womit über die Jahre viele neue Erkenntnisse über das Spiel gewonnen wurden. Aus eigener Produktion kann ich hier z.B. die Wirkweise des magischen Wurfdolchs und das Aufklären der Gerüchte um einen Praios-Tempel aufführen.

Projekt 2.
Eine moderne Version der Schicksalsklinge, die ohne Dos-Box direkt auf aktuellen Betriebssystemen lauffähig ist.

Der Startpunkt ist Projekt 1, wobei zwangsweise ein gewisser Bruch stattfindet, denn der Anspruch, dass das Spiel exakt mit dem Original identisch ist, kann hierbei nicht aufrecht erhalten werden. Den "proof of concept" hat Henne mit dem Charakter-Generator bereits erbracht. Es müssen alle Stellen ertüchtigt werden, wo eine Interaktion des Spiels mit der Hardware oder dem Betriebssystem stattfindet, u.a.

• Grafik
  
• Sound
  
• Eingabe (Tastatur, Maus)
  
• Dateisystem-Zugriffe
  

 Es findet also zwangsweise ein gewisser Bruch zu Projekt 1 statt.

In diesem Rahmen ist auch geplant:

• Soweit möglich alle bekannten Fehler zu reparieren.
  
• Neue Features mit einzubauen, aber mit Augenmaß! Keine wilden Modding-Phantasien, sondern nur Dinge, die auch für das 1992er Original gut vorstellbar sind, wenn das Entwickler-Team etwas mehr Kapazitäten gehabt hätte.
  

Aktueller Stand.
Momentan stehen wir am Scheideweg zwischen Projekt 1 und 2. Henne scharrt schon mit den Hufen, den Wechsel zu vollziehen, und ich freue mich auf sehr darauf. Aber man sollte sich den Schritt auch gut überlegen, denke ich, denn man hat dann ja zwei getrennte Code-Basen. Dinge, die man gerne in Projekt 2 drinhätte und jetzt an Projekt 1 noch machen kann, sollte man vielleicht eher jetzt gleich noch machen. Denn in Projekt 1 haben wir noch den Binäräquivalenz-Test, der uns sehr zuverlässig vor Fehlern bewahrt. Außerdem ist es natürlich schön, auch den Code von Projekt 1 möglichst aktuell zu haben.

[llm]

Henne hat da wirklich unglaubliches geleistet

seine Source-Reconstruction (so nennt man das Reversing bei dem Source raus kommt der binärgleich baut) gehört zu den wenigen Projekten (maximal 5 oder so) die diesen Weg gegangen sind (oder noch gehen) bei teilweise viel kleineren Spielen

anderen Projekten (auch sehr wenige) reicht ein funktional identisches Reversing - was aber auch nicht wirklich leicht ist aber nicht ganz so herausfordernd

andere Reconstruction-Projekte:
A reconstruction of the source code of Cosmo's Cosmic Adventure: https://github.com/smitelli/cosmore - Fertig
Reconstructed source code of the game Duke Nukem II: https://github.com/lethal-guitar/Duke2Reconstructed - Fertig
The Reconstruction of ZZT: https://github.com/asiekierka/reconstruction-of-zzt - Fertig
Reconstructed source code for the Microprose game F-15 Strike Eagle 2 for MS-DOS: https://neuviemeporte.github.io/category/f15-se2.html - am Anfang

[cmfrydos]

Und was wäre, wenn man die verschiedenen Projektstände in unterschiedlichen Branches führt?

• Haupt-Branch „BCEQ-DOS“: Projekt 1 – Ziel: Refactorings, um den Code besser zu verstehen. Pull-Request-Akzeptanzkriterium: Die Binäräquivalenz (BCEQ) bleibt erhalten.
  
• Branch „Patches“ – baut auf dem Haupt-Branch auf, mit dem Ziel, bekannte Fehler im Spiel zu beheben.
  
• Branch „SDL-Win“ – baut auf dem Patch-Branch auf, mit dem Ziel, Windows-Kompatibilität via SDL herzustellen.
  
• Branch „Features“ – baut auf dem SDL-Branch auf: alles, was an zusätzlichem Schnickschnack cool wäre. QoL-Verbesserungen, Android-Support, optionale Erweiterungen, ggf. „echte“ Mods, die das Spiel über den Originalzustand hinaus verbessern.
  

Man hätte also folgende Schichtung:

BCEQ-DOS
Patches
SDL-Win
Features

Außerdem würde man versuchen, die abhängigen Branches regelmäßig auf den aktuellen Stand ihres Mutter-Branches zu bringen (z. B. per Rebase).

Damit könnte man an den verschiedenen Ausbaustufen parallel arbeiten, ohne sich gegenseitig groß in die Quere zu kommen. Wichtig wäre dann natürlich, dass die jeweiligen Änderungen zuerst im richtigen Branch landen.

Nur so als Idee – die Alternative wäre eben der Bruch in mehrere verschiedene Projekte, die nicht mehr direkt zusammenarbeiten.

---

Um auf mobilen Geräten eine Tastatur einzublenden, könnte man verschiedene Gesten verwenden. Platform spezifische Branches möchte ich zwar gerne vermeiden, aber durch die unterschiedliche Auflösung hat man auf mobilen Geräten rechts und links ohnehin recht breite Trauerränder. Prinzipiell könnte man dort eine plattformspezifische Verzweigung einfügen und links und rechts einige Icons einblenden (z. B. für die F-Tasten, PgUp usw.). Alternativ könnte man diese Lösung auch auf allen Plattformen nutzen, sofern es die Auflösung zulässt.

Ich bin mir jedoch nicht sicher, ob solche zusätzlichen Features überhaupt erwünscht sind, da das Ergebnis dann offensichtlich nicht mehr vollständig originalgetreu wäre. Für mich persönlich wären solche Änderungen aber akzeptabel, da sie das eigentliche Spiel nicht verändern, sondern lediglich eine Bedienung ohne Tastatur ermöglichen.

Finde ich auch sinnvoll, aber eventuell erst nach der Windows-Kompatibilität.
Nur könnte es mühselig sein, den entsprechenden Build aufs Handy zu bringen – aus rechtlichen Gründen dürfte man ja kein fertiges APK anbieten. Aber vielleicht springt bis dahin ja Attic wieder auf .

[siebenstreich]

Und was wäre, wenn man die verschiedenen Projektstände in unterschiedlichen Branches führt?

• Haupt-Branch „BCEQ-DOS“: Projekt 1 – Ziel: Refactorings, um den Code besser zu verstehen. Pull-Request-Akzeptanzkriterium: Die Binäräquivalenz (BCEQ) bleibt erhalten.
  
• Branch „Patches“ – baut auf dem Haupt-Branch auf, mit dem Ziel, bekannte Fehler im Spiel zu beheben.
  
• Branch „SDL-Win“ – baut auf dem Patch-Branch auf, mit dem Ziel, Windows-Kompatibilität via SDL herzustellen.
  
• Branch „Features“ – baut auf dem SDL-Branch auf: alles, was an zusätzlichem Schnickschnack cool wäre. QoL-Verbesserungen, Android-Support, optionale Erweiterungen, ggf. „echte“ Mods, die das Spiel über den Originalzustand hinaus verbessern.
  

Man hätte also folgende Schichtung:

BCEQ-DOS
Patches
SDL-Win
Features

Außerdem würde man versuchen, die abhängigen Branches regelmäßig auf den aktuellen Stand ihres Mutter-Branches zu bringen (z. B. per Rebase).

Damit könnte man an den verschiedenen Ausbaustufen parallel arbeiten, ohne sich gegenseitig groß in die Quere zu kommen. Wichtig wäre dann natürlich, dass die jeweiligen Änderungen zuerst im richtigen Branch landen.

Nur so als Idee – die Alternative wäre eben der Bruch in mehrere verschiedene Projekte, die nicht mehr direkt zusammenarbeiten.

Ja, es wäre großartig, wenn man das so schichten könnte. Bloß will mir beim Konkretisieren solcher Gedanken bisher leider keine realistische Umsetzung einfallen. Stimmungsdämpfer sind:

• Programmlogik und I/O wird im Spiel oft wild vermischt. Es gibt z.B. einen Bug, wo die Leichen toter Gegner verschwinden, wenn ein zweifeldriges Monster in einer gewissen Richtung drüberläuft. Und zwar wohlgemerkt nicht nur graphisch, sondern generell (nicht mehr durch einen Horriphobus anwählbar). Die schuldige Stelle ist gut versteckt in einem Programmteil, der eigentlich die Kampf-Animation macht.
  
• Manche Bugs lassen sich nicht lokal fixen, sondern erfordern größere Umbauarbeiten.
  
• Es gibt genügend Stellen, wo man für eine neue, cleane Version die Dinge lieber "funktional-äquivalent" nachbauen will, anstelle die originale, krude Programmlogik weiter durchzuschleppen.
  

Vielleicht fehlt mir auch einfach nur die Phantasie.

[Hirukan]

Finde ich auch sinnvoll, aber eventuell erst nach der Windows-Kompatibilität.

Hmmm ich habe ein Windows 10 Installation in einem Virtual PC, aber die benutze ich nur um zu sehen ob meine CMakeLists.txt auch unter Windows laufen und das Visual Studio Projekt dann auch funktioniert wenn man den Play button klickt (sprich die Pfade relativ zu den assets, die dlls an die richtige stelle kopiert etc...). Und dann schnell wieder raus da, bevor irgendwelche Zwangsfeatures installiert oder gar ein Windows 11 Update läuft und meine Virtual Machine versaut wird weil die (virtuelle) SSD mit einem BitLocker gesperrt ist, oder was weiß ich was 

Also hauptsächlich Entwickle ich in Linux. Aber solange SDL benutzt wird ist alles gut, da sich ja SDL um das Betriebssystemspezifische Zeug kümmert.

[llm]

Henne hats gemacht!

der DOS "Fork" liegt jetzt in schick_dos und der schick-Folder ist jetzt der Portierungsfolder der auf Linux, Windows, ... getrimmt wird - also erstmal ohne Branch

direkt mal zur Feier des Tages einen Pull-Request erstellt


auf jeden Fall bauen alle EXEn - ohne SDL - schon mal mit MSVC 2017-2026, Windows clang/clang-cl und msys2-gcc/clang - jetz fehlen nur noch Portierung der läppischen paar Zeile Assembler und DOS-API-Code

[Shihan]

Also gewissermaßen fertig 

Glückwunsch und Hut ab an Henne für die Wahnsinnsarbeit, die du hier geleistet hast!!!
Und schön, dass jetzt weitere engagierte Helfer mitmachen

[HenneNWH]

Danke, Danke!

Von übermäßigem gebranche halten ich nicht soviel: "Branchen ist einfach, das Zusammenführen ist eher das Problem."

Das Verzeichnis schick ist jetzt der Hauptbranch des Projektes!

Dort werden vorerst notwendige grundlegende Low-Level-Fehler von mir behoben und der vom Charaktergenerator etablierte SDL-Port angebaut.
Binäräquivalenz bleibt vorerst erhalten. Ich vermute jedoch, dass diese nicht allzulange aufrecht erhalten werden kann.
Features bleiben erstmal außen vor, bis Schick annehmbar und stabil auf Linux und Windows läuft.

Wer ein Feature entwickeln möchte kann das gerne tun, sollte aber zu einem Meeting vorher mit dabei sein,
damit es auch zum Spiel passt.

Kleine Info zu den Charakterbildern und dem Import nach Schweif:
Hab gerade einen das Bild eines Schick-Helden per Hexeditor modifiziert und den Spielstand in Schweif importiert.
Der Held bekommt dann automatisch ein Gesicht zugeordnet, welches man in Schweif per Auswahl ändern kann.
D.h. es ist für Schick möglich eigene Icons zu benutzen.
Somit ist der Wunsch von Obi-Wahn praktisch umsetzbar, aber nur auf Schick begrenzt.

[NewProggie]

Features bleiben erstmal außen vor, bis schick annehmbar und stabil auf Linux und Windows läuft.

macOS!

[HenneNWH]

Features bleiben erstmal außen vor, bis schick annehmbar und stabil auf Linux und Windows läuft.

macOS!

Nur wenn's keine Umstände macht. Der Charaktergenerator war relativ einfach was Dateizugriffe betrifft.

Versprechen kann ich nichts, bin mir aber sicher: Wenn's unter Linux läuft, dann auch unter macOS.

[NewProggie]

Features bleiben erstmal außen vor, bis schick annehmbar und stabil auf Linux und Windows läuft.

macOS!

Nur wenn's keine Umstände macht. Der Charaktergenerator war relativ einfach was Dateizugriffe betrifft.

Versprechen kann ich nichts, bin mir aber sicher: Wenn's unter Linux läuft, dann auch unter macOS.

Falls es nicht geht, kann ich mir das für macOS anschauen.

[llm]

Falls es nicht geht, kann ich mir das für macOS anschauen.

sobald wir CMake habe wird das wohl recht einfach sein - mit brew ein paar Libs/Tools installieren - bauen -> fettich!

[NewProggie]

Falls es nicht geht, kann ich mir das für macOS anschauen.

sobald wir CMake habe wird das wohl recht einfach sein - mit brew ein paar Libs/Tools installieren - bauen -> fettich!

CMake hatte ich vor ein paar Wochen schon hinzugefügt (in meinem Fork). Wurde aber nicht upstream gemerged bisher.

Edit: Conan besser