Reverse Engineering der NLT II

[HenneNWH]

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?

Es sieht ganz danach aus. Diese Funktion halte ich für ein Paradebeispiel, da sie sich sehr leicht formal beweisen lässt.
Ein 32-bit Wert hat 4 Bytes v = (a,b,c,d). Der Wert der Funktion swap_u32(v) = (d,c,b,a), wenn alles richtig vom Compiler umgesetzt wurde.
Der Clang hat das sogar noch bestätigt.

Die in Gen gewählte Implementierung habe ich jetzt, optimiert mit (-O2), mit meiner neuen Implementierung verglichen.
Beispiel:

Code:

v = 0x1'21'93 new = 0x93'21'01'00 old = 0x1'01'00

Folglich geht an diesem Beispiel mit der Originalimplementierung etwas kaputt wofür der BCC verantwortlich gemacht werden kann.

In der professionellen Anwendungsentwicklung benutzt man automatische Unit-Tests um solchen Fehlern auf die Schliche zu kommen.
Die gibt's bei BrightEyes noch nicht werden von mir aber in Erwägung gezogen, wenn die Zeit dafür reif ist.

Solche Warnungen wie: "Blos nicht die Optimierung einschalten." werden (manchmal zu Recht) immer noch in Programmiererkreisen geflüstert.
Daher sind meine Anforderungen an korrekte, portable Programmierung berechtigt.
Ich bin mir allerdings auch bewusst, dass 1992 das Entwickeln von Software sehr mühselig und frustrieren war und ziehe den Hut vor Guido und Jochen.
Das gleiche gilt auch für die Entwickler von Compilern. Nach schlimmer als unter Windows etwas zu entwickeln war es unter DOS.

Dieser mögliche Fehler tritt übrigens in GEN nicht auf, da die Optimierung ausgeschaltet ist und imho. diese Funktion gar nicht benutzt wird.


Zum Schiffsreisebug: Es scheint so, dass das, was ich aus dem Assemblercode zurück entwickelt habe, mehrdeutig ist.
Manchmal wird bei unterschiedlicher signedness vom BCC derselbe Code erzeugt, manchmal nicht.
Im aktuellen Zustand von Schick in Bright-Eyes fällt es mir im Moment auch schwer etwas verlässliches zu sagen.
Hab das aber im Hinterkopf.

[Obi-Wahn]

Die Bildvergößerung geht jetzt wieder unter Linux.

[Obi-Wahn]

Die Bildvergößerung geht jetzt wieder unter Linux.

Und wieder nicht. Keine Ahnung, ob es vielleicht ein Fehler auf meiner Seite ist...

[HenneNWH]

Es sieht ganz danach aus. An diesen Codeteilen hab ich lange nichts mehr gemacht und halte das bisher theoretisch für stabil.

Mit dem Clang und OpenMP hab ich auch
einen kleinen Erfolg gehabt. Da sind händisch
im Makefile_old die Variablen CC und CFLAGS
auszukommen Tieren und bei den beiden Clang-Varianten die # am Anfang der Zeile zu entfernen.

[HenneNWH]

Die Bildvergößerung geht jetzt wieder unter Linux.

Und wieder nicht. Keine Ahnung, ob es vielleicht ein Fehler auf meiner Seite ist...

Hab gerade noch paar Tests dazu gemacht und konnte manchmal soetwas reproduzieren.
Nach dem Resize habe ich jetzt ein Neuzeichnen des Fensterinhalts angestoßen.
Probier mal ob es jetzt bei dir besser ist.

P.S.: Unter Linux mit Clang ist die installation des Pakets libomp-dev notwendig.

[Obi-Wahn]

Ja. scheint zu funktionieren. Super! :-)

[HenneNWH]

Na Klasse.
Hab gerade noch ein unentdecktes "Feature" mit den deutschsprachigen DSAGEN.DAT Files freigelegt.
Das sieht man im Expertenmodus. ;-)
Schönen Sonntag!

[Alrik Alrikson]

Na Klasse.
Hab gerade noch ein unentdecktes "Feature" mit den deutschsprachigen DSAGEN.DAT Files freigelegt.
Das sieht man im Expertenmodus. ;-)
Schönen Sonntag!

Welches "Feature" wäre das denn?

[HenneNWH]

Erzähls uns, nachdem du es ausprobiert hast.

[HenneNWH]

Hab noch zwei weitere Features hinzugefügt, die nicht ganz so offensichtlich sind:
* positive Attribute sind jetzt DSA3-Regelkonform: 8 * W6+7, ein minimaler Wert wird weggelassen
* der Hintergrund von Zeichen bleibt erhalten (keine unfreiwilligen schwarzen Boxen)

[Obi-Wahn]

Mein Standard-Test des neuen Builds hat unter Windows einen potentiellen Fehler ergeben. Ich kann bei der Umwandlung der Talentsteigerungen nichts mehr eingeben. Siehe Screenshot.

Eine andere Sache noch, die schon längst ansprechen wollte. Beim Build mit cmake gibt es einen Fehler bei der Benennung. Die Exe bekommt den folgenden Namen "ngen_cc.exe.exe" ein ".exe" zu viel. Kannst du das "kürzen"?

[HenneNWH]

Thx, das ist nur ein Darstellungsfehler. Die Eingabe funktioniert weiterhin, nur wird im Moment die Zahl nicht angezeigt.

Ich bin noch in der Überarbeitung der modernen Grafikausgabe und bin noch nicht ganz am vorderen Ende des Bildschirms angekommen. ;-)

Das periodische Rendern habe ich entfernt, da es seltsamerweise auf dem Raspi nicht funktioniert hat.

Mit CMake unter Windows hatte ich bisher noch gar keinen Erfolg.
Was hast du denn installiert und welche Variante benutzt du (NMake, MSYS, Mingw)?

[Obi-Wahn]

Ich habe MSYS installiert und dort mingw64. Für SDL2 habe ich einfach dieser Anleitung biz. Hinweisen gefolgt: https://gist.github.com/thales17/fb2e4cf...4c6e832ad2

MSYS erscheint mir als Laie als die "einfachste" Umgebung.

[HenneNWH]

Okay, Danke.

Aktuell gibt es noch mehr solcher Unstimmigkeiten.

[HenneNWH]

Bin jetzt wieder zufrieden mit NGEN. :-)
Mit der Taste '6' kann jetzt als mini-Feature zwischen Anfänger- und Fortgeschrittenenmodus gewechselt werden.

Mit Msys2 sieht das Ganze schon etwas erfreulicher und komfortabler aus. :-)

[Obi-Wahn]

Da war aber jemand heute morgen echt fleißig!

Anbei ein neuer Windows-Build.
  BrightEyes_2025_06_28.zip (Größe: 1,2 MB / Downloads: 1)

[HenneNWH]

Danke, Obi-Wahn.

Mit Msys bin ich gestern Abend abgestorben und weiß noch nicht, wann ich in dieser Hinsicht weitermache.

Heute habe ich etwas Aufräumarbeiten in der Grafikabteilung gemacht, was sich ausgezahlt hat.
Es gibt kaum noch unnötige Grafikupdates und NGEN läuft schon sehr flüssig, siehe Ausgabe am Ende in der Textkonsole.
Das einzige was hierbei noch unperformant mit SDL2 ist, sind die GUI-Elemente (info- und radiobox).
Aktuell wird noch bei jeder Zeichenkette und jeder Kachelzeile in GUI-Elementen ein Textur-Update gemacht.
Natürlich arbeite ich daran.

Weiterhin wurden einige globale Variablen entfernt um den Code nachvollziehbarer (u.U sogar formal beweisbar oder automatisiert testbar) zu machen.
Dafür hab ich ein Auge entwickelt und sehe schnell, wenn etwas nicht stimmt.
Beispielsweise wurde eine Unstimmigkeit von mir behoben, welche im Anfängermodus dazu führt, dass ein Held eine negative Anzahl von Talent- und Zaubersteigerungen hat.
Test: Im Anfängermodus einen Typus auswählen => mit '6' in den Fortgeschrittenenmodus wechseln => feststellen dass alles passt. :-)

[Obi-Wahn]

Läuft bei mir gut. Einmal war kurzzeitig die Eingabe durch Maus oder Tastatur nicht mehr möglich, dass konnte ich aber nicht reproduzieren. (Edit: Ich hatte die Namenseingabe offen)

Edit: Gibt es jetzt eigentlich etwas beim Char-Gen, was noch gar nicht funktioniert? Oder geht es jetzt "nur" noch ums Optimieren?

[HenneNWH]

Läuft bei mir gut. Einmal war kurzzeitig die Eingabe durch Maus oder Tastatur nicht mehr möglich, dass konnte ich aber nicht reproduzieren. (Edit: Ich hatte die Namenseingabe offen)

So etwas hatte ich vor einiger Zeit auch schon erlebt. Mittlerweile ist dieser Fehler schon lange nicht mehr aufgetreten.

Edit: Gibt es jetzt eigentlich etwas beim Char-Gen, was noch gar nicht funktioniert? Oder geht es jetzt "nur" noch ums Optimieren?

Die Funktionalität, abgesehen von der MIDI/AWS-Musik, ist aus meiner Sicht vollständig.
Die Fehler, welche ich gefunden habe, wurden schon behoben.
Aktuell ist es eher wie eine große Formel umstellen, damit man "etwas sieht". :-)

Heute habe ich ein paar Unstimmigkeiten beim Lesen aus der DSAGEN.DAT entfernt. Technische DOS-Limits.
Mein Bestreben ist es, die Abhängigkeiten zu reduzieren, die Software flexibler zu machen und an aktuelle Anforderungen anzupassen.
Das sind große Vorhaben, aber es geht gut voran.

Ein wichtiger Punkt ist, die Nutzdaten (Held) weitestgehend von der Darstellung zu trennen.

Probier mal die neue Version. ;-)

[Obi-Wahn]

Mein Bestreben ist es, die Abhängigkeiten zu reduzieren, die Software flexibler zu machen und an aktuelle Anforderungen anzupassen.
Das sind große Vorhaben, aber es geht gut voran.

Ein wichtiger Punkt ist, die Nutzdaten (Held) weitestgehend von der Darstellung zu trennen.

Probier mal die neue Version. ;-)

Sehr gut, wenn wir mal irgendwann BrightEyes für den "normalen" Spieler nutzbar machen wollen, wären etwas weniger Abhängigkeiten bestimmt hilfreich!
Im Moment bekomme ich BrightEyes leider auch nicht mehr auf dem SteamDeck zum Laufen. Da SteamOS ein immutable OS ist, bekomme ich gerade SDL2_Mixer nicht zur Verfügung gestellt...
Wobei man für Linux natürlich auch ein Flatpak/AppImage/Snap erstellen könnte.

Zum neusten Build: Ist ein bisschen grau geworden.