Reverse Engineering der NLT II

[Obi-Wahn]

Witzbold.

[Obi-Wahn]

NGEN läuft nach den letzten paar Updates richtig flott und butterweich!

[Obi-Wahn]

Und es läuft immer noch alles gut unter Windows.

[HenneNWH]

Die Popup-Boxen werden im RAM vorbereitet und in einem Schritt auf den Bildschirm gebracht.

[Obi-Wahn]

Die Popup-Boxen werden im RAM vorbereitet und in einem Schritt auf den Bildschirm gebracht.

Danke für die Erklärung. Für Nicht-Programmierer ist es immer interessant, was genau hinter den ganzen Code-Schnipseln steckt.

[HenneNWH]

So, jetzt habe ich eine weitere Verbesserung gepusht.
Die Popup-Boxen werden jetzt an genau einer Stelle im RAM vorbereitet und anschließend in genau einem Schritt auf den Bildschirm gebracht.
Das Verfahren vorher war zweistufig, jetzt ist es einstufig, elegant und so wie ich es haben will, bzw. wie es aktuell (mit Fenstern sein sollte).
Das Rendering ist aus meiner Sicht jetzt vorzeigbar und in einer Qualität, die aus technischer Sicht seinesgleichen sucht.

In der ursprünglichen Version wurde vieles direkt auf den Bildschirm gezeichnet, was damals möglich und richtig war.
Wer die Cycles in der DOSBox auf 1000 runterdreht, kann auch heute noch den langsamen Bildschirmaufbau beobachten.
Auf modernen Systemen führte das bisher zu sehr viel unnötigem Datenaustausch und zu einer verzögerten Darstellung.
Da ich BrightEyes aus der DOSBox herausoperiert habe, kann ich jetzt vieles so anpassen wie ich es für richtig halte
und somit mir bekannte technische Blockaden und Unstimmigkeiten auflösen oder einfache Features implementieren,
welche ich für sinnvoll halte.

Gestern war ich in einem Park und habe mir dort eine kleine TODO-Liste mit Dingen gemacht,
welche ich noch implementieren werde:

• Speichern von CHR-Dateien für die deutschsprachige Diskettenversion
  
• Zwischenspeichern der Typusbilder (analog zu den Hintergrundbildern)
  
• Darstellungsfehler auf dem Raspi2
  
• Antesten von BigEndian Maschinen (PowerPC von älteren Mac-Laptops)
  
• Speichern von LittleEndian-Helden auch auf
  
• MIDI-Musik
  
• den PowerPack 2.0 Dekompressionsalgo vereinheitlicht in C
  
• Trennung von Darstellung und Nutzdaten (= Helden)
  
• ... aber viel weltbewegendes wird dann nicht mehr passieren.
  

[Obi-Wahn]

Das klingt doch nach einem Plan. Ich muss meinen Raspi auch mal wieder rausholen und einen neuen Build machen.

Wie komplex wäre es eigentlich, neue oder andere Charakterbilder einzufügen? Gerade in der Schicksalsklinge sind ja doch recht wenige Bilder verfügbar.

Der Build unter Windows mit makefile_old wirft im Moment ein paar Warnungsmeldung aus, funktioniert aber dennoch. https://github.com/Henne/BrightEyes/issues/11

[HenneNWH]

Angefixt! :-)

Zu den Bildern: Dass diese Frage irgendwann kommt, habe ich schon vermutet.
Prinzipiell ist das möglich, aktuell ist der Zeitpunkt nicht gut.

In Schick ist das Charakterbild direkt als 32x32-Matrix gespeichert.
In Schweif werden etwas schönere Charakterbilder benutzt, welche in der Datenstruktur nur als Index (z.B. Bild Nummer 20) gespeichert werden.
Somit wäre das Aufwand, der zum Spielen der gesamten NLT nicht viel beiträgt.
Wie und ob man das Ganze erweitert sollte, wird entschieden wenn Schick als BrightEyes-Version lauffähig ist
und ähnlich gut funktioniert wie der Charaktergenerator.
Wenn dich das interessiert: Die Farbpalette von diesen Bildern heißt g_pal_heads hat 32 Farbwerte.

Einige der Warnungen habe ich im Makefile_old entfernt und bin mir der Hintergründe bewusst.
Das muss so sein!
Warnungen abschalten ist nur in Ausnahmefällen eine gute Lösung, ail_stub.c ist so eine.
Bei gen_timer_isr() und WinMain() ist das auch möglich.
Die Anderen erfordern andere Ansätze.
Einer sollte noch übrig sein, aber da muss ich konzentriert sein.

EDIT: Das war ich gerade!

[Obi-Wahn]

Die Schwierigkeiten die Bilder über die verschiedenen NLT-Teile mitzunehmen, hatte ich schon vermutet. Ich bin ja schon mehr als glücklich mit dem Port an sich. 

Alle Warnmeldung sowohl unter Windows als auch unter Linux sind weg. Ein neuer Build ist angehängt. Dieses Mal mit den Windows- und Linux-Binaries.

  BrightEyes_2025_07_06.zip (Größe: 1,38 MB / Downloads: 1)

[HenneNWH]

Warnung: Habe gerade entdeckt, dass unter Windows die Dateigröße der mit NGEN generierten CHR-Dateien unterschiedlich ausfällt.

[Obi-Wahn]

Warnung: Habe gerade entdeckt, dass unter Windows die Dateigröße der mit NGEN generierten CHR-Dateien unterschiedlich ausfällt.

Inwiefern fallen sie den unterschiedlich groß aus? Für mich als Laie müsste die Datei eines Magiers und eines Kriegers unterschiedlich groß sein, da beim Magier mehr gespeichert werden muss. Oder sind die Dateien bei mehreren Generierungen von einer Klasse unterschiedlich groß?

[HenneNWH]

Das ist scheinbar eine Windows-spezifische technische Angelegenheit.
Die Datenstruktur für Helden muss immer dieselbe Größe haben (1754 Bytes bei DE_CD und EN_DISK) sonst geht es nicht oder führt zu Problemen.
Meine Beispiele unter Windows haben Dateilängen von 1754-1760 Bytes. Unschön.

Ein Krieger hat darin auch Platz für Zaubersprüche, aber aufgrund des unterschiedlichen Typus sind diese Werte alle 0 und werden vom Spiel ignoriert.

Das Ganze kann zwei Ursachen haben:
1. Der Compiler ändert die Größe der Datenstruktur um effizienten Code zu erzeugen. Das nennt sich Padding und wurde von mir verboten.
    Falls der Compiler doch so etwas tut, wird eine Fehlermeldung ausgegeben. Dort scheint der Fehler nicht zu liegen.

2. Beim Schreiben der Datenstruktur passiert etwas Merkwürdiges.
    Hier ist der Verantwortliche die C-Bibliothek und/oder das Betriebssystem.
    Dafür habe ich auch eine Fehlermeldung hinzugefügt, aber es scheint vorerst behoben.

[Obi-Wahn]

Das ist scheinbar eine Windows-spezifische technische Angelegenheit.
Die Datenstruktur für Helden muss immer dieselbe Größe haben (1754 Bytes bei DE_CD und EN_DISK) sonst geht es nicht oder führt zu Problemen.
Meine Beispiele unter Windows haben Dateilängen von 1754-1760 Bytes. Unschön.

Ein Krieger hat darin auch Platz für Zaubersprüche, aber aufgrund des unterschiedlichen Typus sind diese Werte alle 0 und werden vom Spiel ignoriert.

Das Ganze kann zwei Ursachen haben:
1. Der Compiler ändert die Größe der Datenstruktur um effizienten Code zu erzeugen. Das nennt sich Padding und wurde von mir verboten.
    Falls der Compiler doch so etwas tut, wird eine Fehlermeldung ausgegeben. Dort scheint der Fehler nicht zu liegen.

2. Beim Schreiben der Datenstruktur passiert etwas Merkwürdiges.
    Hier ist der Verantwortliche die C-Bibliothek und/oder das Betriebssystem.
    Dafür habe ich auch eine Fehlermeldung hinzugefügt, aber es scheint vorerst behoben.

Ich habe mal zwei Chars angehängt, die frei gewählt wurden.

Bei Zurgrimm kam diese Meldung:
ERROR: flen = 1756

Bei Kalef diese Meldung
ERROR: flen = 1755

Edit: Unter Linux gibt es gar keine Ausgabe in der Konsole dazu?

[HenneNWH]

Genau so ist es. Dieses Problem tritt nur unter Windows auf.
Dazu kann ich nur sagen: "Na Bill, geht's?"

EDIT1: Danke für die Zuarbeit. Da ich dieses Problem selbst erst am Samstag entdeckt habe,
reicht mir das Feedback von euch, dass es euch auch betrifft.

EDIT2: Folgendes: Es werden (nur unter Windows) laut write() genau 1754 Bytes geschrieben,
aber wenn anschließend die Dateilängen getestet wird, sind es manchmal mehr.

EDIT3: Habe jetzt unter Windows die Datei mit _open() anstelle von _creat() geöffnet.
Jetzt scheint es zu funktionieren.

[Obi-Wahn]

Anbei nochmal Charakter-Dateien, die mit der neuen Version unter Windows erstellt wurden. Die Konsolenausgabe ist auch schon wieder weg?

[HenneNWH]

Unter Windows wird jetzt eine andere Variante benutzt um Dateien zu öffnen.
Die Konsolenausgabe kommt nur, wenn es beim Speichern der CHR-Dateien einen Fehler gab.

Gerax und Parim sind gesund, die kannste behalten.
Kalef und Zurgrimm haben es leider nicht in die Schicksalsklinge geschafft.

[Zurgrimm]

Kalef und Zurgrimm haben es leider nicht in die Schicksalsklinge geschafft.

[Obi-Wahn]

Gerax und Parim sind gesund, die kannste behalten.
Kalef und Zurgrimm haben es leider nicht in die Schicksalsklinge geschafft.

Neeeeeiiiinnn!

Naja, sind ja eh nur aus dem Setzbaukasten.

[HenneNWH]

Hab gerade die Funktion "TYPUS FREI WÄHLEN" überarbeitet, etwas leserlicher gemacht und eine Konsolenausgabe hinzugefügt.
Diese zeigt, die initial gesetzten Attributwerte und die Anforderungen (aus char-gen) an den entsprechenden Typus.

Diese Thread gehört wohl überarbeitet: Aha!

EDIT: Hab soeben BrightEyes mit dem GCC auf GhostBSD kompiliert bekommen!

EDIT2: Läuft! Auch wenn SDL2_mixer die FLAC-Datei nicht erkennt. :-(

[Obi-Wahn]

Oh, danke für die Konsolenausgabe für die Funktion "TYPUS FREI WÄHLEN". Interessant wie die Werte zurecht gebogen werden.
Hier ein Bespiel für einen Thorwaler:

Code:

choose_typus() initial attribute values
        MUT = 12
        KLUGHEIT = 8
        CHARISMA = 10
        FINGERFERTIGKEIT = 11
        GEWANDTHEIT = 9
        INTUITION = 9
        KÖRPERKRAFT = 9
        ABERGLAUBE = 5
        HÖHENANGST = 7
        RAUMANGST = 7
        GOLDGIER = 3
        TOTENANGST = 7
        NEUGIER = 5
        JÄHZORN = 5
choose_typus() attribute requirement adjustments
        MUT >= 12
        KÖRPERKRAFT >= 13
        ABERGLAUBE >= 7
        CHARISMA >= 1

Unter Linux werden die Umlaute nicht richtig dargestellt. Könnte aber auch an meinem System liegen.

Code:

choose_typus() initial attribute values
        MUT = 12
        KLUGHEIT = 8
        CHARISMA = 12
        FINGERFERTIGKEIT = 11
        GEWANDTHEIT = 9
        INTUITION = 12
        K�RPERKRAFT = 8
        ABERGLAUBE = 3
        H�HENANGST = 7
        RAUMANGST = 3
        GOLDGIER = 7
        TOTENANGST = 7
        NEUGIER = 4
        J�HZORN = 7
choose_typus() attribute requirement adjustments
        INTUITION >= 13
        GEWANDTHEIT >= 13
        GOLDGIER <= 4
        CHARISMA >= 1