Reverse Engineering der NLT II

[Obi-Wahn]

git checkout 00b5f43cf54cb1f9ef4164c8bf114e0a61cef959
Kompilieren geht nicht. Das Problem hattest aber schon gehoben

git checkout cf22d73d8da8fc4481a1878f919a671e0b59f790
Kompilieren geht, aber dann kommt der Segmentation fault

git checkout e507d576ca716fac81e31a48b6e4f52654ba91af
Es funktioniert wieder alles??

Und mit einem frischen Git-Clone und der aktuellsten Version geht auch alles. Scheint also behoben oder vielleicht ein Fehler bei mir gewesen zu sein.

[HenneNWH]

Danke, ein "git pull" sollte eigentlich reichen. Damit bekommst du die aktuelle Version.

Hab heute die Grafikausgabe überarbeitet. :-D

* Mit <TAB> kann jetzt die Fenstergröße angepasst werden.
* Die Anzahl der Textur-Updates wurde erheblich reduziert.
* Die Dateirechte auf Linux-Systemen werden jetzt korrekt gesetzt.
* Beim Speichern der CHR-Datei, wird die Fehlermeldung jetzt in einer schicken Infobox ausgegeben.
* Die DSAGEN.DAT der deutschsprachigen Diskettenversion funktioniert auch wieder.
* Die Credits werden seit gestern korrekt angezeigt.
* Die Tastatur geht auch (incl. Umlaute und Hotkeys (STRG+Q, STRG+F3, STRG+F4 und 1,..,5 im Fortgeschrittenenmodus)).

[Obi-Wahn]

Wow, beeindruckend, wie gut die Charaktergenerierung inzwischen läuft. Die Logo-Animationen sind butterweich und alles läuft flott! 
Auch das Speichern der Charakterdateien funktioniert.

  ngen_gcc_2025_04_30.zip (Größe: 188,01 KB / Downloads: 0)

Das einzige was jetzt noch deutlich herausfällt, ist die Animation der Check-Boxen, die nach oben und nach unten über den Fensterrahmen hinausgehen. Aber daran arbeitest du ja gerade auch noch.

[HenneNWH]

Gestern Abend habe ich die Anzahl der Textur-Updates weiter reduziert.
Das Füllen der Checkboxen wurde auch überarbeitet, da die bisherige Variante nicht ganz so Prozessorfreundlich war.
Senkrechte Striche zu zeichen ist etwas aufwändiger als wagerechte Striche.

Die Begrenzung der Checkboxen sind mir natürlich auch schon aufgefallen.
Das liegt daran, dass der Mauscursor noch nicht implementiert ist.

Heute Vormittag wurde ein weiterer Meilenstein erreicht:
Der Charaktergenerator hat jetzt einen Timer, womit die Pseudo-Zufallszahlen etwas zufälliger wirken.
Jetzt ist es möglich Charaktere zu erstellen welche in SCHICK (deutschsprachige CD-Version) und BLADE (englischsprachige Version) benutzbar sind.
Wenn die Charaktere im Spiel sind unterscheiden sich die beiden Sprachversionen jedoch.

Aktuell funktioniert das nur auf Little-Endian-Prozessoren (x86, x86_64, ARM), das Gegenstück ist kaum noch verbreitet.
Hab noch eine PowerPC VM mit Debian 10, da kann ich das ganze Testen.

[siebenstreich]

Es geht ja in großen Schritten voran!

Die Grafik ist jetzt flüssig. Neben der fehlenden vertikalen Begrenzung der Pos. des Radio-Buttons bei Benutzung der Maus ist mir noch Folgendes aufgefallen: Bislang konnte man das Programm nicht durch einen normalen kill (Klick auf Fenster schließen) beenden. Das scheint jetzt an vielen Stelle zu funktionieren, aber nicht überall: Beim ersten Fenster "Wählen Sie den Schwierigkeitsgrad!" geht es nicht.

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.

Vielen Dank!

Ist es so gemeint? Wenn Bright-Eyes sein eigenes Datensegment hätte, dann käme es zu einem seltsamen Verhalten, wenn man innerhalb einer weiterlaufenden Bright-Eyes Dosbox die SCHICKM.EXE beendet und wieder neu startet. Richtig?

[Obi-Wahn]

Gibt es eigentlich einen Unterschied zwischen dem Intro des Hauptprogrammes und von der Char-Generierung? Ich habe gerade mal testweise die Steam-Version gestartet und dort kommt beim attic-Logo noch ein gelber Schriftzug "präsentiert in Kooperation mit". Das Logo erscheint auch nicht von unten. Das Fantasy-Productions"-Logo kommt dafür bei Steam von unten rein.

[HenneNWH]

@Siebenstreich:
Zum Datensegment: Genau so ist es! Das führt zu nix.

Die "Mauszeiger-Radio-Box-Problematik" hab ich unter den Umständen gelöst und das Killen des Fensters mit einer geöffneten RadioBox funktioniert jetzt auch. Weiterhin habe ich die Assembler-Grafikroutinen durch leserlichen und performanten C-Code ersetzt.

@Obi-Wahn: Ja, den Unterschied gibt es. Das Intro vom Charaktergenerator ist in der GEN.EXE eingebaut. Das Intro vom Spiel ist in mehreren separaten Dateien untergebracht und wird mit der INTRO.EXE gestartet. In der SCHICKM.EXE selbst ist kein Intro enthalten.

Code:

ls INTRO*

[Obi-Wahn]

Danke für die Erklärung! Ich bin gerade unterwegs und habe daher auf meinem Windows-Laptop die Kompilierungsumgebung installiert. Dabei habe ich gemerkt, dass ich auf meinem Desktopsystem wohl unabsichtlich eine alte Umgebungsvariable, die auf SDL2 verweist, weiter verwendet habe. Es wird die SDL.dll (im gleichen Verzeichnis) benötigt, wenn man ngen_gcc.exe startet.  Die bekommt man von der offiziellen SDL-Downloadpage: https://github.com/libsdl-org/SDL/releas...ase-2.32.4

Edit: Ich habe gerade mal versucht, die drei wichtigen Dateien DSAGEN.DAT, ngen_gcc.exe und SDL2.dll in ein neues Verzeichnis zu kopieren und dann dort die ngen_gcc.exe zu starten. Das klappt leider nicht. Das Programm stürzt ohne Fehlermeldung ab. Braucht ngen_gcc.exe doch noch mehr Dateien aus dem github-Verzeichnis oder woran könnte es liegen? Direkt im github-Verzeichnis läuft das Programm ohne Probleme.

Edit2: Es scheint irgendwas in dem msys-Ordner zu sein, da auch das Kopieren des ganzen BrightEyes-github-Ordners nicht funktioniert. Ich hatte der Einfachheit halber den BrightEyes-github-Ordner im home-Ordner von msys gepackt. Ich probiere nochmal rum.

Edit3: Jetzt läuft es. DSAGEN.DAT, ngen_gcc.exe und SDL2.dll in einem Ordner und gut ist. Ich bin ratlos...

[HenneNWH]

Prinzipiell brauchst du nur diese 3 Dateien: ngen_gcc.exe, DSAGEN.DAT und die SDL2.dll (wenn du dynamisch gelinkt hast).
Alle anderen Dateien sind nur für DOS interessant.

Hab gerade den originalen MouseCursor aktiviert.
Dass man jetzt bei den Radioboxen den eingegrenzten Bereich verlassen kann finde ich wesentlich angenehmer.

[siebenstreich]

Die Mausbedienung ist irgendwie so und so komisch aus heutiger Sicht. Also dass man nicht direkt auf den Radio Button draufklicken muss, sondern dass die vertikale Position des Mauszeigers das einzig Entscheidende ist. Aber ja, dass der Mauszeiger nicht in der Box gefangen ist, ist schon etwas natürlicher.

Der Mauszeiger fühlt sich aber noch "laggy" an, weil die Position nicht so oft aktualisiert wird. Ich tippe auf unter 10 FPS. Lässt sich das noch erhöhen?

Das Beenden des Programms durch Klick auf "X" funktioniert jetzt zuverlässig.

[HenneNWH]

Ja, der Mauszeiger ist laggy und rate mal: Daran arbeite ich gerade.

Technischer Hintergrund: Beim Bewegen des Mauszeigers wird der ganze Fensterinhalt neu gezeichnet (Aufwändig).

[Obi-Wahn]

Mal läuft ngen_gcc.exe, mal nicht. Ich kann keinerlei Struktur erkennen. Ich vermute, dass das irgendein Windows-Problem ist ... oder so.

[NewProggie]

Mal läuft ngen_gcc.exe, mal nicht. Ich kann keinerlei Struktur erkennen. Ich vermute, dass das irgendein Windows-Problem ist ... oder so.

Konnte ich hier in einer Windows 10 VM mit w64devkit und SDL2 gerade auch nachvollziehen. Kompiliert durch, aber die Executable startet nicht, keine Fehlermeldung.

[Obi-Wahn]

Mal läuft ngen_gcc.exe, mal nicht. Ich kann keinerlei Struktur erkennen. Ich vermute, dass das irgendein Windows-Problem ist ... oder so.

Konnte ich hier in einer Windows 10 VM mit w64devkit und SDL2 gerade auch nachvollziehen. Kompiliert durch, aber die Executable startet nicht, keine Fehlermeldung.

Danke für die Rückmeldung! Komisch!
Ich führe die Schritte wiederholt durch, zum Teil auch mit einem neuen git clone und plötzlich geht es wieder...

[HenneNWH]

Konnte ich hier in einer Windows 10 VM mit w64devkit und SDL2 gerade auch nachvollziehen. Kompiliert durch, aber die Executable startet nicht, keine Fehlermeldung.

w64devkit und eine fertige SDL2 haben bei mir auch gerade zum erfolgreichen kompilieren und starten geführt.
Im Makefile hab ich dazu ein paar Zeilen geschrieben, die nur auskommentiert werden müssen.

Hatte auch gerade einen Segfault, welchen ich dann nicht mehr reproduzieren konnte.
Alle nächsten Anläufe lief es dann ohne Probleme.
Tipp: NGEN sollte wegen der Fehlermeldungen von der Kommandozeile aus gestartet werden.

Bei mir ist der Eindruck entstanden, dass Windows zum Entwickeln eher zweite Wahl ist.

Neues:
* Pixelwerte wurden umgestellt (zweimal schneller auf meinem Raspi2 !?!)
* Es wird nicht mehr jedes mal der gesamte Bildschirminhalt kopiert, sonder jeweils nur die Bereiche, welche sich Ändern.

[siebenstreich]

Ja, der Mauszeiger ist laggy und rate mal: Daran arbeite ich gerade.

Technischer Hintergrund: Beim Bewegen des Mauszeigers wird der ganze Fensterinhalt neu gezeichnet (Aufwändig).

Danke für die Rückmeldung! So in der Richtung hatte ich das auch vermutet.

Es wird nicht mehr jedes mal der gesamte Bildschirminhalt kopiert, sonder jeweils nur die Bereiche, welche sich Ändern.

Ich habe mir gerade die letzte Version angeschaut. Der Mauszeiger ist jetzt anders, beim Bewegen flackert er. Kann es sein, dass beim Update der geänderten Bereiche zwischendrin auch der Bildschirminhalt ohne den darübergelegten Mauszeiger in der Ausgabe landet?

Bei mir ist der Eindruck entstanden, dass Windows zum Entwickeln eher zweite Wahl ist.

Nicht nur zum Entwickeln.. 

[HenneNWH]

Aktuell ziehe ich es vor den Aufwand fürs Rendern zu minimieren und überarbeite gerade die Popup-Boxen.

Das Flackern des Mauszeigers kann mehrere verschiedene Ursachen haben.
Vermutlich hast du mit deiner Vermutung (auch) Recht.
Vielleicht löst es sich nach ein paar Optimierungen von selbst auf.
Als Möglichkeit sehe ich noch, die Maus-Cursor mit SDL2 umzusetzten.
Das kommt aber eher am Ende.

Ich sehr das allerdings positiv: Wenn etwas laggt, dann gibt es noch irgendetwas zu optimieren.
Für diesen Zweck hab ich mir auch mal den Raspi angeschafft um ein modernes 286-Pendant zu haben. :-D

[siebenstreich]

Aktuell ziehe ich es vor den Aufwand fürs Rendern zu minimieren und überarbeite gerade die Popup-Boxen.

Das Flackern des Mauszeigers kann mehrere verschiedene Ursachen haben.
Vermutlich hast du mit deiner Vermutung (auch) Recht.
Vielleicht löst es sich nach ein paar Optimierungen von selbst auf.
Als Möglichkeit sehe ich noch, die Maus-Cursor mit SDL2 umzusetzten.
Das kommt aber eher am Ende.

Ich sehr das allerdings positiv: Wenn etwas laggt, dann gibt es noch irgendetwas zu optimieren.
Für diesen Zweck hab ich mir auch mal den Raspi angeschafft um ein modernes 286-Pendant zu haben. :-D

Gute Idee! Genau, der Anspruch muss sein, dass BrightEyes zum flüssigen Spielen nicht mehr Resourcen benötigt als die originale Schicksalsklinge.

Du sprichst hier einen Punkt an, über den ich mich schon ein wenig gewundert hatte. Ich sitze an einem halbwegs aktuellen Notebook, ein absolutes Monster im Vergleich zur Hardware, auf der wir die Schicksalsklinge damals gespielt haben. Man sollte meinen, selbst bei einer Implementierung die ständig den ganzen Bildschrirminhalt neu rendert, sollte man locker 25 FPS schaffen. Offenbar ist das aber nicht der Fall, warum? Ist die SDL-Bibliothek derart ineffizient?

[Obi-Wahn]

Anbei noch einmal meine kompilierte Variante von heute Nachmittag. Hat bei mir funktioniert.


  ngen_gcc_2025_05_04.zip (Größe: 128,01 KB / Downloads: 0)

[HenneNWH]

Das SDL-Bibliothek würde ich nicht dafür die Schuld in die Schuhe schieben.
Das liegt eher daran wie ich generell an die Problematik (DOS-Anwendung portieren) rangehe und
versuche den Übergang zu gestalten. Es soll von Außen alles so bleiben wie es ist.
Dafür war/ist erstmal viel Rechenleistung notwendig, welche nach und nach minimiert wird.

Aktuell braucht SDL_UpdateTexture() noch sehr lange (Raspi ca. 10 ms) und wird noch bei jeder Änderung aufgerufen.
Die Skalierung und die PopUp-Boxen habe ich heute weiter optimiert und noch ein Performance-Messtool ausprobiert.
Das hat mir gezeigt, dass ich beim Skalierungsalgorithmus erstmal ordentlich abgeliefert habe und gestern Abend noch
ein paar Performanceengpässe abgemildert habe.

Ich spiele auch mit dem Gedanken, reines Softwarerendering auszuprobieren, da das eher zu diesen Spielen passt,
als permanent softwaregerenderte Bilder an die GPU zu schicken.
Das erfordert allerdings noch etwas Einarbeitung in die SDL2-Bibliothek.