Reverse Engineering der NLT

[gaor]

Ich muss sagen, dass ich durch die Speicherverwaltung nicht durchsteige (Gut, ich habe zugegebenermaßen auch sonst keine Erfahrung mit der Speicherverwaltung von Computerspielen, schon gar nicht mit DOS-Spielen.)

Es wird in Segment 120 in `init_global_buffer` eine Vielzahl von Buffern von unterschiedlicher Größe angelegt. Und von diesen wird ein und derselbe Buffer anscheinend gar nicht für einen einheitlichen Zweck verwendet, sondern an der einen Stelle im Code als Zwischenspeicher für Text, woanders für Grafik-Daten, für Kampfdaten, für Monster-Datenblätter, ...

Gibt's da irgendein System, das ich übersehe?

[Obi-Wahn]

Lohnt es sich, einen neuen Build zu bauen?

[gaor]

Nein, ich habe nur einen Haufen Zeug im Code anders ausgedrückt, um die Code-Lesbarkeit etwas zu verbessern. Das Kompilat bleibt dadurch völlig unverändert.

@HenneNWH: Da bin ich auch weiterhin dran. Habe noch eine ganze Menge Veränderungen in diese Richtung in der Schublade und bin selbst sehr zufrieden damit, wie sehr es wirklich die Lesbarkeit verbessert. Wenn du das auch so siehst, werden demnächst noch weitere pull requests kommen. Sehr praktisch ist, dass man mit deinem pre-commit-Skript immer sicherstellen kann, dass man nichts kaputtmacht - die commits für meine Änderungen sind nämlich sehr unübersichtlich, weil das ja automatisiertes Suchen-Und-Ersetzen ist.

[HenneNWH]

Ich muss sagen, dass ich durch die Speicherverwaltung nicht durchsteige (Gut, ich habe zugegebenermaßen auch sonst keine Erfahrung mit der Speicherverwaltung von Computerspielen, schon gar nicht mit DOS-Spielen.)

Es wird in Segment 120 in `init_global_buffer` eine Vielzahl von Buffern von unterschiedlicher Größe angelegt. Und von diesen wird ein und derselbe Buffer anscheinend gar nicht für einen einheitlichen Zweck verwendet, sondern an der einen Stelle im Code als Zwischenspeicher für Text, woanders für Grafik-Daten, für Kampfdaten, für Monster-Datenblätter, ...

Gibt's da irgendein System, das ich übersehe?

Das System hab ich auch noch nicht verstanden.
Es gibt ein paar kleine Buffer für Daten die häufig benötigt werden und einen großen Buffer
für "Den Rest". Für den Zugriff auf den großen Buffer wurden auch viele Zeiger angelegt.
Ich denke das dieses System mit der Kenntniss der Eingabedaten erdacht wurde.
Denn: "640k müssten such genug sein."

Nein, ich habe nur einen Haufen Zeug im Code anders ausgedrückt, um die Code-Lesbarkeit etwas zu verbessern. Das Kompilat bleibt dadurch völlig unverändert.

Genau. Ich werde diese Woche noch einige Reiseevents pushen.
Habe heute die Greifenwiese und die erste Begegnung mit dem Einhorn fertiggestellt.
Neun weitere sollen noch folgen, damit seg118 noch fertig ist.

@HenneNWH: Da bin ich auch weiterhin dran. Habe noch eine ganze Menge Veränderungen in diese Richtung in der Schublade und bin selbst sehr zufrieden damit, wie sehr es wirklich die Lesbarkeit verbessert. Wenn du das auch so siehst, werden demnächst noch weitere pull requests kommen.

Ich bin sehr zufrieden mit deinen Patches. Weiter so. Immer her damit.

[HenneNWH]

Neuer Monat, neues Release:

Erstmal vielen Dank an gaor!
Er hat sich in den letzten Wochen der Arbeit gestellt,
die vielen magischen Zahlen im Quelltext durch aussagekräftige Bezeichner zu ersetzten.
Jetzt ist vieles sehr viel lesbarer und die Semantik des Quellcodes wird viel klarer.


Ersetzte Funktionen (Segmente sind komplett identisch)

• seg112: Reiseevents 4 / 10 (Ork-Monolit[71], Leiche mit Einhornbrief[73], Wegelagerer[74][77])
  
• seg118: Reiseevents 10 / 10 (Greifenwiese[37], Erstbegegnung Einhorn[38])
  

Original-Bugfix:

• seg118: Reiseevent 78: Erneutes Laden des Dialogbildes nach dem Campen
  
• seg118: Reiseevent 124: Nur eine unglückliche Probe verläuft tötlich
  

Sonstiges:

• GCC/MSVC: Compilerwarnungen geprüft und viele davon behoben
  
• Magic-Numbers durch aussagekräftige Namen ersetzt
  

TODO-Liste:

• Reiseevents (viele kleine Funktionen) (noch 58)
  
• Reisemodus (noch 12)
  
• Dungeons (ein paar kleine und wenige sehr lange Funktionen) (noch 122)
  

Statistik:

Es sind 1032 von 1236 Funktionen nachgebaut (83,50%).
Davon sind 1008 identisch mit dem Originalcode.
Nach Byte-Metrik sind schon 81,55% (korrigiert) fertig.


Viele Spaß beim Testen,
HenneNWH

[Obi-Wahn]

Neue Version vom 08.03.2016!

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

Am Wochenende will ich testweise einen Twitch-Stream machen. Mal gucken, ob das klappt.

[Rabenaas]

Cool! Was ist ein Twitch-Stream?

[Alpha Zen]

Twitch ist eine Streaming-Plattform. Im Grunde dafür gedacht, dass Leute ins Internet streamen, wie sie etwas spielen, aber es wird für alles mögliche genutzt. Unter anderem von den Rocketbeans (die Macher von Game One... damals), die da ihren 24h-Internetsender streamen.

[Obi-Wahn]

@Alpha: Genau.

Aus dem Stream ist leider nichts geworden... Ich lag krank und platt im Bett. Aber rein technisch sollte es funktionieren. Einen kleinen Test habe ich machen können.

[HenneNWH]

Erstmalig gibt es ein Oster-Release von Bright-Ei:

Ein Meilenstein wurde erreicht, denn ich konnte heute das gesamte Reisesystem komplett abschließen.
Jetzt kann ich mich ausschließlich auch die Dungeons konzentrieren.

Nocheinmal vielen Dank an gaor für die vielen, vielen Patches und die bisherige gute Zusammenarbeit!


Ersetzte Funktionen (Segmente sind komplett identisch)

• seg093: Reisemodus
  
• seg094: Reisemodus
  
• seg110: Reiseevents 2 / 10 (Verfallene Herberge[46])
  
• seg114: Reiseevents 6 / 10 (Steinwand[110],FIRUN-Tempel[113],Sumpf[114], Wolfangrif[122], Brücke[123])
  

Sonstiges:

• Weitere Magic-Numbers durch aussagekräftige Namen ersetzt
  

TODO-Liste:

• Dungeons (ein paar kleine und wenige sehr lange Funktionen) (noch 122)
  

Statistik:

Es sind 1101 von 1237 Funktionen nachgebaut (89,01%).
Davon sind 1077 identisch mit dem Originalcode.
Nach Byte-Metrik sind schon 85,90% (korrigiert) fertig.


Viele Spaß beim Testen,
HenneNWH

[Obi-Wahn]

Neue Version vom 25.03.2016!

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

[Obi-Wahn]

Das Wiki ist auf eine neuere Version geupdatet worden: http://bright-eyes.obiwahn.de/

Soweit funktioniert noch alles?!

[Obi-Wahn]

NRS hat in seinem Patch viele Bugs behoben. Welche sind davon denn schon in Bright-Eyes behoben?

[NRS]

Ich habe das Git-Repositorium mal heruntergeladen und nach M302de_ORIGINAL_BUGFIX durchsucht. Von den Korrekturen meines Patches ist demnach in Brighteyes nur "Meister Dramosch bezahlt Vorauszahlung mehr als einmal" berücksichtigt (sogar auf ähnliche Weise, wobei es im Quellcode natürlich eleganter aussieht). Umgekehrt sind alle anderen "original bugfixes" aus BrightEyes in meinem Patch noch nicht berücksichtigt. Ich werde mal sehen, wie viele davon ich, zusammen mit den von Zurgrimm angemerkten, in meinen Patch noch integrieren kann. Wo nur ein Wert anders abzufragen ist (z.B. hier), dürfte das kein Problem sein; wenn dagegen mehrere Codezeilen am Stück einzufügen sind, so ist das auf Binärebene (d.h. ohne Quellcode neu zu kompilieren) zwar durchaus möglich, aber mühselig und damit relativ zum Ertrag zu entscheiden. Ein bisschen negativ stößt mir auf, in BrightEyes Schreibfehler in den .LTX-Dateien aus SCHICK.DAT als Teil des Programmcodes auszubügeln --- hier würde ich entsprechend entsprechend die .LTX-Dateien selbst modifizieren und SCHICK.DAT entsprechend neu aufbauen, wie ich es ja bereits getan habe.

[Wetzer]

Wenn ich das richtig verstehe, patched NRS direkt in den Original-Dateien. Diese "NRS-Version" von Schick kann aber nicht mit Bright Eyes benutzt werden, oder?

@NRS: Ich glaube der Grund warum nicht direkt in den Originaldateien (außer der Exe) gepatched wird ist, dass der Originalcode dokumentiert werden soll (und nebenbei kann man dann die Fehler auch ausbügeln, ohne die Spieldateien zu verändern).

Ich würde mich natürlich freuen, wenn die Erkentnisse von NRS in die BrightEyes-Version einfließen könnten.

[gaor]

Ich glaube, im Bright-Eyes-Repository sollen aus Lizenzgründen keine Original-Dateien aus dem Spiel gehostet werden, also auch keine modifizierte SCHICK.DAT. Man könnte allerdings eine Art diff von der SCHICK.DAT erstellen und die dann in der Funktion load_archive_file dazwischenschalten, damit einzelne Werte on-the-fly manipuliert/korrigiert werden können. Ich kann mir aber vorstellen, dass das etwas aufwendiger wäre, als es sich anhört.

[NRS]

Diese "NRS-Version" von Schick kann aber nicht mit Bright Eyes benutzt werden, oder?

Ich wüsste nicht, warum das nicht gehen sollte, wenn Du mit "benutzen" meinst, dass ein BrightEyes-Kompilat mit meiner korrigierten SCHICK.DAT verwendet wird. Die Reihenfolge der Dateien in SCHICK.DAT bleibt ja gleich; es ändern sich nur die Offsets, die nicht in SCHICKM.EXE sondern am Anfang von SCHICK.DAT vermerkt sind.

[NRS]

In seg119.cpp heißt es ab Zeile 321:

Code:

            /* PARALYSIS / PARALYSE: get better */
            if (host_readbs(disease_ptr) == 1) {

                if (!host_readbs(disease_ptr + 2) && !host_readbs(disease_ptr + 3)) {
                    host_writebs(disease_ptr + 1, 0);
                    host_writebs(disease_ptr, 0);
                } else {

                    if (!host_readbs(disease_ptr + 2)) {
                        sprintf((char*)Real2Host(ds_readd(DTP2)),
                            (char*)get_ltx(0x8f4),
                            (char*)Real2Host(hero) + HERO_NAME2);

                        GUI_output(Real2Host(ds_readd(DTP2)));

                        dec_ptr_bs(disease_ptr + 2);
                        inc_ptr_bs(Real2Host(hero) + HERO_KK);
                    }

                    if (!host_readbs(disease_ptr + 3)) {
                        sprintf((char*)Real2Host(ds_readd(DTP2)),
                            (char*)get_ltx(0x908),
                            (char*)Real2Host(hero) + HERO_NAME2);

                        GUI_output(Real2Host(ds_readd(DTP2)));

                        dec_ptr_bs(disease_ptr + 3);
                        inc_ptr_bs(Real2Host(hero) + HERO_GE);
                    }
                }
            }

Ist das ! in Zeile 329 und 340 nicht jeweils falsch (im Spiel, habe verifiziert, dass das in SCHICKM.EXE auch wirklich so ist)? "disease_ptr+2" hält ja die Zahl der reduzierten KK-Punkte, und im Falle der Remission muss KK erhöht und diese Variable erniedrigt werden, so lange sie nicht Null ist. Im Moment ist mir anhand des Codes wie er ist nämlich nicht klar, wie man nach einer kurierten Paralyse seine KK und GE wieder bekommen soll. Das gleiche bei Frostschäden.

[Wetzer]

Diese "NRS-Version" von Schick kann aber nicht mit Bright Eyes benutzt werden, oder?

Ich wüsste nicht, warum das nicht gehen sollte, wenn Du mit "benutzen" meinst, dass ein BrightEyes-Kompilat mit meiner korrigierten SCHICK.DAT verwendet wird. Die Reihenfolge der Dateien in SCHICK.DAT bleibt ja gleich; es ändern sich nur die Offsets, die nicht in SCHICKM.EXE sondern am Anfang von SCHICK.DAT vermerkt sind.

Das meinte ich auch nicht. Mir scheint, die meisten Bugfixes von dir betreffen die Schick.exe und diese gepatchte exe-Datei funktioniert höchstwahrscheinlich nicht mit BrightEyes zusammen, oder?

[Obi-Wahn]

BrightEyes soll dosbox.exe und auch schickm.exe langfristig ersetzen. (Oder?)