Zitat:Es ist der Binäräquivalenztest, der mich vor Fehlern bewahrt.
ja das ist unschlagbar - es bleibt garantiert so falsch wie es vorher war
So kann man es auch formulieren...
(20.12.2025, 13:50)llm schrieb: @siebenstreich
wenn du die Routine frei stehend aufrufen willst ist das ein kleiner statischer Test - der vor der main aufgerufen wird, kann man dann schön rein debuggen
einfach hinter die GUI_name_inflect_with_article-Funktion kopieren
Danke für den Tip!
Aha, die Idee ist wohl die Funktion über den Konstruktor eines static struct auszuführen. Das ist doch eigentlich ein C++-Konstrukt. Interessant, dass das in diesem C-Projekt auch funktioniert.
20.12.2025, 20:39 (Dieser Beitrag wurde zuletzt bearbeitet: 22.12.2025, 08:34 von llm.)
(20.12.2025, 18:57)siebenstreich schrieb: Danke für den Tip!
Aha, die Idee ist wohl die Funktion über den Konstruktor eines static struct auszuführen. Das ist doch eigentlich ein C++-Konstrukt. Interessant, dass das in diesem C-Projekt auch funktioniert.
die Datei-Endungen sind .cpp also wird vom BCC, MSVC und gcc C++ angenommen (die meisten Kompiler reagieren auf die Datei-Endung)
der gcc kompiliert C++ - er zieht nur nicht automatisch die libstdc++ library wie der g++ (g++ ist mehr oder minder gcc -x c++ -lstdc++ ...)
außerdem sind die Schick Quellen nicht pure C - wenn man C kompilierung in CMakeLists.txt mit add_compile_options(-x c) forciert - also gcc -x c, fehlen hier und dort ein paar struct Angaben usw.
die so nur mit C++ funktionieren, bin mir unsicher ob das kompilieren mit C++ nötig ist wegen der Binäräquivalenz oder ob das einfach so passiert ist
aus der TEST-Class kann man auch eine eine statische Funktion machen
Code:
int TEST_GUI_name_inflect_with_article()
{
init_memory();
init_text();
char* x = (char*)GUI_name_inflect_with_article(
INFLECT_INDEFINITE_ARTICLE | INFLECT_SINGULAR | INFLECT_1ST_CASE,
ITEM_SAEBEL,
INFLECT_NAME_TYPE_ITEM
);
return 1234; // dummy
}
static int TEST_GUI_name_inflect_with_article_result = TEST_GUI_name_inflect_with_article();
neues In App Menü (Hauptmenü und Ingame Menü) mit Maus und Tastatur Navigation
dynamisches Lichtsystem mit Tag und Nacht Rhythmus
Musikplayer
Runtime Fonts mit deutlich schärferer Schrift
Öffnen anderer ALF Archive bzw. gezieltes Laden von DUNGEON.ALF, zum Beispiel aus Demo Versionen
Extraktion der Spieldateien sowie Konvertierung einiger Bild- und Videoformate (ACE, AIF, NVF, AAF)
Gerade das neue Fontsystem mit endlich scharfen Schriften (MonoGame litt darunter) und die neuen Erkenntnisse, die ich zusammen mit Shihan und per Stack Tracing gefunden habe, machen mich neugierig, nochmal Schritte in Richtung einer bespielbaren HD beziehungsweise 4K Version zu machen. Vielleicht finde ich ja 2026 wieder etwas mehr Zeit dafür.
Über Anregungen und Feedback freue ich mich immer, besonders kritisches, oder wenn etwas hakt.
[Edit: Direkt nach Alpha 2 gibt es Alpha 2.1: AAF-Videoexport gefixt, und neue experimentelle Flacker-Engine.]
Großartig, lieber cmfrydos!
Hab alle drei Versionen heruntergeladen und in den Ferien endlich mal in Ruhe ausprobiert - hauptsächlich in Riva Stadt plus kurz mal in einigen Dungeons...
Es gibt einige Anmerkungen :
Bei Alpha 2 bzw. 2.1: am auffälligsten ist eine deutliche Verpixelung bei Objekten im Vordergrund (Pflasterstein, Wasser in der unteren Monitordrittel bzw. Wände, Holz etc.)
Bei der alten Alpha 1 Version ist das alles einfach nur etwas verschwommen, was natürlicher wirkt.
Was bewirkt übrigens die "Vertex-Anzeige"? Bei mir erscheit nur ein kleines rotes Quadrat, nicht anklickbar.
Ansonsten ist die Version Alpha 2.1 sehr komfortabel, zB. die Zeitstreckung!
A propos Streckung: schön, daß man auch zwischen Proportionen umschalten kann - da rätsele ich übrigens die ganze Zeit, was eigentlich richtig wäre...
"Originalhöhe" stimmt geometrisch, wirkt aber sehr ungewöhnlich (jedenfalls erscheint bei mir im Originalspiel, also in der DosBox ein etwas gestreckteres Bild).
Das merkt man sofort zB. bei der Laterne am Traviatempel, Praios-Amulett an der Wand (Gruft) oder Kurbelrad im Magierturm. Oder habe ich eine falsche DosBox Einstellung?
P. S. "Experimentelles Flackern" finde ich eindeutig besser, natürlicher!
11.01.2026, 17:52 (Dieser Beitrag wurde zuletzt bearbeitet: 11.01.2026, 20:22 von cmfrydos.)
Danke für dein Feedback, violeverde. Das ist super hilfreich!
Zu deinen Punkten:
1) „Verpixelung“ (Alpha 2/2.1) vs. „verschwommener“ Eindruck (Alpha 1)
Das ist hauptsächlich eine Frage des Texture-Samplings. In der nächsten Version wird es im Menü eine einfache Auswahl geben, ob man lieber „pixelig“ (Point/Nearest-Sampler) oder „verschwommen/weich“ (Linear-Sampler) möchte.
2) Vertex-Anzeige (rotes Quadrat)
Die Vertex-Anzeige ist ein Überbleibsel aus einem alten Debug-Experiment und ist aus Versehen im Build gelandet.
Das war nur eine Spielerei: Es wird jeweils der nächstgelegene Vertex rot markiert. Das zugehörige Objekt kann man dann mit Strg+X aus der Welt löschen.
Mit Strg+L lässt sich ein Vertex fest markieren, der dann grün dargestellt wird. Während das Enter-Menü geöffnet ist, kann man diesen grünen Vertex anschließend mit der Maus in der Ebene verschieben.
Wie gesagt: Das war eher experimentell und hat nicht so gut funktioniert wie erhofft, deshalb fliegt es raus. Dafür wird es neue, bessere Debug-Ansichten geben.
3) Proportionen / Seitenverhältnis („Originalhöhe“ wirkt ungewohnt)
Das Thema ist leider nicht eindeutig, weil das Original je nach Inhalt und Ansicht nicht immer konsistent wirkt. Als Faustregel gilt: Dinge, die geometrisch rund sein sollten, sollten auch rund wirken. Am Ende ist es aber auch eine Geschmackssache.
Darum wird es neben dem Umschalten auch eine feinere Anpassung geben, damit man es nach eigenem Empfinden einstellen kann.
P.S. „Experimentelles Flackern“
Freut mich, dass dir das besser gefällt. Das wird noch weiter abgestimmt, damit es atmosphärischer wirkt.
Im Hintergrund ist in letzter Zeit viel passiert und es ist noch einiges geplant. Ich möchte aber erst wieder etwas veröffentlichen, wenn es insgesamt rund und stabil ist.
Da möchte ich mich violeverde anschließen. Der Viewer hat ja echt noch mal einen gewaltigen Sprung gemacht. Toller Arbeit, cmfrydos
Das Flackern ist richtig gut und gefühlt nah am Original. Habe das jetzt nicht detailliert verglichen, sondern sehe das einfach nur nach Erinnerung so.
Auch gut, dass du planst, die Streckung konfigurierbar zu machen. Das hatte mich bei meinen Recherchen im 3DM-Format auch immer irritiert, denn so, wie die Daten gespeichert sind, sieht es im Spiel einfach nicht aus.
13.01.2026, 17:58 (Dieser Beitrag wurde zuletzt bearbeitet: 13.01.2026, 20:09 von cmfrydos.)
Danke fürs „Zuvorkommen“, Shihan. Sehr zuvorkommend! Und danke für das Lob!
Auf meinem YouTube-Kanal gibt es auch zwei ältere, unkommentierte Showcase-Videos mit Zwischenständen zwischen Alpha1 und Alpha2. Man muss etwas durchskippen, um die interessanten Stellen zu finden. Es sind teilweise DOSBox und teilweise der HD-Viewer im Wechsel zu sehen.
Ich möchte noch nicht zu viel von dem spoilern, was da gerade so vor sich hin brodelt, aber in den letzten Wochen ist das Projekt von einem reinen 3D-Viewer zu einer umfassenderen, „moderneren“ Frontend-Engine gewachsen.
Dabei sind auch ein paar der übrigen Dateiformate gefallen:
.MOV / .MOF sind größtenteils entschlüsselt und stellen die Autobewegungen der verschiedenen Events dar. Es handelt sich dabei grundlegend um Input-Replikationsmechanismen (wie Laufen, Strafen, Umgucken usw.) und nicht um absolute Datenpunkte!
Dieses direkte Aufzeichnen und Wiederabspielen von Eingaben ist schön einfach (wir hatten im Studium auch mal ein Spiel entwickelt, das sich im Kern darum drehte), aber eben sehr wacklig, wenn Aufzeichnung und Wiedergabe nicht ganz deterministisch sind.
Das erklärt die Probleme, die das Spiel im Release hatte (und die einen Patch nötig machten), und ist für den „externen“ HD-Viewer leider etwas schwer zu kalibrieren, ohne die genauen internen Parameter zu kennen. Aber ich versuche mein Bestes!
Daneben sind die Text-/Dialogformate .LXT und .XDF größtenteils geknackt.
.LXT ist noch eher lückenhaft, da es sehr viele Spezialfälle in den Textbausteinen gibt, während .XDF (die Texte über die Dialogmaske) fast vollständig entziffert ist.
Ich arbeite noch etwas daran und hoffe dann, entsprechende Wiki-Einträge anlegen zu können.
Jetzt meine Frage an euch: Ich meine mich zu erinnern, dass es für Schick oder Schweif schon einmal eine Art Modding-Inspektor gab, der Texte oder Dialoge über eine GUI zugänglich gemacht hat. Das waren noch etwas andere Formate, die aber als Entwicklungsvorstufe dienten.
Ich will ja nicht spickeln, aber das wäre vielleicht doch ganz hilfreich, falls ich das wiederfinden könnte. Die Forensuche hat mich hier leider etwas im Stich gelassen. Kann sich jemand erinnern, wie das Tool hieß oder von wem es entwickelt wurde?
[Edit: Ich habe es jetzt doch selbst wiedergefunden: Es sind ein paar Lua Skripte von Henne! Bin gespannt.. ]
Jetzt, wo ich den letzten Screenshot von Shihan sehe, fällt mir noch was ein.
Das Bücherregal in der Gruft hat ja im Spiel noch einen anderen Zustand: den mit abgebrannten Büchern.
Wie auch die Kerzen im Pentagramm. Ist auch logisch, daß der Viewer den ursprünglichen Zustand zeigt.
Am Eingang in der Gruft aber ist das Praios-Amulett nicht mehr da, sich also im alternativen Zustand befindet (von der Wand entfernt)!
Woran liegt das und kann man auch an den anderen Zustand im Viewer kommen?
(13.01.2026, 18:39)violeverde schrieb: Das Bücherregal in der Gruft hat ja im Spiel noch einen anderen Zustand: den mit abgebrannten Büchern.
Wie auch die Kerzen im Pentagramm. Ist auch logisch, daß der Viewer den ursprünglichen Zustand zeigt.
Am Eingang in der Gruft aber ist das Praios-Amulett nicht mehr da, sich also im alternativen Zustand befindet (von der Wand entfernt)!
Woran liegt das und kann man auch an den anderen Zustand im Viewer kommen?
Teilweise sind die Zustände in den 3D-Daten auch überlagert. Der originale Spielcode aktiviert bzw. deaktiviert entsprechende Objekte manuell, je nach Event. Über Strg-X und eine geschickte Kamerapositionierung kann man versuchen, entsprechende Objekte selbst aus- bzw. einzublenden. Das kann etwas frickelig sein und klappt nicht immer.
In der nächsten Version wird es, neben einem Objekt-Browser über alle Objekte, auch die Möglichkeit geben, über UI-Prompts zwischen diesen Event-Zuständen umzuschalten. Allerdings muss ich viele davon noch manuell einpflegen, weshalb ich nicht garantieren kann, alle zu erwischen. Wann ich das veröffentlichen kann, weiß ich aktuell noch nicht.
(13.01.2026, 17:58)cmfrydos schrieb: Jetzt meine Frage an euch: Ich meine mich zu erinnern, dass es für Schick oder Schweif schon einmal eine Art Modding-Inspektor gab, der Texte oder Dialoge über eine GUI zugänglich gemacht hat. Das waren noch etwas andere Formate, die aber als Entwicklungsvorstufe dienten.
Ich will ja nicht spickeln, aber das wäre vielleicht doch ganz hilfreich, falls ich das wiederfinden könnte. Die Forensuche hat mich hier leider etwas im Stich gelassen. Kann sich jemand erinnern, wie das Tool hieß oder von wem es entwickelt wurde?
[Edit: Ich habe es jetzt doch selbst wiedergefunden: Es sind ein paar Lua Skripte von Henne! Bin gespannt.. ]
Super, danke! Genau das Tool meinte ich ursprünglich. Ich hatte mich schon gewundert, mit Hennes Script hatte ich irgendwann nämlich auch schon mal meinen Spaß, und dachte schon, ich hätte die beiden Dinge durcheinandergeworfen. Jetzt ist’s mir wieder klar! Hat definitiv geholfen.
Es werden jetzt 100% aller XDF-Dialogpfade angezeigt. Die verschiedenen Flags für die unterschiedlichen Plots/Storys lassen mich noch etwas rätseln. Es scheint, als ob Dialogschritte sowohl Callback-Funktionen (via ID) aufrufen können, als auch nur unter bestimmten Bedingungen (gesetzte Flags) angezeigt werden.
Der Riva-Demo-Debug-Build hat zwar mehrere Konsolen für Flags, aber die waren bislang nicht wirklich hilfreich. Spannend wäre definitiv, diese in den globalen Daten zu identifizieren und auslesbar zu machen.
Ich denke, das Gespräch im Badehaus (mit Maren Aberdan) wäre ein gutes Beispiel: Nach dem Einleitungssatz sind die folgenden Abschnitte nur dann sichtbar, wenn Eventflag 22 gesetzt ist. Hierbei könnte es sich z. B. darum handeln, ob ein männlicher Held in der Gruppe ist. Danach wird Trigger 28 ausgeführt. Das könnte eine Funktion sein, die z. B. eine Probe auf CH ablegt und je nach Ergebnis Eventflag 23 oder 24 setzt. Danach wird ein weiterer Trigger (13) ausgeführt, worum auch immer es sich dabei handelt.
Es wäre folglich ganz nützlich, bald einmal,
a) die Speicherstelle der Event-/Dialog-Flags anzuschauen, und
b) herauszufinden, ob es eine „Callback-Liste“ (oder einen dicken Switch-Block) für die Event-Trigger innerhalb der Dialoge gibt, die von allen Dialogen geteilt wird.
16.01.2026, 21:01 (Dieser Beitrag wurde zuletzt bearbeitet: 16.01.2026, 21:21 von cmfrydos.)
Ja, gewissermaßen. Ziel wäre es, einige größere „UI-/Medienfunktionen“ bzw. Screens für hochauflösende Auflösungen nachzubauen. Gleichzeitig hilft mir das Nachbauen der Visualisierung dabei, den Originalcode besser zu verstehen.
Ich konnte inzwischen einiges an Code rund um die Dialoge identifizieren. Allerdings sind die Bedingungen keine einfachen gesetzten Flags, sondern ebenfalls Switch-Logik im Code: Hinter jeder ID steckt ein Case, der die entsprechende Prüfung ausführt. Die Konditionen [RVA 0x55650] sind damit quasi Prädikate (sie führen Code aus und liefern einen Wahrheitswert zurück), während die Trigger/Actions [RVA 0x56030] Code ausführen und dabei vor allem Zustände ändern.
Trotzdem gibt es definitiv einen Block an Flags [Object2 RVA 0x1bca74] in den globalen Daten, der sehr häufig eine Rolle spielt. Es lohnt sich vermutlich, diesen während der Laufzeit sichtbar zu machen bzw. zu visualisieren.
Ich habe außerdem testweise einen Libretro-DOSBox-Kern in den Viewer integriert. Lizenzrechtlich ist das allerdings nicht ganz trivial: DOSBox ist GPL-lizenziert, und je nach Einbindung könnte das Auswirkungen auf die Lizenzierung des restlichen Projekts haben. Ich muss noch prüfen, ob ich diesen Weg gehen will. Eventuell wäre es für mich aber einfacher, eine Globals-UI dort einzubauen, als mich direkt mit SDL herumzuärgern. Außerdem ließe sich so auch der Tracer vermutlich schöner darstellen und leichter bedienen.
Edit: Lizenzrechtlich dürfte es weniger problematisch sein, eine DOSBox so zu modifizieren, dass sie den Speicher des Spiels nicht als privaten, sondern als geteilten Speicher anlegt. Dann könnte ein externer Prozess wie der Viewer darauf zugreifen, ohne selbst „Teil von DOSBox“ zu werden.
Definitiv eine interessante Idee, die man verfolgen sollte. Allerdings kann es sein, das dafür ein paar grundlegendere Änderungen an der DOSBox nötig sein werden. Wir hatten ja schon mal über das Paging gesprochen, was die DOSBox bei 32bit macht. Bin mir nicht mehr ganz sicher, aber ich glaube, dass es keine Garantien gab, dass der Speicher auch linear aneinander liegt.
Dazu hatte ich letztes Jahr ein paar Experimente gestartet. Ich schau mal, ob ich da was brauchbares ableiten und dokumentieren kann.
(16.01.2026, 07:11)cmfrydos schrieb: Ich denke, das Gespräch im Badehaus (mit Maren Aberdan) wäre ein gutes Beispiel: Nach dem Einleitungssatz sind die folgenden Abschnitte nur dann sichtbar, wenn Eventflag 22 gesetzt ist. Hierbei könnte es sich z. B. darum handeln, ob ein männlicher Held in der Gruppe ist. Danach wird Trigger 28 ausgeführt. Das könnte eine Funktion sein, die z. B. eine Probe auf CH ablegt und je nach Ergebnis Eventflag 23 oder 24 setzt. Danach wird ein weiterer Trigger (13) ausgeführt, worum auch immer es sich dabei handelt.
Dank deinem wunderbaren Logger, kann ich an dieser Stelle mal beisteuern, dass nach dem Einleitungssatz eine CH-Probe+0 auf den Charismatischsten den Gruppe durchgeführt wird, bei dessen Erfolg er die gute Maren verführt. Ob das Geschlecht bei der Auswahl auch eine Rolle spielt, kann ich allerdings nicht mit Gewissheit sagen.
Danke fürs Nachprüfen! Es hätte gut auch eine Betören-Probe sein können.
Es ist immer viel spekulativ, und es tut gut, Dinge definitiv zu wissen.
Das liest sich jetzt so, als würde die Probe bereits im „Prädikat“ bzw. in der Bedingungsprüfung ausgeführt werden,
was nach den neuesten Erkenntnissen ja durchaus möglich sein kann.
Was genau die Trigger hier dann bewirken, müsste man noch im Assembly nachlesen.
Ich vermute außerdem noch eine Geschlechtsprüfung, da in den Textbausteinen das männliche Pronomen „er“
mehrfach eingebaut ist und es keinen alternativen Baustein für eine weibliche Verführerin gibt.
Jetzt wollte ich doch einmal den aktuellen Stand des HD Viewer zeigen:
Dabei die wichtigsten Neuerungen:
- Android-Build inklusive Steuerung
- Rotierende Minimap
- (Größtenteils) verlinkte Dungeon-Ausgänge
- Ground-Level-Erkennung und damit verbundener Laufmodus
- Clicked-Object-Erkennung: Türen lassen sich per Wisch öffnen und schließen
Nächste Schritte:
- Genauere Untersuchung von Karten-Events und Gebieten
- Ermittlung eines Mappings zwischen Positionen und den verschiedenen Gebäuden bzw. Kämpfen
Das UI- und logikverworrene Kampfsystem ist aktuell noch der einzige größere Blocker,
um zumindest einen kleineren Abschnitt (etwa den der Demo) im HD Viewer nachspielbar zu machen.
Vermutlich konstruiere ich eine eigene Kampflogik, wobei sich Details ja recht leicht aus BrightEyes ablesen lassen,
bis auf Kleinigkeiten ist das Kampfsystem dort ja identisch.
19.01.2026, 20:58 (Dieser Beitrag wurde zuletzt bearbeitet: 19.01.2026, 20:59 von Pergor.)
Hach, da wird man richtig nostalgisch, wenn man die Riva-Musik mal wieder hört. Gott, ist das lange her.
(19.01.2026, 17:40)cmfrydos schrieb: Das liest sich jetzt so, als würde die Probe bereits im „Prädikat“ bzw. in der Bedingungsprüfung ausgeführt werden,
was nach den neuesten Erkenntnissen ja durchaus möglich sein kann.
Naja, das kommt, wenn man zum ersten Mal die Gesprächsoption ("Hi!") wählt und von da ab an läuft dann alles automatisch. Danach kommt das auch nicht wieder (oder da steckt noch ein Timer drin, keine Ahnung). Danach öffnet öffnet sich nur noch das gewohnte Fenster mit den standardmäßig zur Verfügung stehenden Gesprächsoptionen.
Eine Gruppe bestehend nur aus weiblichen Helden hat hier keine Chance, das ist richtig. Macht ja auch Sinn, auch wenn man nicht näher erfährt, was Maren und Held X denn nun in ihren Privaträumen so treiben *hust* machen.
Ich lese hier zwar interessiert mit, verstehe aber nur ca. 1,4 % (grobe Schätzung) von dem, was hier geschrieben wird.
: 
