Reverse Engineering der NLT II

[siebenstreich]

In Bright-Eyes wurde die Typisierung der Variablen durch Makros wie ds_readbs() oder ds_readb() an sehr vielen Stellen separat festgelegt.

Alles klar, danke!
In diese Richtung hatte ich schon gedacht, dann aber wohl vergessen, dass ds_readw die unsigned-Variante ist.

[HenneNWH]

Soo, es gibt etwas Neues. Die von mir erzeuge BLADEM.EXE hat jetzt genau die korrekte Größe.
Das hat den Vorteil, dass mit diesen 5 Werten jetzt der Fortschritt genau erkennbar ist
und ich es mir wieder etwas schwerer gemacht habe zukünftig Fehler zu machen.

Die ersten 3 Werte sind Code-Kosmetik, die letzten Beiden sind harte Fakten.

Im Overlay-Code gibt es ca. 7.8 % Unstimmigkeiten, welche hoffentlich bald behoben sind.

Code:

# host_read  : 2196
# host_write : 447
# _ptr_      : 275
BAE CODE     : 486
BAE OVR      : 31043

[Obi-Wahn]

Soo, es gibt etwas Neues. Die von mir erzeuge BLADEM.EXE hat jetzt genau die korrekte Größe.

Juhu! Also läuft das Spiel jetzt schon?

[HenneNWH]

Nein, noch lange nicht. Die Bladem.exe ist der DOS Nachbau, welchen ich mit der Original SCHiCKM.EXE vergleiche. Aktuell zwingt mich das RL mich mit anderen Dingen zu beschäftigen. Hoffe ich bin bald weniger gestresst.

[Obi-Wahn]

Nein, noch lange nicht. Die Bladem.exe ist der DOS Nachbau, welchen ich mit der Original SCHiCKM.EXE vergleiche. Aktuell zwingt mich das RL mich mit anderen Dingen zu beschäftigen. Hoffe ich bin bald weniger gestresst.

Ah, okay. Danke für die Erklärung. Alles Gute fürs RL! 

[siebenstreich]

Ich habe in letzter Zeit immer mal wieder in die commits geschaut. Sehr befriedigend zu sehen, wie die structs (z.B. hero) entstehen und dann diese umständlichen Konstrukte mit readbs und zu Fuß nachgebauten Struct- bzw. Arrayzugriffen rückgebaut werden.

Zwei Fragen/Anmerkungen:

(1)
Dieser Commit: Warum muss da immer umständlich "(struct struct_hero*)hero" gecastet werden?

Gleich ein Versuch der Erklärung:
Solange noch Zugriffe "zu Fuß" der alten Methode "hero + HERO_MONEY" existieren, muss hero den Typ Bit8u* haben. Wenn alles umgebaut wurde, kann der Typ auf struct_hero* umgestellt werden, womit die Typecasts (struct struct_hero*)hero nicht mehr notwendig sind und entfernt werden können. Richtig?

(2)
Anlässlich dieses Commits ist es mir wieder eingefallen: Mir persönlich gefällt die gelegentlich anzutreffende Variablenbezeichnung mit "_no" gar nicht. Mein Hirn denkt da immer zuest an das englische Wort "no", also "nein". Zwei Vorschläge für Alternativen:

• _nr
  Ich weiß, das ist ein Germanismus: Die offizielle Abkürzung von "number" im Englischen is nun mal "no". Aber letztlich geht es ja nicht darum, einen Literaturnobelpreis zu gewinnen, sondern möglichst selbsterklärende Bezeichner zu wählen. Der Zweck heiligt die Mittel.
  
• Oder gleich so:
  _id
  

Das ganze nur als Anmerkung, es ist ja ein totaler Nebenkriegsschauplatz. Aber vielleicht kann man (ich?) das irgendwann mal bereinigen, wenn sich die großen Wogen gegleättet haben.

(Mein Gedächtnis verblasst schon etwas: Evtl. hatte ich entsprechende Änderungen damals auch gelegentlich gemacht. Aber sicher nicht flächendeckend: Ich hatte immer etwas Skrupel, mich zu sehr an den alten Bezeichnern zu vergreifen.)

[cmfrydos]

Schlammschlacht! Ich widerspreche.
„nr“ geht nur, wenn das Repository komplett auf Deutsch wäre. 
Außerdem gibt es bereits „group_pos“, und mit „group_id“ würde die Verwirrung nur größer. 

Mir persönlich gefallen „party_id“ und „party_slot_id“ am besten. 
„Group“ kann nämlich alles Mögliche bedeuten, während „Party“ die eindeutigere Bezeichnung für eine Heldengruppe ist. 
Indizes in „Hero“ werden bisher durchgängig mit „_id“ abgekürzt: Damit bliebe das Schema gewahrt und es entstünde keine Verwirrung.

[NewProggie]

(2)
Anlässlich dieses Commits ist es mir wieder eingefallen: Mir persönlich gefällt die gelegentlich anzutreffende Variablenbezeichnung mit "_no" gar nicht. Mein Hirn denkt da immer zuest an das englische Wort "no", also "nein". Zwei Vorschläge für Alternativen:

• _nr
  Ich weiß, das ist ein Germanismus: Die offizielle Abkürzung von "number" im Englischen is nun mal "no". Aber letztlich geht es ja nicht darum, einen Literaturnobelpreis zu gewinnen, sondern möglichst selbsterklärende Bezeichner zu wählen. Der Zweck heiligt die Mittel.
  
• Oder gleich so:
  _id
  

Code:

_num

?

[siebenstreich]

An die Umbenennung group -> party hatte ich auch schon gedacht, ich hätte da auch noch weitere. Ich wollte nur nicht gleich mit der Tür ins Haus fallen!


party_id wäre auch mein Favorit. Allerdings sollte man dann die Änderung group -> party gleich konsequent durchführen, damit es einheitlich ist. Das trifft einige Variablen- und Funktionsnamen.

[HenneNWH]

@Obi-Wahn: Danke.

@Siebenstreich:
Zu 1.: Ganz genau. Bit8u* ist ein Zeiger auf ein Array aus unsigned char Werten.
Theoretisch ist host_readb(Hero + HERO_HEIGHT) dasselbe wie Hero[HERO_HEIGHT].
Die Typecasts werden dann hoffentlich bald entfernt.

Zu 2.: _id ist perfekt.
Das ist jedoch eher als Codekosmetik zu sehen.
Im Vergleich zur Binäraequivalenz hat das erstmal eine niedrigere Priorität.

Gesten hab ich noch dafür gesorgt, dass alle cpp Dateien mit dem GCC kompilieren, aber das Linken der erzeugten Dateien funktioniert noch nicht.
Wenn ich dafür ne Lösung gefunden hab gibt's auch das Makefile.

[HenneNWH]

Es ist vollbracht!
Seit heute gibt es eine kompilierbare 64-Bit Version der Schicksalsklingen. Benutzbar ist sie noch nicht.
Mit dem Debugger konnte ich bis zum Schwierigkeitsgrad menu vorpreschen.
Dann mangelt es an der Tastatureingabe.
Die SCHICK.DAT scheint auch ohne Fehler lesbar.

[Shihan]

Das ist ein überraschend wilder Meilenstein. Überraschend im Sinne der Schwierigkeit, alte Software soweit zu bringen, dass sie mit den ganzen Änderungen der Pointer-Arithmetik klarkommt, die dieser Schritt nach sich zieht. Chapeau, Henne!

[Obi-Wahn]

Super! :-)

[HenneNWH]

Zwischenstand: Dass jetzt zumindest mit dem GCC durchkompiliert werden kann, hat sich als gute Entscheidung entpuppt.
Das geht wesentlich schneller als mit dem BCC und wichtige Fehlermeldungen huschen jetzt nicht mehr so schnell unbemerkt an mir vorbei.

Weitere externe Anregungen jeglicher Art werden erstmal nur zur Kenntnis genommen
und irgendwann umgesetzt, wenn die Zeit dafür reif ist.

Code:

# host_read  : 1992
# host_write : 410
# _ptr_      : 261
BAE CODE     : 486
BAE OVR      : 31043

[Obi-Wahn]

Ich sitze vor dem Bildschirm und hüpfe auf meinem Stuhl wie ein kleiner Flummi hin und her. Wer hätte Anfang des Jahres 2025 gedacht, dass BrightEyes überhaupt weiter entwickelt wird und dass du dann auch noch so weit voran kommst!

[HenneNWH]

Bin selbst überrascht. Das geht wie das Brezelbacken!
Aktuell bin ich dabei die "struct_hero" einzubauen und das SIZEOF_HERO durch ein sizeof(struct struct_hero) zu ersetzen.
Das ist nur noch 111 mal vorhanden, dann kann auch das weg!

Code:

# host_read  : 1799
# host_write : 372
# _ptr_      : 242
BAE CODE     : 486
BAE OVR      : 31043

[siebenstreich]

@Siebenstreich:

Zu 1.: Ganz genau. Bit8u* ist ein Zeiger auf ein Array aus unsigned char Werten.

Theoretisch ist host_readb(Hero + HERO_HEIGHT) dasselbe wie Hero[HERO_HEIGHT].

Die Typecasts werden dann hoffentlich bald entfernt.

Alles klar, danke für die Bestätigung.

Zu 2.: _id ist perfekt.

Das ist jedoch eher als Codekosmetik zu sehen.

Im Vergleich zur Binäraequivalenz hat das erstmal eine niedrigere Priorität.

Prima, dann sind wir uns ja generell einig mit _id. Die niedrige Priorität sehe ich genauso, Nebenkriegsschauplatz.

Eine Kleinigkeit, weil es mir gerade aufgefallen ist: Kann es sein, dass du in dieser Änderung in der commons.h versehentlich die Zeile "HERO_INVENTORY_SLOT_KNAPSACK_16 = 22," entfernt hast?

[HenneNWH]

@Siebenstreich:

Du bist aber aufmerksam. Diese Zeile war nicht wirklich notwendig, hab sie aber wieder hinzugefügt.

Code:

# host_read  : 1030
# host_write : 217
# _ptr_      : 155
BAE CODE     : 486
BAE OVR      : 30725

[HenneNWH]

Heute sind ein paar (technische) Meilensteine erreicht worden:
* logische und arithmetische Operationen auf die globalen Variablen sind jetzt in nativem C (kein add_ptr_bs(), ...),
* die Flags der Helden wurden eingebaut,
* die Beschreibung der Gegenstände ist komplett fertiggestellt (g_itemsdat).

Code:

# host_read  : 343
# host_write : 8
BAE CODE     : 486
BAE OVR      : 30725

[HenneNWH]

Schreibzugriffe auf globale Variablen wurden entfernt!

Code:

# host_read  : 173
# host_write : 0
BAE CODE     : 473
BAE OVR      : 23451