Reverse Engineering der NLT II

[wiese.hano]

Prima erklärt, siebenstreich. Danke! Wieviel Stellen sind noch zu ändern?

[aeyol]

Falls ich grad mal eine kurze Zwischenfrage stellen darf:

Was mich an Schicksalsklinge am meisten nervt, ist die Passwortabfrage bei Spielstart. Ließe die sich mittels Bright Eyes umgehen (und ist das evtl sogar schon der Fall)?

[Obi-Wahn]

Falls ich grad mal eine kurze Zwischenfrage stellen darf:

Was mich an Schicksalsklinge am meisten nervt, ist die Passwortabfrage bei Spielstart. Ließe die sich mittels Bright Eyes umgehen (und ist das evtl sogar schon der Fall)?

Ja, die Passwortabfrage ist bei Bright Eyes deaktiviert. Zum Glück.

[aeyol]

Sehr schön, danke für die Info. Dann richte ich mir das wohl doch mal wieder ein.

[siebenstreich]

Prima erklärt, siebenstreich. Danke! Wieviel Stellen sind noch zu ändern?

sehr viele...

[siebenstreich]

Sehr schön, danke für die Info. Dann richte ich mir das wohl doch mal wieder ein.

Für den Fall, dass du den Quellcode selbst compilierst, könntest du auch das BrightEyes aus meinem Fork nehmen (und Probleme gerne melden). Da sind ein paar zusätzliche Bugs repariert. Z.B. werden Talent- und Zaubersteigerungen nach den originalen DSA3-Regeln durchgeführt (und nicht nach der etwas verkorksten Interpretation der Attic-Programmierer).

Ich hätte das ganze ja sehr gerne wieder im originalen BrightEyes drin, aber bisher ist auf meine Anfrage hin nichts passiert.

[aeyol]

Ich fürchte, zum selbst kompilieren (auch wenn ich das durchaus gern probieren würde), bräuchte ich ein kleines HowTo.

[Obi-Wahn]

Ich fürchte, zum selbst kompilieren (auch wenn ich das durchaus gern probieren würde), bräuchte ich ein kleines HowTo.

An sich kannst du dich an die Anleitungen halten, die ich im Download-Thread verlinkt habe.

https://www.crystals-dsa-foren.de/showth...p?tid=3911


Das letzte Kompilieren ist bei mir aber auch schon drei Jahre her....
Ich kann nichts versprechen, aber ich gucke mir mal die Tage siebenstreichs Fork an und versuche die Kompilierstraße wieder ans Laufen zu bringen. Wo war nochmal der Compiler???

[aeyol]

Perfekt, schau ich mir an. Danke.

[siebenstreich]

Ich kann euch nur sagen wie man es mit Linux macht. Man lädt den Quellcode herunter (in github auf den grünen Code-Knopf drücken und dann "download ZIP"), entpackt das, geht in einem Terminal in entsprechende Verzeichnis und lässt die 3 Befehle
./autogen.sh
./configure
make
durchlaufen. Danach liegt unter
src/dosbox
die BrightEyes-Dosbox.

[Obi-Wahn]

Das wahre Drama unter Windows und vielleicht auch unter Linux sind die Abhängigkeiten. Dosbox mag keine zu neuen Versionen von SDL und co. Aber wie gesagt, ist schon etwas her...

[siebenstreich]

ok, davor bin ich wohl verschont geblieben. Das Problem könnte sein, dass BrightEyes zugrundeliegende Dosbox-Version mittlerweile auch schon ein paar Jahre auf dem Buckel hat.

[Obi-Wahn]

Nope, leider bekomme ich keinen sauberen Build mehr hin. Auch mit dem Original-Code von Henne und Visual Studio 2008 Express Edition. (Mit Visual Studio 2019 bekomme ich Probleme mit Code-Änderungen in SDL...)

Ich weiß auch nicht, ob der Fehler bei mir liegt oder im Code. Der BuildLog ist im Anhang.

[Borbaradwurm]

Nope, leider bekomme ich keinen sauberen Build mehr hin. Auch mit dem Original-Code von Henne und Visual Studio 2008 Express Edition. (Mit Visual Studio 2019 bekomme ich Probleme mit Code-Änderungen in SDL...)

Ich weiß auch nicht, ob der Fehler bei mir liegt oder im Code. Der BuildLog ist im Anhang.

Schuss ins Blaue (da ich momentan keine Windows Kiste habe): Im VC++ Projekt wird die datei datseq.cpp übersetzt, die wird aber von seg002.cpp inkludiert, daher wird die datei zweimal übersetzt und beim linken wird dann abgebrochen weil die Definitionen von datseg.cpp in zwei Objektdateien stehen.

Versuche mal die Datei datseg.cpp aus dem VC++ Projekt zu entfernen (d.h. nur aus der Liste der zu kompilierenen Dateien, nicht aus dem Projektverzeichnis im Dateisystem).

[aeyol]

Ich habe hier auch Visual Studio 2019 installiert und möchte mir hier ungern durch die Installation älterer Versionen das System zumüllen oder gar zerschießen. Also werde ich wohl vorerst mit den bereits existierenden, wenn auch veralteten Builds arbeiten.

Wünsche Euch aber viel Erfolg

[Obi-Wahn]

Ich habe hier auch Visual Studio 2019 installiert und möchte mir hier ungern durch die Installation älterer Versionen das System zumüllen oder gar zerschießen. Also werde ich wohl vorerst mit den bereits existierenden, wenn auch veralteten Builds arbeiten.

Wünsche Euch aber viel Erfolg

Theoretisch sollte es mit Visual Studio 2019 einfacher gehen. Wenn du SDL 1.2.15 damit kompilieren kannst....

[Rabenaas]

Versuche mal die Datei datseg.cpp aus dem VC++ Projekt zu entfernen (d.h. nur aus der Liste der zu kompilierenen Dateien, nicht aus dem Projektverzeichnis im Dateisystem).

...oder schreib

Code:

#pragma once

in die Datei.

[Borbaradwurm]

...oder schreib

Code:

#pragma once

in die Datei.

Das funktioniert aber nicht mit dem alten Borland C++ Compiler der den Bright Eyes Sourcecode auch übersetzten soll. Annsonnsten: Sourceode nur dann für Eigenheiten eines einzelnen Compiler ändern wenn es absolut notwending ist, und das ist hier nicht der Fall.

[siebenstreich]

Genau, man kann einzelne C-Quellcode-Dateien getrennt voneinander kompilieren. In Bright-Eyes sind die nötigen Befehle bzw. Skripte dafür enthalten. Aber der Compiler selbst (BCC.EXE) ist nicht in Bright-Eyes enthalten, weil er proprietär lizensiert ist.

Den Compiler habe ich gerade gefunden. gaor, kannst du mir sagen wie ich jetzt am besten vorgehe? Also wohin welche Dateien des Compilers müssen und welches Skript ich (vermutlich via dosbox) starten muss? Danke!

[gaor]

Henne hatte in mehreren Beiträgen beschrieben, wie das geht (https://www.crystals-dsa-foren.de/showth...#pid145112 und https://www.crystals-dsa-foren.de/showth...#pid145120). Ich gebe es hier mal zusammengefasst wieder:

1. Stelle sicher, dass Bright-Eyes einmalig auf dem gewöhnlichen Wege erfolgreich kompiliert vorliegt:
   Code:

   make clean && ./autogen.sh && ./configure && make -j4
2. Die BCC-Dateien müssen in das Verzeichnis src/custom/drive_c/BORLANDC/, sodass die BCC.EXE in src/custom/drive_c/BORLANDC/BIN/BCC.EXE landet.
   
3. Die Original SCHICKM.EXE muss in das Verzeichnis src/custom/schick/rewrite_m302de/tools/.
   
4. Einmalig muss dann das Skript disassemble.sh ausgeführt werden:
   Code:

   cd src/custom/schick/rewrite_m302de/tools/ && ./disassemble.sh
5. Einzelne cpp-Dateien kannst du kompilieren und manuell auf Binärkompatibilität prüfen, indem du die entsprechende Zeile in src/custom/schick/rewrite_m302de/compile.bat auskommentierst und anschließend bc.sh ausführst:
   Code:

   cd src/custom/schick/rewrite_m302de && ./tools/bc.sh
6. Am praktischsten ist aber das pre-commit-Skript, das checkt, dass die Binärkompatibilität nicht kaputt gegangen ist. Den folgenden Code packst du in die Datei .git/hooks/pre-commit und machst sie mit chmod +x .git/hooks/pre-commit ausführbar:
   Code:

   #!/bin/sh

# 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/
SDL_VIDEODRIVER=dummy ./tools/bc_ready.sh
RETVAL=$?
cd $BAK

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

exit 0