Reverse Engineering der NLT

[HenneNWH]

Sind die Segmentnummern Deine eigene Aufteilung, tatsächliche Segmente des Binaries oder logische Einheiten.

Die Nummerierung hat sich IDA-Pro ausgedacht (aufsteigend vom Anfang des Binaries).
Ein Segment entspricht dem Inhalt einer Objekt-Datei, und im Fall von Bright-Eyes auch einer C-Datei.

P.S.: Das Wiki sollte jetzt wieder etwas schneller laufen. Mehr Serverleistung.

Danke Obi!

[Lippens die Ente]

Welche genau meinst du?

na alle Kämpfe, die kommen, sobald man ein bestimmtes Feld betritt. So wie in den Städten ein Tempel betreten wird, wird dort eben ein Kampf betreten. Alle mir fehlenden Kämpfe werden auf solchen Feldern ausgetragen, dazu kommen noch sämtliche Zufallskämpfe beim Übernachten in Dungeons, genau die, die ich verändern wollte...

[Helios]

Meine Frage bezog sich auf "Feldinhalte der Dungeonfelder". Die Zuordnung dieser Kämpfe läuft über die noch nicht ganz entschlüsselten Dats. Ich meine es wäre FNEIBOUR.DAT gewesen aber keine Garantie, ist schon eine Weile her.

[HenneNWH]

Soo, eine produktive Woche mit Bright-Eyes liegt hinter mir, mit folgenden Ergebnissen:

Ersetzte Funktionen (Segmente sind komplett identisch)

• seg099, seg100: ALLE Zaubersprüche, bis auf Transversalis, da die Zielauswahl noch nachgebaut werden muss
  
• seg107: Benutzung von Gegenständen (Waffengift, Orkdokumente, Magischer Beutel, etc)
  
• seg096: Zeichenkettenfunktionen
  

Behobene Fehler (Bright-Eyes):

• Farbige Texte funktionieren wieder
  
• Zwei mögliche Abstürze in "Ecliptifactus" und "Blitz dich find" wurden behoben
  

Behobene Fehler, Verbesserungen (Original):

• Hjore kann nicht mehr durch Lesen des Schuldbuches von den Toten auferweckt werden
  
• Beim Wiederauffüllen einer brennenden Öllampe wird das Öl beim falschen Helden gesucht
  
• Warnung, wenn der BEUTEL nicht in der Magierruine geöffnet wird
  

Zu Statistik: Mehr als 50% aller Funktionen von Schick sind jetzt nachprogrammiert, davon sind über 2/3 nachgeprüft identisch mit dem Original (d.h. 1/3 oder 33% vom gesamten Spiel).
Viel Spaß,
Henne

[Obi-Wahn]

Unter Linux klappt das Bauen leider nicht:

Code:

make[5]:
*** Keine Regel vorhanden, um das Target  »seg074.cpp «,
  benötigt von  »seg074.o «, zu erstellen.  Schluss.

Edit: Hier noch der BuildLog von Windows:
  BuildLog.zip (Größe: 5,97 KB / Downloads: 0)

[Rabenaas]

Zu Statistik: Mehr als 50% aller Funktionen von Schick sind jetzt nachprogrammiert, davon sind über 2/3 nachgeprüft identisch mit dem Original (d.h. 1/3 oder 33% vom gesamten Spiel).
Viel Spaß,
Henne

Um es mal so zu sagen: Das ist einfach nur irre. Super Leistung.

[Shihan]

Krass! Großartige Sache, Henne, einfach großartig!

Nur eine Frage hätte ich, nach einem Blick in den Code: Wie könnte ein mögliches, in der unbestimmten Zukunft liegendes Refaktoring aussehen? Ich blick' da nämlich überhaupt nicht durch

[Obi-Wahn]

Neue Version vom 17.08.2014!

[HenneNWH]

Vielen Dank!

Unter Linux klappt das Bauen leider nicht:

Manchmal lass ich mich von GIT doch noch austricksen.
Die fehlenden Dateien sind jetzt im Repo.

Nur eine Frage hätte ich, nach einem Blick in den Code: Wie könnte ein mögliches, in der unbestimmten Zukunft liegendes Refaktoring aussehen? Ich blick' da nämlich überhaupt nicht durch

Ja, Shihan, der Code ist momentan sehr unleserlich, was viele Ursachen hat.

Der grobe Entwicklungsfahrplan hat 3 Stufen:

1. Den Programmcode zu 100% nachbauen.
   
2. Hilfskonstrukte für Speicherzugriffe durch normale Speicherzugriffe ersetzten, sinnvolle Benennung und Dokumentation
   
3. Portierung der Ein-/Ausgabe auf SDL
   

Im Moment sind wir in Stufe 1.

Zu Punkt 2:

Eine kleine Ursache ist, dass einige Funktionen und Variablen noch keine sinnvollen Namen haben.
Das liegt daran, dass ich mich im Moment aus Zeitgründen nicht damit auseinandersetzen möchte,
was jede einzelne Variable bedeutet, sondern lieber Programmcode erzeuge welcher 1:1 übereinstimmt.
Die sinnvolle Namensgebung, kann dann in Ruhe im Nachgang erledigt werden.

Die Hauptursache ist, dass sämtliche Speicherzugriffe auf globale Daten und dynamisch allokierten Speicher
mittels Funktionen oder Makros durchgeführt werden.
Das wird sich, bis der Code von wirklich allen Funktionen nachgebaut ist, auch nicht ändern.

Danach können alle Zugriffe auf die globalen Daten im Quellcode leserlich gemacht werden,
indem die entsprechenden Variablen angelegt, exportiert und vom ganzen Programm benutzt werden.

Zum Beispiel: aus diesem Code, welcher einfach einen 32bit Wert kopiert...

Code:

ds_writed(SPELLUSER, ds_readd(ITEMUSER));

... wird später ...

Code:

spelluser = itemuser;

Auch verschwindet das Konvertieren von Zeigern mit Real2Host(), welches einen Zeiger in RealMode-Addressierung,
in einen Zeiger für unsere Systeme umwandelt.

Bei dynamischem Speicher kann ähnlich verfahren werden wie bei Globalem,
wobei hier noch etwas behutsamer auf korrekte Endianess geachtet werden muss
wenn Daten aus Dateien eingelesen werden.

War die Auskunft hilfreich?

[NewProggie]

Hey HenneNWH,

vielleicht wäre es ganz hilfreich ein paar Zeilen zum Aufbau und Struktur des Codes zu schreiben, so dass sich "Neue" leichter einfinden und bei dem Projekt helfen könnten.
Ich hatte mir vor einiger Zeit mal den Code angeschaut und gedacht, dass ein kleines Buildsystem evtl. ganz nett wäre (wie z.B. CMake), was auch das Bauen für die verschiedenen Betriebssysteme vereinfachen würde. Ich könnte das auch übernehmen, sofern du das als nützlich erachtest.

[HenneNWH]

Hey HenneNWH,

vielleicht wäre es ganz hilfreich ein paar Zeilen zum Aufbau und Struktur des Codes zu schreiben, so dass sich "Neue" leichter einfinden und bei dem Projekt helfen könnten.

Die Idee ist gut, ich überlege mir mal welche Informationen wichtig sind.
Was interessiert sich denn?

Ich hatte mir vor einiger Zeit mal den Code angeschaut und gedacht, dass ein kleines Buildsystem evtl. ganz nett wäre (wie z.B. CMake), was auch das Bauen für die verschiedenen Betriebssysteme vereinfachen würde. Ich könnte das auch übernehmen, sofern du das als nützlich erachtest.

Vielen Dank für das Angebot, NewProggie.

Im Moment ist Bright-Eyes ein Teil von DOSBox, welche schon GNU Autotools als Buildsystem nutzt.
Wenn es dann ohne DOSBox laufen soll, dann ist CMake eine sehr gute Wahl,
aber bis dahin wird noch viel Zeit vergehen.

[NewProggie]

Die Idee ist gut, ich überlege mir mal welche Informationen wichtig sind.
Was interessiert sich denn?

(Vielleicht steht das auch schon irgendwo und ich hab das bisher noch nicht gefunden)
Also z.B. mein bisheriger Wissensstand ist:

• DOSBox ist ein x86-Emulator, mit dem man alte DOS Spiele spielen kann.
  
• Die Sourcen zu DOSBox sind frei verfügbar.
  
• Das DSA1 Spiel liegt im Binärformat vor.
  
• Mittels großem Eifer und Reverse Engineering wurden die Offsets vieler Gegenstände, Spieler und Aktionen etc. in den Binärdateien gefunden, so dass sich z.b. mittels einem Hexeditor der Wahl auslesen und verändern lassen.
  
• Du baust nun in C++ das Spiel 1:1 nach, in dem du sämtliche Funktionen implementierst.
  

Mich würde interessieren:

• Was machst du da genau gerade? Funktionen implementieren, die die vorher erwähnten Offsets auslesen und setzen?
  
• Wieso wird DOSBox benötigt für das Nachbauen?
  
• Was spielt DOSBox hier für eine Rolle? (Theoretisch reicht doch der Aufbau der Binärdateien für z.B. Texturen, Grafiken, Spielerinfos, daher die Frage)
  
• Wie ist das Repository aufgebaut bzw. was ist die Bedeutung der einzelnen Ordner? (Viele sind auch im DOSBox Repo vorhanden bzw. identisch?)
  
• Wie ist die Nummerierung der einzelnen Sourcen zu verstehen? (z.B. g105de_seg001.cpp, g105de_seg002.cpp etc.) Wie hängen die thematisch zusammen?
  
• Was ist das große Ziel des Projekts? Vollständiger Klon von DSA1 ohne Dosbox?
  

Ich hoffe, ich erschlage dich jetzt nicht mit den vielen Fragen, aber vielleicht ist das für einige mehr hier ganz nützlich zu verstehen. Mir würde es jedenfalls helfen, um mich etwas besser zurecht zu finden im Code und auch konstruktiv mitzuhelfen.

[Rabenaas]

Ein paar der Fragen kann ich auch schon mal beantworten. Die DosBox ist nötig, weil Schick nicht in einem Rutsch neu implementiert wird, sondern Funktion für Funktion. D.h. im Moment läuft Schick in der DosBox und für einzelne, bereits neu implementierte Funktionen springt es aus der Emulation heraus in den nativen Code. Wenn alle Funktionen neu implementiert sind, ist die DosBox überflüssig.

Ansonsten ist das Werkzeug der Wahl IDA, der interaktive Disassembler.

[Shihan]

Henne, viele Dank für die Erläuterungen! Dann weiß ich ja, warum es so aussieht, wie es aussieht. Alles klar.
Hatte mir nur gedacht, dass es einfacher wäre, Deine Arbeit zu unterstützen, wenn der Code ein wenig anders aussehen würde.
Aber ich verstehe Deine Vorgehensweise!

[Rabenaas]

Wäre es vielleicht sinnvoll, BrightEyes statt auf der Vanilla-DosBox auf Daums gepatchte Sourcen aufsetzen zu lassen? http://ykhwong.x-y.net/

[Rabenaas]

Bitte gebt mir einen Account im BrightEyes-Wiki.

[Shihan]

Wäre es vielleicht sinnvoll, BrightEyes statt auf der Vanilla-DosBox auf Daums gepatchte Sourcen aufsetzen zu lassen? http://ykhwong.x-y.net/

Magst Du kurz erklären, was es damit auf sich hat? Habe noch nie davon gehört...

[Rabenaas]

Daums Version der DosBox beinhaltet einige mehr oder weniger nützliche Patches, welche die Standard-DosBox aufbrezeln. Während uns z.B. der Glide-Support herzlich egal sein kann, wären Savestates uU zum debuggen ganz nützlich.

[Obi-Wahn]

Bitte gebt mir einen Account im BrightEyes-Wiki.

Email ist an die Adresse raus, die du auch hier im Forum verwendest.

[Rabenaas]

Kthx! Bin ich schon drin, oder was...