Reverse Engineering der NLT II

[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.