Reverse Engineering der NLT

[Zurgrimm]

Sieht so aus:

Diese sonderbaren hinteren Zeichen in dem Font6 sehen sehr nach den Runensymbolen aus "Spirit of Adventure", einem Schick-Vorgängerspiel, aus. In Schick selbst kommen sie ja wohl nicht vor. Aber ob das ein Zufall ist?

[gaor]

So, jetzt kann man sich auch durch Dialoge durchklicken:

[Rabenaas]

Läuft hier ganz wunderbar unter Linux.

[Shihan]

@gaor:
Numpy hatte ich tatsächlich schon drauf. Gehört ja zu einer vernünftigen Python-Installation hinzu

[HenneNWH]

Phase 2: Das Bauen einer SCHICKM.EXE aus dem Code von Bright-Eyes.

Neues in diesem Release:

Neue Features:

• Auswahl: Audio-CD oder Midi-Musik (evtl. Die Schicksalsklinge Midipatch installieren)
  
• Informationen der Händler und Heiler werden wieder ausgegeben
  

Technisches:

• Goar hat fast alle fehlenden Adressen des Datensegments durch Symbolnamen ersetzt.
  
• Goar hat die Datei mit den Symbolnamen in ein Maschinenlesbares Format gebracht.
  
• Die main()-Funktion wird jetzt wieder nativ ausgeführt.
  
• Eine von den 6 unterschiedlichen Funktionen (get_diskspace():seg120.cpp) ist jetzt doch noch identisch geworden. Bleiben noch 5.
  

Bau der EXE-Datei:
Eine EXE-Datei kann schon mit dem BCC gebaut werden, aber es gibt noch viele technische Ungereimtheiten.


TODO-Liste:

• Mit dem Compiler eine neue SCHICKM.EXE bauen, welche bis auf wenige Ausnahmen, identisch mit der deutschen CD-Version von SCHICK sein sollte (der ultimative Beweis für die Äquivalenz von SCHICKM.EXE und BrightEyes)
  
• Erneut versuchen die letzten Unterschiede im Code auszumerzen.
  
• Ersetzen von Hex-Werten in Symbolnamen für Zugriffe aufs Datensegment
  
• Original-Bugs fixen, fixen, fixen
  

Statistik:

Es sind 1237 von 1237 Funktionen nachgebaut (100%).
Davon sind 1232 identisch mit dem Originalcode.


Viele Spaß beim Testen,
HenneNWH

[gaor]

Ich finde es echt spannend, wie das alles auf ein grandioses Finale zuläuft

Ich habe nun auch die Unterstützung für die komprimierten Grafiken (NVFs) in mein Tool eingebaut. Leider habe ich für einige Grafiken noch nicht die richtige Farbpalette gefunden. Aber das wäre gerade ein wichtiger Punkt, um die restlichen Einträge in der symbols.h zu verstehen. Gibt's denn jemanden, der sich schonmal mit den Paletten (z.B. für die Texturen von Häusern) auseinandergesetzt hat?

Das Tool soll auch dabei helfen, zu erklären, wie Animationen (etwa im Kampf) funktionieren. In dem Zusammenhang gibt's nämlich noch eine Menge "kryptischen" Code. Das gleiche trifft auf die Texturen in Städten und Dungeons zu. Die werden irgendwie ad hoc zusammengestückelt und der Code ist an den entscheidenden Stellen echt extrem schwer zu entziffern.

[Rabenaas]

Hier ist die Palette. Im Inventar ändert sie sich, aber nur teilweise. Ich habe auch schon eigene Texturen eingefügt. Müsste ich mir aber selbst erst mal wieder ansehen, bevor ich dazu was sagen kann.

EDIT: Eventuell sind die Beiträge #60, #61 oder #73 dort hilfreich?

EDIT2: Ach ja, jetzt erinnere ich mich. Mein Skript hat in die Zeichenroutine eingegriffen, und einfach in jedem Pixel eines Items im Inventar die mit 0, 1, 2, ..., 255 indizierte Farbe gezeichnet.

[gaor]

Bei dem von dir verlinkten Thread geht es um die Farbpalette für Gegenstände. Da gibt es nur eine, dementsprechend unterhaltet ihr euch da auch immer nur über eine Palette. Im Spiel gibt es aber jede Menge Farbpaletten, je nach aktuellem Bildschirminhalt (das ist dir bekannt, darüber sprichst du nämlich auch im Bezug auf den Händlerbildschirm). Mir geht es jetzt konkret darum, zu verstehen, woher die Paletten geladen werden und welche Palette da genau welchen Zweck hat.

Die Palette für die Gegenstände in der GGSTS.NVF habe ich mir bereits aus globalen Variablen zusammengeschustert. Das wird in meinem Tool alles richtig angezeigt. Auch viele andere Grafiken werden mit dieser Palette richtig angezeigt. Ausnahmen sind leider noch die Texturen HOUSE1.NVF bis HOUSE4.NVF, FINGER.NVF und ein paar weitere (FIGHTOBJ.NVF, TEMPICON, OBJECTS.NVF, wenn ich das richtig sehe).

[Rabenaas]

Du könntest im Prinzip meinem Ansatz für das Inventar folgen und in die Zeichenroutine für Häuser einfügen, dass Pixel mit den Farben 0 bis 255 gezeichnet werden. Ich schaue mir das morgen mal an. Wenn Du die RGB-Werte hast, sollte es einfach sein, sie im Code zu lokalisieren. Aber jetzt

[Borbaradwurm]

Ausnahmen sind leider noch die Texturen HOUSE1.NVF bis HOUSE4.NVF, FINGER.NVF und ein paar weitere (FIGHTOBJ.NVF, TEMPICON, OBJECTS.NVF, wenn ich das richtig sehe).

HOUSE1.NVF bis HOUSE4.NVF und FINGER.NVF enthalten selbst keine Palette, nutzen aber alle die Palette von TDIVERSE.NVF.

FIGHTOBJ.NVF nutzt vier verschiedene Paletten, und zwar die Palette ihrer Kampfhintergrundtextur:
* Texturen #0 bis #9 nutzen die Palette aus KDBACK.DAT und KDLBACK.DAT.
* Texturen #10 bis #18 nutzen die Palette aus KCBACK.DAT und KCLBACK.DAT.
* Texturen #19 bis #27 nutzen die Palette aus KSBACK.DAT und KSLBACK.DAT.
* Texturen #28 bis #57 und #62 nutzen die Palette aus KLBACK.DAT und KLLBACK.DAT.
* Texturen #58 bis #61 funktionieren mit allen vier Kampfhintergrundpaletten, da sie nur zwei Farbeindicies nutzen: Schwarz und 100%-Transparenz; die bei allen vier Paletten gleich sind.

TEMPICON enthält selbst keine Palette, nutzt die Palette der Tempel-Animation (die Palette der Animation #2 aus ANIS).

OBJECTS.NVF weiss ich auch noch nicht. Scheint aber auch mehr als eine Palette zu sein (wie bei FIGHTOBJ.NVF). Wobei die Texturen mit den Indices 0-9, 10-11, 12-16 und 17-18 zusammen gehören.

[Obi-Wahn]

Neue Version vom 23.01.2017!

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

[gaor]

HOUSE1.NVF bis HOUSE4.NVF und FINGER.NVF enthalten selbst keine Palette, nutzen aber alle die Palette von TDIVERSE.NVF.

FIGHTOBJ.NVF nutzt vier verschiedene Paletten, und zwar die Palette ihrer Kampfhintergrundtextur:
* Texturen #0 bis #9 nutzen die Palette aus KDBACK.DAT und KDLBACK.DAT.
* Texturen #10 bis #18 nutzen die Palette aus KCBACK.DAT und KCLBACK.DAT.
* Texturen #19 bis #27 nutzen die Palette aus KSBACK.DAT und KSLBACK.DAT.
* Texturen #28 bis #57 und #62 nutzen die Palette aus KLBACK.DAT und KLLBACK.DAT.
* Texturen #58 bis #61 funktionieren mit allen vier Kampfhintergrundpaletten, da sie nur zwei Farbeindicies nutzen: Schwarz und 100%-Transparenz; die bei allen vier Paletten gleich sind.

TEMPICON enthält selbst keine Palette, nutzt die Palette der Tempel-Animation (die Palette der Animation #2 aus ANIS).

OBJECTS.NVF weiss ich auch noch nicht. Scheint aber auch mehr als eine Palette zu sein (wie bei FIGHTOBJ.NVF). Wobei die Texturen mit den Indices 0-9, 10-11, 12-16 und 17-18 zusammen gehören.

Oh, cool. Allerhand

Darf man fragen, woher du das weißt bzw. wie du das jetzt so schnell herausgefunden hast?

[Wetzer]

Habe die neue Version mit CD Musik ausprobiert.

Wenn man die Cycles mit AltGR+F11 reduziert, funktioniert das.

Das Erhöhen mit AltGR+F12 führt zu einem komischen Geräusch und im Fenster steht mehrfach "Fast Forward ON", "Fast Forward OFF",...

[Obi-Wahn]

Muss die DosBox eigentlich auch in Zukunft noch mitkompiliert werden, oder können die beiden Sourcecodes irgendwann "wieder" getrennt werden?

[Wetzer]

Muss die DosBox eigentlich auch in Zukunft noch mitkompiliert werden, oder können die beiden Sourcecodes irgendwann "wieder" getrennt werden?

So wie ich das verstanden habe, ist das Phase II, an deren Anfang wir stehen. Der 100% originäre Code wird sicherlich nur mit einer DosBox (oder jeder anderem Dos-Umgebung) laufen. Wenn aber der Sourcecode der Schickm vorliegt, kann man angepasste, native <hier dein Betriebssystem deiner Wahl einsetzen> -Versionen generieren. So mein Verständnis.

[Rabenaas]

Sobald der DosBox-Teil wie der Schwanz einer Kaulquappe abgestoßen wurde, haben wir ein Programm, das nativ unter DOS läuft.

Da BE über die DOSBox indirekt auf SDL zugreift, können diese Zugriffe auch in den BE-Teil gezogen werden, so dass das Programm per Compiler-Flag auch für Linux, Windows, Mac etc. (AmigaOS ) kompiliert werden kann.

[HenneNWH]

Wie Wetzer es richtig erkannt hat, endet Phase 2 mit einer SCHICKM.EXE, welche nur unter DOS funktioniert.
Phase 3 ist dann die Portierung der DOS-Abhängigen Codeteile auf SDL,
damit das ganze Programm nativ auf _richtigen_ Betriebssystemen läuft.

Phase 2 ist folgendermaßen untergliedert:

• Mit dem BCC eine SCHICKM.EXE erstellen, in welcher sich der Code aus Phase 1 an genau den richtigen Stellen befindet.
  
• Ersetzen der Variablen aus dem Datensegment, welches bis jetzt nur ein großes Feld mit Daten ist, durch Variablen, welche in C deklariert und ggf. definiert sind.
  

Im Moment arbeite ich an Punkt 1, gaor an Punkt 2.
Ich bin schon bis zu Segment seg014 vorgedrungen, an welchem es noch kleine Unterschiede gibt, anschließend kommen die Stub-Segmente, das Datensegment und schließlich der Code (seg024-seg122) welche aus der SCHICKM.EXE bei Bedarf nachgeladen werden. Die Stub-Segmente und der nachladbare Code sollten schon soweit identisch sein, das Datensegment ist vorerst nur ein
großes Feld mit lauter Nullen.
Diese Nullen werden durch die Arbeit von gaor durch _richtige_ Daten ersetzt, wodurch der Code wesentlich lesbarer werden wird.

Innerhalb von Phase 2 sollte sich nichts wesentliches für die Benutzer von Bright-Eyes ändern, abgesehen von Bugfixes.

Phase 3 ist die Portierung:

• Ein- und Ausgabe von Dateien sollte über die Funktionen aus der C-Bibliothek realisiert werden. In SCHICKM.EXE werden nicht-portable Varianten von DOS genutzt. Hinzu kommt, dass der Spielstand im Little-Endian-Format abgelegt wird, damit die Spielstände auch auf verschiedenen Prozessoren funktionieren.
  
• Eingaben von Maus und Tastatur müssen neu geschrieben werden.
  
• Die Ausgabe auf den Framebuffer muss neu geschrieben werden + sinnvolle Skalierungsmöglichkeiten, da eine Auflösung von 320x200 nicht mehr tragbar ist.
  
• Die Ausgabe der Musik muss neu überdacht werden. SDL2.0 hat keine Audio-CD Unterstützung mehr, desshalb sollte dafür ausschließlich das Abspielen von MP3/OGG/FLAC implementiert werden. Alternativ sind ja auch noch die MIDI-Daten vorhanden. Um diese Abzuspielen muss auch wieder etwas implementiert werden.
  
• Ein Timer muss neu implementiert werden um die Zeit in Aventurien weiterlaufen zu lassen. Da dieser Timer zu gleichen Zeit auf einem anderen Prozessor laufen kann, muss der Code auf kritische Bereiche geprüft werden um Race-Conditions zu vermeiden.
  
• ...???
  

Nach dieser Phase sollte eine lauffähige Version für jedes Betriebssystem bereitstehen, welches von SDL unterstützt wird.

[Alrik Alrikson]

[...]
Die Ausgabe auf den Framebuffer muss neu geschrieben werden + sinnvolle Skalierungsmöglichkeiten, da eine Auflösung von 320x200 nicht mehr tragbar ist.
[...]

Welche Auflösung wird das fertige Spiel denn dann haben, oder ist es noch zu früh darüber etwas sagen zu können?

[HenneNWH]

Hallo Alrik,

[...]
Die Ausgabe auf den Framebuffer muss neu geschrieben werden + sinnvolle Skalierungsmöglichkeiten, da eine Auflösung von 320x200 nicht mehr tragbar ist.
[...]

Welche Auflösung wird das fertige Spiel denn dann haben, oder ist es noch zu früh darüber etwas sagen zu können?

das ist schwer zu sagen. Prinzipiell kann man das fertige Bild mit OpenGL auf jede beliebige Größe skalieren,
aber ob das immer schön aussieht ist fraglich. Das Seitenverhältnis der Bilder muss schon beibehalten werden.
Bis jetzt hatte ich mal einige Scaler aus der DOSBox probiert, aber bin bei normal2x geblieben.
Der Grund ist folgender: In Schick muss viel Text gelesen werden und alle Scaler die etwas cleverer sind
versuchen die weiße Schrift mit dem grünen Hintergrund zu verschmelzen.
Die Folge ist eine unscharfe Schrift.
Für die Bilder finde ich die Scaler in Ordnung.

Fazit: Ich denke im Moment, dass die Bilder gezeichnet,
mit einem guten Scaler skaliert und anschließend der Text auf das Resultat geschrieben werden sollte.
Welcher Scaler für Schick am geeignetsten ist, weiß ich auch noch nicht.

[Rabenaas]

Mein Lieblingsscaler ist hq3x. Die Ergebnisse sind erstaunlich.