Reverse Engineering der NLT II

[siebenstreich]

Auf MusicBrainz.org hab ich die mir 3 bekannten CD-Versionen (Original, Bestsellergames 18, Topware) eingepflegt. Da gibt es tatsächlich (geringfügige) Unterschiede.

Mit Disketten-Versionen und Soundtrack-CD wird es noch unübersichtlicher, siehe diesen Beitrag von NRS.

Die Soundtrack-CD würde mich ja echt interessieren. Vermutlich ist sie teuflisch schwer herzubekommen.

[HenneNWH]

Von mir wurden noch ein paar kleine Änderungen an der Musikausgabe (CD-Audio/AIL) unter DOS vorgenommen:
* Compilerwarnungen mit BCC eliminiert
* Dokumentation für einige Funktionen
* Autorepeat der Audio-CD wird durch den periodischen Timer übernommen (war vorher nur durch Tastendruck implementiert)
* MIDI wird der Audio-CD Musik bevorzugt

Um MIDI mit der DOS-Version zu benutzen ist der passende Soundtreiber auszuwählen.

[Obi-Wahn]

Der Build läuft unter Windows mit cmake problemlos durch.

Anmerkung am Rande: Der Nummernblock funktioniert noch nicht, könnte das noch eingebaut werden? Ich bin ein Nummernblock-Fan. :-D

[HenneNWH]

Hervorragend! Ich arbeite parallel an einer Preisliste für Features. :-)

[Obi-Wahn]

Hervorragend! Ich arbeite parallel an einer Preisliste für Features. :-)

Bar oder Karte?

[HenneNWH]

Bitte in bar. Manche Menschen möchte ich auch mal nach all den Jahren persönlich kennenlernen. :-D

Aber mal im Ernst: Ich spiele mit dem Gedanken einen Patreon-Account zu erstellen und ein paar Videos zu produzieren.
Themen sind vielfältig (BrightEyes, Programmierung, Mathe, Graphentheorie, Musik und anderer fakten- und erfahrungsbasierter Blödsinn.
Edutainment sozusagen: Kleines Beispiel gefällig?

[HenneNWH]

@Obi-Wahn: Hab gerade Keypad-Support hinzugefügt.

[Obi-Wahn]

Bitte in bar. Manche Menschen möchte ich auch mal nach all den Jahren persönlich kennenlernen. :-D

Aber mal im Ernst: Ich spiele mit dem Gedanken einen Patreon-Account zu erstellen und ein paar Videos zu produzieren.
Themen sind vielfältig (BrightEyes, Programmierung, Mathe, Graphentheorie, Musik und anderer fakten- und erfahrungsbasierter Blödsinn.
Edutainment sozusagen: Kleines Beispiel gefällig?

Gegen das Beispiel hätte ich nichts. Hört sich interessant an.
Ob das mit Patreon klappen würde, bin ich mir unsicher. Das ist schon ein spezielle Kombi! 

Der neue Build läuft unter Linux durch, nur bin ich gerade unterwegs und habe nur einen Labtop ohne Num-Block dabei.   

[Obi-Wahn]

Auf meinem Windows-Laptop mag es gerade nicht.

Der alte "make" Befehl findet die SDL.h nicht mehr, obwohl sie da sein sollte und cmake läuft durch, aber dann findet das ngen_cc.exe-Programm libgomp-1.dll nicht.

Gnarf. Keine Ahnung, wo das Problem liegt.

[Taktikus]

...

Der neue Build läuft unter Linux durch, nur bin ich gerade unterwegs und habe nur einen Labtop ohne Num-Block dabei.   

Bin ebenfalls ein Num-Block-Fan, gerade bei der NLT. Es gibt USB-Num-Blocks zum anstecken, das wär vielleicht was für Dich.

[Obi-Wahn]

So, ich bin wieder am PC mit NumBlock. Das reicht mir aus.

Leider funktioniert es nicht. Die Tasten auf dem NumBlock haben keinen Effekt.

[HenneNWH]

Bei mir geht es mit/ohne NumLock.

EDIT: Auch in einer Windows-VM. Dort hab ich noch eine von mir gefundene Ungereimtheit entfernt, welche mit den Num-Keys nichts zu tun haben.
Ich probier das heute Abend mal auf nem echten Windows.

[Obi-Wahn]

Bei mir meckert die cmake-Exe nach dem Erstellen, dass die folgenden DLLs fehlen. Sind das versteckte Abhängigkeiten oder habe ich da ein Fehler beim Kompilieren? Wenn ich die DLLs per Hand in den Ordner kopiere geht es.

[Obi-Wahn]

Am großen PC zu Hause treten die Fehler mit den DLLs nicht auf. Ich vermute, dass ich da irgendwelche Einstellungen bzw. Verweise aktiv habe, die das beheben/lösen.

Mag das mal jemand Drittes testen? Anbei ein aktueller Build.

Edit: [Anhang entfernt]

[HenneNWH]

@Obi-Wahn: Soetwas habe ich schon vermutet.
CMake ist prinzipiell ein hervorragendes Build-Tool, aber wenn etwas damit nicht funktioniert bin auch ich aufgeschmissen.
Insbesondere auf Fremdrechnern.

Unter Debian/Linux konnten einige Projekte nicht gebaut werden, da irgendwelche Bibliotheken keine CMake Unterstützung hatten.
Aktuell bereite ich einen Windows-Entwicklungslaptop vor und hoffe dort eine reibungslos funktionierende Build-Umgebung für BrightEyes aufsetzen zu können,
die allgemeingültig ist.

Zu den fehlenden Bibliotheken: Die werden von OpenMP (parallele Multicore-Standard-Bibliothek) verwendet.
Von mir wurden damit die momentan verwendeten Performance-Messungen fürs Rendern realisiert, da diese weitestgehend portabel gehalten sind.
In der Praxis treten damit offenkundig Unterschiede und Unstimmigkeiten bei verschiedenen Kombinationen von Rechnern/Betriebssystemen/Buildumgebungen/Compilern auf => Fass ohne Boden.

Aktuell benutze ich immer noch das Makefile_old, da diese Variante bei mir am verlässlichsten funktioniert und ich manuell eingreifen kann.
CMake wäre schöner, jedoch stecken dort viele Automatismen drin, die ich bei Weitem noch nicht durchdrungen habe.
Insbesondere bei Fremd-PC's auf die ich keinen Zugriff habe, kann ich da überhaupt nichts ausrichten.
Deshalb: Etwas Geduld, bin dran.

[Obi-Wahn]

Danke für die ausführliche Erklärung! Viel Erfolg bei der Erstellung der Build-Umgebung! Wenn ich helfen kann, melde dich.

Danke auch auf das Hinweisen auf den Fehler in der Zip-Datei von gestern. Ich habe den alten Anhang entfernt und einen aktuellen Windows-Build zusammengestellt. Dieses Mal hoffentlich fehlerfrei.


  BrightEyes_2025_06_15.zip (Größe: 1,2 MB / Downloads: 1)

[HenneNWH]

Perfekt! Danke!

[HenneNWH]

Kleiner Compiler-Exkurs:

Hab gerade die Funktion swap_u32() von NGen überarbeitet, welche die Bytereihenfolge einer Ganzzahl vertauscht.
Einfach gesagt: Für eine natürliche Zahl n soll gelten: n = swap_u32(swap_u32(n)).
Ein einfacher verständliches Beispiel ist: n = (-1 * (-1 * n)).

Das war das von mir benutzte Testverfahren für alle 32-bit Werte in diesem Bereich.

Der GCC hat mit verschiedenen Optimierungsstufen keinen Fehler gemacht und passende Programme erzeugt.

Der Clang hat noch einen drauf gesetzt und zur Compilezeit erkannt, dass das immer stimmt und ein Programm erzeugt,
welches korrekterweise eine sehr kurze Laufzeit hatte.

Beim BCC (DOS) gibt es einige Optimierungsstufen (-O1, -O2) welche nicht korrekten Code erzeugen.
Code welcher mit anderen Optimierungsstufen generiert wurde (-O, -G, -Od) laufen scheinbar ohne Fehler.


P.S.: Das ist mir schon beim Code vom PowerPack-Dekompressionsalgo aufgefallen.
Die C-Version lässt sich zwar mit dem BCC übersetzen, aber die dekomprimierten Bilder sind unbrauchbar.

[Obi-Wahn]

Puh, deinen kleinen Compiler-Exkurs verstehe ich nur zum Teil. Das ist schon ganz tief in der Programmierung und für mich etwas zu tief. :-D Mir macht es Spaß dir zu zugucken und deine Freude am Programmieren zu sehen! :-)

Ich habe gerade nochmal unter Linux kompiliert und grundsätzlich läuft alles wieder. Nur wird die Ausgabe nach dem Drücken auf die Tabulatur-Taste schwarz und das Bild verschwindet.

[siebenstreich]

Beim BCC (DOS) gibt es einige Optimierungsstufen (-O1, -O2) welche nicht korrekten Code erzeugen.

Code welcher mit anderen Optimierungsstufen generiert wurde (-O, -G, -Od) laufen scheinbar ohne Fehler.

Das ist sehr interessant und vielleicht ein guter Moment, um diese Sache ins Gespräch zu bringen:
https://github.com/Henne/Bright-Eyes/issues/54

Steckt da vielleicht ein BCC-Bug dahinter?

Hintergrund: Ich hatte im Rahmen dieser Diskussion beobachtet, dass die Schiffsreisezeiten im mit dem gcc übersetzten BrightEyes von denen der originalen SCHICKM.EXE abweichen. Nachdem in Bright-Eyes ja auf Binärkompatibilität getestet wird, kann der Grund dafür eigentlich nur sein, dass derselbe C-Code von BCC und GCC unterschiedlich interpretiert wird.