Reverse Engineering der NLT II

[Obi-Wahn]

Für diejenigen, die es selbst mal testen wollen, hier die Exe. Es fehlt dann nur noch die DSAGEN.DAT.


  ngen_gcc.zip (Größe: 184,65 KB / Downloads: 0)

[HenneNWH]

Hab gerade experimentellen Maus-Support gepusht. Einen Charakter hab ich auch gerade erstellt. Es sieht schon gut aus.

[Obi-Wahn]

Super, probiere ich morgen aus.

[HenneNWH]

Dazu bitte keine Issues erstellen, daran arbeite ich gerade aktiv und bemühe mich erstmal um eine funktionierende
anschließend um eine zufriedenstellende Lösung. Die beiden Issues die du erstellt hast waren in Ordnung.

[Obi-Wahn]

Das Kompilieren funktioniert und die Maus geht auch ... irgendwie. Es geht voran!

Es gibt noch ein Problem beim Logo von Fantasy Productions. Das wird bei mir unter Windows verfälscht ausgegeben, siehe Screenshot.
   

[NewProggie]

Das Kompilieren funktioniert und die Maus geht auch ... irgendwie. Es geht voran!

Es gibt noch ein Problem beim Logo von Fantasy Productions. Das wird bei mir unter Windows verfälscht ausgegeben, siehe Screenshot.

Sieht aus wie RGB -> BGR (bzw. LE -> BE)

[HenneNWH]

Okay, das Bild sieht schon mal gut aus, nur die Farben stimmen nicht.
Zum Vergleichen hab ich mal die Farbpalette unter Linux ausgegeben.
Ich comitte das gleich mal.

So sollte es aussehen:
FANPRO.NVF length = 3401
# 00 = (00, 00, 00)
# 01 = (38, 2c, 30)
# 02 = (38, 28, 2c)
# 03 = (38, 24, 2c)
# 04 = (34, 1c, 24)
# 05 = (30, 14, 1c)
# 06 = (30, 0c, 14)
# 07 = (2c, 04, 10)
# 08 = (28, 04, 04)
# 09 = (24, 04, 04)
# 0a = (1c, 00, 00)
# 0b = (18, 00, 00)
# 0c = (10, 00, 00)
# 0d = (0c, 00, 00)
# 0e = (04, 00, 00)
# 0f = (04, 04, 04)
# 10 = (04, 04, 04)
# 11 = (08, 08, 08)
# 12 = (0c, 0c, 0c)
# 13 = (10, 10, 10)
# 14 = (14, 14, 14)
# 15 = (18, 18, 18)
# 16 = (1c, 1c, 1c)
# 17 = (20, 20, 20)
# 18 = (24, 24, 24)
# 19 = (28, 28, 28)
# 1a = (2c, 2c, 2c)
# 1b = (30, 30, 30)
# 1c = (34, 34, 34)
# 1d = (38, 38, 38)
# 1e = (3c, 3c, 3c)
# 1f = (3c, 3c, 3c)

[Obi-Wahn]

Die Ausgabe sieht bei mir so aus:

.\ngen_gcc.exe
DSAGEN.DAT DE_CD
FANPRO.NVF length = 587
# 00 = (03, 02, 04)
# 01 = (4d, 9b, d8)
# 02 = (c6, 80, ca)
# 03 = (68, 9e, 3f)
# 04 = (0a, 6f, c4)
# 05 = (18, 20, 1e)
# 06 = (18, 2d, c6)
# 07 = (23, ff, ff)
# 08 = (ff, ff, ff)
# 09 = (ff, ff, ff)
# 0a = (e9, 31, e4)
# 0b = (4c, 3d, 8c)
# 0c = (94, 08, 24)
# 0d = (ec, 7f, 71)
# 0e = (87, 54, 8d)
# 0f = (05, c4, 02)
# 10 = (87, bb, f7)
# 11 = (ff, ff, ff)
# 12 = (ff, ff, ff)
# 13 = (ff, ff, 93)
# 14 = (0f, 69, 98)
# 15 = (0a, 12, 63)
# 16 = (e7, 84, 8b)
# 17 = (93, 3f, fe)
# 18 = (35, 53, d4)
# 19 = (81, e1, 03)
# 1a = (80, d3, d4)
# 1b = (a8, 01, ff)
# 1c = (ff, ff, ff)
# 1d = (ff, ff, ff)
# 1e = (ff, f1, 30)
# 1f = (e2, 00, 4c)

[NewProggie]

Die Ausgabe sieht bei mir so aus:

.\ngen_gcc.exe
DSAGEN.DAT DE_CD
FANPRO.NVF length = 587
# 00 = (03, 02, 04)
# 01 = (4d, 9b, d8)
# 02 = (c6, 80, ca)
# 03 = (68, 9e, 3f)
# 04 = (0a, 6f, c4)
# 05 = (18, 20, 1e)
# 06 = (18, 2d, c6)
# 07 = (23, ff, ff)
# 08 = (ff, ff, ff)
# 09 = (ff, ff, ff)
# 0a = (e9, 31, e4)
# 0b = (4c, 3d, 8c)
# 0c = (94, 08, 24)
# 0d = (ec, 7f, 71)
# 0e = (87, 54, 8d)
# 0f = (05, c4, 02)
# 10 = (87, bb, f7)
# 11 = (ff, ff, ff)
# 12 = (ff, ff, ff)
# 13 = (ff, ff, 93)
# 14 = (0f, 69, 98)
# 15 = (0a, 12, 63)
# 16 = (e7, 84, 8b)
# 17 = (93, 3f, fe)
# 18 = (35, 53, d4)
# 19 = (81, e1, 03)
# 1a = (80, d3, d4)
# 1b = (a8, 01, ff)
# 1c = (ff, ff, ff)
# 1d = (ff, ff, ff)
# 1e = (ff, f1, 30)
# 1f = (e2, 00, 4c)

Die Länge stimmt nicht überein. Wird das vielleicht in ASCII/Text Modus geladen, statt in binary?

[HenneNWH]

Das sieht nicht gut aus. Hab gerade noch eine Änderung dazu gemacht. Vielleicht hilfts.

[Obi-Wahn]

Code:

$ make
gcc -O0 -g -fno-asm -c cda_code.c
gcc -O0 -g -fno-asm -c ngen.c
gcc -O0 -g -fno-asm -c powerp20.c
gcc -O0 -g -fno-asm -c vgalib.c
gcc -O0 -g -fno-asm -c ail_stub.c
gcc -O0 -g -fno-asm -o ngen_gcc cda_code.o ngen.o powerp20.o vgalib.o ail_stub.o -lSDL2
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ngen.o: in function `open_datfile':
C:/msys64/home/tobia/BrightEyes/src/gen/ngen.c:2550:(.text+0x1e45): undefined reference to `flushall'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:5: gen] Error 1

[HenneNWH]

Und nochmal!

[NewProggie]

Code:

$ make
gcc -O0 -g -fno-asm -c cda_code.c
gcc -O0 -g -fno-asm -c ngen.c
gcc -O0 -g -fno-asm -c powerp20.c
gcc -O0 -g -fno-asm -c vgalib.c
gcc -O0 -g -fno-asm -c ail_stub.c
gcc -O0 -g -fno-asm -o ngen_gcc cda_code.o ngen.o powerp20.o vgalib.o ail_stub.o -lSDL2
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: ngen.o: in function `open_datfile':
C:/msys64/home/tobia/BrightEyes/src/gen/ngen.c:2550:(.text+0x1e45): undefined reference to `flushall'
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:5: gen] Error 1

_flushall() (mit <Windows.h> ?

[Obi-Wahn]

Jetzt funktioniert es und alles sieht richtig aus.


  ngen_gcc_2024_04_28.zip (Größe: 187,23 KB / Downloads: 0)

Code:

.\ngen_gcc.exe
DSAGEN.DAT DE_CD
FANPRO.NVF length = 3401
# 00 = (00, 00, 00)
# 01 = (38, 2c, 30)
# 02 = (38, 28, 2c)
# 03 = (38, 24, 2c)
# 04 = (34, 1c, 24)
# 05 = (30, 14, 1c)
# 06 = (30, 0c, 14)
# 07 = (2c, 04, 10)
# 08 = (28, 04, 04)
# 09 = (24, 04, 04)
# 0a = (1c, 00, 00)
# 0b = (18, 00, 00)
# 0c = (10, 00, 00)
# 0d = (0c, 00, 00)
# 0e = (04, 00, 00)
# 0f = (04, 04, 04)
# 10 = (04, 04, 04)
# 11 = (08, 08, 08)
# 12 = (0c, 0c, 0c)
# 13 = (10, 10, 10)
# 14 = (14, 14, 14)
# 15 = (18, 18, 18)
# 16 = (1c, 1c, 1c)
# 17 = (20, 20, 20)
# 18 = (24, 24, 24)
# 19 = (28, 28, 28)
# 1a = (2c, 2c, 2c)
# 1b = (30, 30, 30)
# 1c = (34, 34, 34)
# 1d = (38, 38, 38)
# 1e = (3c, 3c, 3c)
# 1f = (3c, 3c, 3c)

[HenneNWH]

_flushall() (mit <Windows.h> ?

Das _flushall() halte ich für fehl am Platz, da das einzigen was geschrieben wird, die CHR-Datei ist.
Für den BCC lass ich es noch drin. Falls es später noch zu Problemen kommen sollte überleg ich mir etwas.
Danke für die Tipps und Obi-Wahn fürs melden!

[Obi-Wahn]

Ich vermute, eine der (beiden?) letzten Änderungen hat etwas verschlimmbessert. Das Kompilieren läuft durch, aber das Programm startet nicht mehr:

Code:

tobia@Tobias-AMD MINGW64 ~/BrightEyes/src/gen
$ make
gcc -O0 -g -fno-asm -c cda_code.c
gcc -O0 -g -fno-asm -c ngen.c
gcc -O0 -g -fno-asm -c powerp20.c
gcc -O0 -g -fno-asm -c vgalib.c
gcc -O0 -g -fno-asm -c ail_stub.c
gcc -O0 -g -fno-asm -o ngen_gcc cda_code.o ngen.o powerp20.o vgalib.o ail_stub.o -lSDL2

tobia@Tobias-AMD MINGW64 ~/BrightEyes/src/gen
$ ./ngen_gcc.exe
Segmentation fault

[HenneNWH]

@Obi-Wahn: Hast du schonmal mit GIT den Projektzustand zurückgespult?
Probier mal:

Code:

git checkout 00b5f43cf54cb1f9ef4164c8bf114e0a61cef959
<COMPILIEREN und TESTEN>
git checkout cf22d73d8da8fc4481a1878f919a671e0b59f790
<COMPILIEREN und TESTEN>
git checkout e507d576ca716fac81e31a48b6e4f52654ba91af
<COMPILIEREN und TESTEN>

ich benötige die letzte Commitnummer bei der es funktioniert hat und die erste bei der es nicht funktioniert hat.

[siebenstreich]

Glückwunsch! Was ist denn mit den 12 verbleibenden Bytes, warum geht das nicht besser? Ist davon auszugehen, dass auch Attic hier mit Assembler-Code gearbetet hat?

Nope, das ist genau eine Zeile in C. Damit muss ich leben! :-D

Es ist ja eigentlich kaum zu glauben, dass du das Kunststück fertig bekommst, den gesamten Programmcode in C zu rekonstruieren, abgesehen von einer Zeile. Gewissermaßen das eine gallische Asterix-Dorf des Charaktergenerators. Hast du Lust, zu dieser Zeile ein paar Details zu nennen? Vielleicht hat ja jemand anderer noch eine Idee dazu.

Hab gerade experimentellen Maus-Support gepusht. Einen Charakter hab ich auch gerade erstellt. Es sieht schon gut aus.

Funktioniert bei mir auch. Beeindruckend!

Folgende Dinge sind mir aufgefallen:

• Grafik-Ausgabe in Briefmarkengröße (klar, damals hatten Monitore noch eine etwas kleinere Auflösung).
  
• Ziemlich zäher Grafik-Aufbau (hast du ja selber weiter oben angesprochen).
  
• Der erzeugte Charakter hat unter Linux die Permissions 0, ist also a priori weder les- noch schreibbar.
  

[siebenstreich]

Noch eine andere Sache: Motiviert durch die neuesten Entwicklungen hab ich in ein wenig an meinem Bright-Eyes Fork weitergemacht.
Beispielsweise habe ich gesucht, wodurch dieser Fehler

- Wenn man von Overthorn nach Hjalsingor übersetzt und den Hafen in Hjalsingor verläßt, steht man nicht, wie es zu erwarten wäre, auf dem Feld vor dem Hafen, sondern ein ganzes Stück entfernt in der Butnik, nämlich 2 Felder nördlich und 1 westlich der Kräuterhändlerin "Lialin Waskir". Ob das auch passiert, wenn man von woanders kommt und ob das nach Ankunft von Overethorn wirklich in 100% der Fälle passiert, ist derzeit noch offen.

verursacht wird.

Ich denke, im Datensegment passt was nicht, siehe diesen Commit.
Allerdings kann ich den Fix nicht testen: Ich habe den Verdacht, dass die Daten in datseg.cpp keinen Eingang in das (mit dem gcc) compilierte dosbox-Binary finden.

Deswegen meine Frage: Woher kommt das Datensegment, wenn ich Bright-Eyes (mit Bindestrich!) mit make übersetze?

EDIT: Eigentlich kann ich es mir denken. Ich starte mit dem compilierten Bright-Eyes-Dosbox-Binary die originale SCHICKM.EXE, und deren Datensegment kommt dann vermutlich zum Einsatz...

[HenneNWH]

Ich habe den Verdacht, dass die Daten in datseg.cpp keinen Eingang in das (mit dem gcc) compilierte dosbox-Binary finden.



Deswegen meine Frage: Woher kommt das Datensegment, wenn ich Bright-Eyes (mit Bindestrich!) mit make übersetze?

Das ist absolut korrekt. In Bright-Eyes kommt das Datensegment direkt aus der EXE-Datei des Spiels.
Wenn man das Spiel neu startet, werden die dort vorhandenen Daten neu initialisiert.
Würde man ein eigenes Datensegment in Bright-Eyes hinzufügen, wären die Daten nach einem Neustart der EXE inkonsistent und das würde mit Sicherheit in merkwürdigem Verhalten und damit einhergehenden Irritationen resultieren.
Das habe ich vermieden, indem sich Bright-Eyes beim Beenden des Spiels komplett beendet.
Somit bleibt alles sauber.
Der richtige Weg für die SCHICKM.EXE ist, irgendwann in Phase 2 überzugehen,
den Code von Bright-Eyes nach BrightEyes zu kopieren und das Datensegment dort separat nachzubauen.
Das passiert allerdings erst, wenn alle Ungereimtheiten mit NGEN.EXE zufriedenstellend gelöst sind.
Das Projekt ist immerhin ein von mir initiierter Lernprozess.

Die Punkte, die du angesprochen hast sind mir bekannt.
Die Tastatureingabe habe ich gestern vorerst zufriedenstellend lösen können.
An der Grafik (Fenstergröße + Geschwindigkeit) arbeite ich gerade und denke, dass da heute noch etwas kommt.
Die Dateirechte der CHR-Dateien sind etwas, wofür ich das Feedback von Obi-Wahn aus der Windows-Welt brauche.

Noch etwas nebenbei:
DOS-Anwendungen haben damals sämtliche Ressourcen des Rechners für sich beansprucht.
Das ging damals nicht anders und äußert sich aktuell in einer sehr hohen CPU-Auslastung.
Diese habe ich mit ein paar geschickt gesetzten SDL_Delays() etwas abmildern können,
bin mir aber sicher, dass mir dazu auch noch eine bessere Lösung einfällt.
An der Grafikausgabe arbeite ich gerade.