Reverse Engineering der NLT

[Obi-Wahn]

Gibt es denn schon wieder was für github? :-D

[HenneNWH]

Im Moment grad noch nicht. Ich habe den zweiten Level der Zwingfeste fertig und bin schon im Dritten.
Es ist aber auch grad wieder Prüfungszeit, d.h. ich habe im Moment nicht soviel Zeit für Bright-Eyes.

Hast Du denn schon einen Bug gefunden?

Und hast Du schonmal was von Jenkins gehört?

[NewProggie]

Und hast Du schonmal was von Jenkins gehört?

Ich hab (beruflich und privat) mehrere Jenkins-Instanzen aufgesetzt und verwende das oft für meine Projekte. Hast du Fragen dazu?

[Obi-Wahn]

Nee, ich hatte bisher noch nicht weitergespielt, da ich hoffte, dass du mit der fertig nachgebauten Zwingsfeste um die Ecke kommst.

Jenkins, also ein Build-System, das automatisch Builds erstellt? Sollte ja auf jedem Linux-System möglich sein. Dazu müsste ich für BrightEyes/dosbox auf dem Server nur MinGW zum Laufen bringen, oder?

[NewProggie]

Jenkins, also ein Build-System, das automatisch Builds erstellt? Sollte ja auf jedem Linux-System möglich sein. Dazu müsste ich für BrightEyes/dosbox auf dem Server nur MinGW zum Laufen bringen, oder?

Jenkins ist in Java geschrieben und braucht selbst also eine JVM. Für das Projekt selbst wird dann ein C/C++ Compiler benötigt (wie MinGW, gcc, clang, ...)

[Rabenaas]

Man kann mit mingw von Linux aus nach Window cross-kompilieren, falls das die Frage ist.

[Wetzer]

Kennt ihr den?

http://xlengine.com/blog/

Der scheint auch erfolgreich Code zu extrahieren. Vielleicht interressant für DSA3?

[HenneNWH]

Auf vielfachen Wunsch einer einzelnen Person gibt es ein neues Release:

Die Zwingfeste ist jetzt komplett nachgebaut.

Bei den Reiseevents handelt es sich größtenteils um Lager-, Jagd- und Kräuterplätze und Hütten.
Die interessanten Begegnungen werde ich hier im Changelog natürlich nennen.
Reisebegegnungen, die keine Funktionalität [62] und [68] haben geben jetzt eine Meldung drüber im Log aus,
ähnlich den nicht implementierten Zaubersprüchen.

Ersetzte Funktionen (Segmente sind komplett identisch)

• seg087: dungeon thorwal 1 / 2 (Dungeonhandler)
  
• seg113: Reiseevents 5 / 10 (Schlucht[98], Harpyenangriff[99], Harpyenangriff[101])
  

Ersetzte Funktionen

• seg112: Drei Reiseevents
  

Original-Bugfix:

• seg098: Reiseevent 98: Speicherzugriffsfehler
  
• seg098: Reiseevent 99 und 101: Sinnvolle Anordnung der Flucht-Probe
  
• seg098: Reiseevent 103: Benutze Rückgabewert einer Funktion, nicht deren Adresse
  
• seg098: Reiseevent 104: Erneutes Laden des Dialogbildes nach dem Campen
  

Sonstiges:

• GCC/MSVC: Compilerwarnungen geprüft und viele davon behoben
  
• Check: Tool: dump_obj: extrahiert Instruktionen aus OBJ-Dateien
  

TODO-Liste:

• Reiseevents (viele kleine Funktionen) (noch 79)
  
• Reisemodus (noch 12)
  
• Dungeons (ein paar kleine und wenige sehr lange Funktionen) (noch 122)
  
• Check: Skripte zum Vergleichen der Binärdateien (erfordert eigenen Borland C++ 3.1 Compiler)
  

Statistik:

Es sind 1011 von 1236 Funktionen nachgebaut (81,80%).
Davon sind 985 identisch mit dem Originalcode.
Nach Byte-Metrik sind schon 80,76% (korrigiert) fertig.


Viele Spaß beim Testen,
HenneNWH


@gaor: Build-Scripte für Borland C++ sind WIP.
Für den manuellen Vergleich mehrere Dateien fehlt nur noch die DOSBox Integration.
Der Gesamtvergleich aller fertigen Dateien ist etwas aufwändiger.

Jenkins, also ein Build-System, das automatisch Builds erstellt? Sollte ja auf jedem Linux-System möglich sein. Dazu müsste ich für BrightEyes/dosbox auf dem Server nur MinGW zum Laufen bringen, oder?

Jenkins ist in Java geschrieben und braucht selbst also eine JVM. Für das Projekt selbst wird dann ein C/C++ Compiler benötigt (wie MinGW, gcc, clang, ...)

Da ich schon sehr CI-mäßig arbeite, wäre es auch sinnvoll ein CI-System zu nutzen.

Die Gnu-Compiler-Familie nutze ich ich ja selbst, aber ich werte die Warnungen auch nur selten aus.
Bei clang und MSVC noch seltener, was die hohe Anzahl an Warnungen beim Kompilieren erklärt.

Da ich zu Zeit für MSVC Virtualbox und für meine Tests QEMU nutze,
kann ich Beides nicht gleichzeitig machen.
Das soll in Virtualbox mittlerweile behoben worden sein,
aber ich möchte _noch_ kein Debian Testing installieren.

Wenn Jenkins so eingerichtet werden kann, dass MSVC damit läuft und
ich einfacher auf die BuildLog.htm zugreifen kann dann kann ich MSVC-Probleme
schneller beheben.

Andere Tools, wie cppcheck oder das Generieren einer aktuellen details.html,
sollten ja einfach zu intrigieren sein.

Kennt ihr den?

http://xlengine.com/blog/

Der scheint auch erfolgreich Code zu extrahieren. Vielleicht interressant für DSA3?

Bis jetzt noch nicht. Oh, Daggerfall. Danke für den Tipp.
Bis jetzt hat er noch keinen Quellcode veröffentlicht, weder von der Engine noch von den Tools.
Das Projekt sollte beobachtet werden.

[Obi-Wahn]

Neue Version vom 09.02.2016!
Hier die Übersicht, die Henne erstellt hat: http://bright-eyes.obiwahn.de/Bright-Eyes/details.html

[Obi-Wahn]

Danke! :-) Die Zwingfeste macht auf den ersten Schritten auch keine Probleme. Dann kann ich jetzt ja etwas testen.

[gaor]

@HenneNWH: Globale Variablen können ja inzwischen systematisch durch aussagekräftige Namen (Makros) ersetzt werden. Aber ich vermisse eine Möglichkeit, auch andere Konstanten (Makros) zu benennen, um so die Übersicht noch etwas zu verbessern. Als Beispiel: Im Kampfsystem haben die Feinde solche "sheets". Und in jedem "sheet" an Position 0x11 steht die LE und bei 0x15 die AE. Wieso führen wir da nicht globale Konstanten (Makros) FIG_SHEET_LE und FIG_SHEET_AE mit den Werten 0x11 bzw. 0x15 ein? So wäre es wesentlich einfacher, den Code zu verstehen.

[HenneNWH]

Hm, ich denke, das wäre in Ordnung.
Eigentlich wollte ich das später direkt in eine Struktur ändern und keine Zwischenänderung machen.
Aber das ist _nur reine Bequemlichkeit meinerseits_.

Ich habe gerade etwas gepusht.
Es handelt sich um die Möglichkeit innerhalb einer DOSBox den Borland-Compiler aufzurufen.

Code:

# Ins Verzeichnis wechseln
cd Bright-Eyes
# Neue Version herunterladen
git pull

# Bright-Eyes komplett neu bauen (wichtig!)
make clean
./autogen.sh
./configure
make -j4

# Deinen C-Compiler platzieren
cp -r <dein BORLANDC - Verzeichnis>/* src/custom/drive_c/BORLANDC

# ins Verzeichnis mit den Schick-Quellen wechseln
cd src/custom/schick/rewrite_m302de

# kopiere SCHICKM.EXE nach tools
cp <deine SCHICKM.EXE v3.02> ./tools/

# Disassemblies für Vergleiche erzeugen (liegen dann in temp/disasm_orig/)
cd tools
./disassemble.sh
cd ..


# Kommentar vor seg066.cpp in compile.bat entfernen
vi compile.bat

# Kompilieren und Unterschiede angucken (Original ist Links, Nachbau rechts, Suche nach '|')
./tools/bc.sh

Melde bitte ob du damit Erfolg hattest.
Dann kann ich noch den Komplett-Build vorbereiten.

@Obi: Du brauchst nicht neu zu bauen. An den Quelldateien hat sich nichts geändert.

[gaor]

Super danke, das funktioniert! Es erschließt sich mir leider nicht, was dahinter stecken könnte, dass im Original-Code das Register ah auf 0x0 gesetzt wird, obwohl die aufgerufene Funktion nur ein Byte (also den Wert von al) will. Das ist doch eigentlich das, was passiert, wenn die Funktion ein short will, aber nur ein char übergeben wird. Aber alle anderen Funktionsaufrufe dieser Funktion im Originalcode zeigen, dass die Funktion ein char will. Seltsam...

Eigentlich wollte ich das später direkt in eine Struktur ändern und keine Zwischenänderung machen.

Ja, ein struct ist natürlich an der Stelle die sinnvollste Lösung, aber das kommt ja wahrscheinlich erst in Frage, wenn alles "borlandified and identical" ist. Und bis dahin könnte man ja bereits daran arbeiten, den vorhanden Code zu "verstehen" (um beispielsweise lokale Variablen zu benennen). Zum Verständnis würden solche Bezeichnungen schon jetzt beitragen, glaube ich.

[HenneNWH]

Dann wünsche ich dir viel Spaß dabei und warte sehnsüchtigst auf deinen Pull-Request.

Die Beschreibung dieser Datenstruktur ist fast vollständig unter folgendem Link zu finden:
Charakterbögen der Feinde

In der Datei common.h habe ich auch schon eine struct enemy_sheets angelegt.
Dort könntest Du die Offsets als Aufzählung (enum) reinschreiben.
Das ist imho der sinnvollste Platz dafür.
Die common.h wird von v302de.h inkludiert und diese wiederum in allen cpp-Dateien.


Das Problem mit der get_border_index() ist folgendes:
Die ersten beiden Benutzer in seg066.cpp rufen die Funktion so auf,
als ob das Argument den Datentyp unsigned short hat.
Für alle weiteren Aufrufer wird Code erzeugt, welcher nur ein unsigned char ist.

Ich hatte schon einmal mit verschiedenen Varianten experimentiert,
aber keine zufriedenstellende Lösung gefunden.


Bis jetzt!

Ich habe bisher C-Casts verwendet. Diese wurden vom Compiler immer wegoptimiert.
Jetzt habe ich zum Casten folgendes benutzt:

Code:

static inline unsigned short cast_u16(unsigned char v) {
  return v;
}

Ergebnis: 2* Borlandified and identical

Vielen Dank, gaor!

[gaor]

Haha, wie absurd ist das denn? Ich habe mich schonmal gefragt, wofür `inline` gut ist. Da würde mich doch wirklich interessieren, wie es im Original zu dieser Konstellation kommen konnte.

Ach, tatsächlich, die common.h ist ein guter Ausgangspunkt. Da werde ich mich mal reinhängen.

[Obi-Wahn]

Ich versteh kaum ein Wort! :-D

[HenneNWH]

@Obi: Es ist mir bei zwei Funktionen bis gestern nicht gelungen diese 1:1 nachzubauen.
Der Grund dafür ist sehr technisch (Compilerbau: Codeerzeugung) und eigentlich nicht sonderlich interessant.
Wichtig ist: Es gibt jetzt nicht mehr so viele Unterschiede zum Original.

@gaor: Ich habe jetzt das andere Tool fürs Bauen aller vollständig nachgebauten Cpp-Files gepusht.

Probier es mal mit ./tools/bc_ready.sh

Ich habe die Konfigurationsdatei von DOSBox noch etwas getuned und bin nur noch wenig langsamer (~40s)
als mit meiner Qemu-Variante (~30s).
Das einzige was mich jetzt noch nervt ist das Fenster.

Bitte baue jetzt folgenden Code in deine .git/hooks/pre-commit ein, damit du nicht aus Versehen etwas kaputt machst:

Code:

# build with gcc
g++ -v 2>/dev/null >/dev/null
if [ $? -ne 0 ]; then
        echo "g++ not installed";
        exit 1
fi

#check it builds on this system
echo "Host build check"
make 2>lastbuild.log >/dev/null
if [ $? -ne 0 ]; then
        echo "Build failure";
        exit 1
fi

#check no working files are damaged
echo "DOS build check"

BAK=$PWD
cd src/custom/schick/rewrite_m302de/
./tools/bc_ready.sh
RETVAL=$?
cd $BAK

if [ $RETVAL -gt 0 ]; then
        echo "Good files were broken";
        exit 1
fi

Der hat zur Folge, dass vor jedem Commit, welchen du machst:

• make ausgeführt wird um zu prüfen ob Bright-Eyes noch gebaut werden kann
  
• alle als fertig markierten cpp-Dateien mit dem BCC-Compiler übersetzt und verglichen werden.
  

[gaor]

Das funktioniert alles hervorragend, danke dir! Das DOSBox-Fenster kannst du mit `export SDL_VIDEODRIVER=dummy` verstecken. Wenn du allerdings das, was im DOSBox-Fenster ausgegeben wird, auf die Shell umleiten willst, bin ich auch überfragt.

Ich habe jetzt für ein paar Änderungsvorschläge einen pull request mit meinem Github-Account (Name ist anders als hier) eröffnet. Falls das so einigermaßen okay ist, würde ich dann weiter solche struct Datentypen als enum in den Code einbauen.

[Rabenaas]

Man kann die Ausgaben mit '>' auf PRN umbiegen und das von DOSBox in eine Datei schreiben lassen:

Code:

[parallel]
parallel1=file append:/tmp/dosbox.prn

Mit

Code:

tail -f /tmp/dosbox.prn

bekommt man die Ausgabe in die Shell.

[HenneNWH]

Pull-Request wurde gemerged! Vielen Dank!

Die beiden DOSBox-Tipps sind auch super!
Ich hab SDL_VIDEODRIVER=dummy jetzt in meinem pre-commit hook gesetzt und
brauche auf meinem Laptop nur noch 2m, statt 2m20s.