08.03.2023, 13:14
(Dieser Beitrag wurde zuletzt bearbeitet: 09.03.2023, 17:59 von cmfrydos.
Bearbeitungsgrund: Ergänzungen wegen neuen Erkenntnissen
)
(07.03.2023, 20:38)Shihan schrieb: Kann gerade nicht wirklich viel Zeit für eine Antwort aufbringen, wollte aber ein kurzes Feedback dalassen:
Super Arbeit! Freut mich, dass du hier soviel weiter gekommen bist. Das Video ist großartig.
Wenn ich mental wieder stabiler bin, sehe ich mit nochmal den Assembler-Code an. Die Stellen, wo die Dateien (.3dm, .nei, .dsc, ...) geladen werden, habe ich schon identifiziert.
Danach gibt's aber ein paar indirekte Calls (passiert für gewöhnlich bei virtuellen Methodenaufrufen von C++), deren Nachverfolgung extrem hart ist und viel Debugging braucht, weil man das nur zur Laufzeit sehen kann.
Danke! Mir macht das Knobeln an den Formaten gerade richtig viel Spaß. Das ist schon cool, wenn man nach längerem Probieren und Auswerten zu einer Lösung kommt. Naja das Video.. Ich wollte auf meiner Möhre kein 4k reencodieren, und war daher auf .mkv hintereinanderhängen beschränkt. Der langwierige Tag/Nachtwechsel in Riva nimmt da das Pacing raus, aber ich musste es mal festhalten, um das später schneller abzugleichen.
Das ist überhaupt kein Problem, dass da gerade nicht die Zeit für dich ist, mitzutüfteln. Deshalb halte ich den Progress hier auch fest, damit später, wenn auch erst in ein paar Jahren, daran weitergearbeitet werden kann. Ich denke für mich ist in Riva bald Schluss. Vielleicht schaue ich mir das 3D in Schweif noch an. Zu Riva habe ich leider (noch) nicht die Skills und Tools, um da in Asm Dinge herauszulesen. Spannend finde ich es, aber ich wüsste nicht, wo man anfangen soll. Da dutzende Register und Speicherstellen im Auge zu haben, und überhaupt grob zu verstehen, was dort passiert, ist schon eine hohe Kunst. Und wie überhaupt kann man das Debuggen, wenn das Programm nur in der DOSBox läuft? Dann muss man sicherlich auch die Tools für DOS haben, und darin debuggen?
Ich konnte mal noch teilweise den unbekannten Datenblock in der .3DM entschlüsseln:
Da stehen wie erhofft die Lichtquellen drin! Aber ich vermute fast, noch mehr. Zumindest beim manuellen Nachzählen in den Leveln kam ich nicht ganz auf die Zahl der Einträge (EDIT: Habe die zwei Tageslichteinfälle (Leiter / Feylamia) vergessen. Scheint jetzt zu passen, und gehe davon aus, dass im unbekannten Datenblock nur die Beleuchtung steckt). Spannend wird sein, was der Marker U1 bedeutet. Auch die Daten in U2 und U3 könnten interessant sein. Was für Daten könnte eine Lichtquelle tragen? Richtung geht schlecht, da es nur nach 2 Integern aussieht. Vielleicht zwei begrenzende Radii der (flackernden) Lichtkugel?
EDIT: Scheint genau das zu sein
. In der Boronsgruft gibt es zwei Fackeln, die besonders abweichen:- Eines im ersten Leichenraum, das besonders hell ist (mit hohen U2 und U3-Werten)
- Und eines im letzen kleinen Raum mit dem Fass, dass sehr dunkel ist (mit kleinen U2 und U3-Werten).
U2 und U3 liegen auch immer recht nah beieinander. Es gilt immer entweder U2 == U3 == 0, oder U2 < U3. In Riva gibt es auch immer 2 Lichtintensitäten, zwischen denen die Lichter "flackern". Wahrscheinlich sind es genau die. Ich halte mal die Augen offen, ob ich auf anderen Karten Lichtquellen finde, bei denen U2 und U3 relativ identisch, oder besonders weit auseinander liegen.
Eine Ausnahme gibt es noch: Ein Eintrag in STAR02 (die versunkene Abendstern) hat viel mehr Daten, als alle anderen Einträge.
Das ist wohl ein Licht(?), das relativ weit außerhalb des Schiffes, wenn man in in der Mitte des ersten Raumes steht, etwa in Richtung der Ecke rechts überhalb des Ausganges positioniert ist. Habe glaube ich keinen Speicherstand direkt davor. Vielleicht scheint dort eben ein ganz spezielles Licht durch das löchrige Schiff. Ich habe in der Tabelle alle Daten, die nur für dieses eine Licht vorhanden sind, mit * markiert.
EDIT: Da ist nichts. Es ist technisch gesehen aber auch eine Tages-"Nebel"-Karte (der blau ist), dh. dort gibt es gar keine Lichter bis auf die globale Beleuchtung.
Eventuell steuert es aber genau diese, wobei die Position dann egal ist. Denn auf vielen "Nebelkarten" gibt es missplatzierte Lichter, zB. im Boronsacker, die keine Fackeln oÄ bei Nacht darstellen können.
Interessanterweise gilt bei dem Licht U2==0==U3, was ja vermutlich die Leuchtkraft darstellt. Eventuell auch einfach nur ein Überbleibsel von einem Versuch der Entwickler, die globale Beleuchtung durch eine positionierte Sonne zu realisieren?
------------------------------------------------------------------------------------------------------------------------------------------------------------
Off Typ Name Anmerkung
------------------------------------------------------------------------------------------------------------------------------------------------------------
0 short NameID Als String-Verweis in die String-Tabelle. Hier werden jetzt die bisher unbenutzten Einträge in der String Tabelle benutzt
2 char[4] Enabled Immer 0x00000101, falls Daten vorhanden. Jede Karte hat am Anfang immer 3 leere Einträge stehen
6 short Typ Immer 1 - Nur einmal 3 in STAR02*
8 short Gruppe Damit startet auch der Name, wenn nicht mit "Light" (nur einmal nicht, da startet der Name mit xx)
10 short U1 Entweder 44, 63 oder (nur in MAGT03) manchmal 17
12 int STAR02D1 Immer 0 (fast*)
16 short Null Immer 0
18 short Light? Meistens 0. Wenn der Name mir "Light" startet, immer 1. Manchmal auch sonst 1, dann steht aber immer ein L im Namen
20 int U2 Unbekannt. Fast immer mit Daten voll. EDIT: Ziemlich sicher 1. (geringere) Leuchtintensität / Reichweite
24 int U3 Unbekannt. Fast immer mit Daten voll. EDIT: Ziemlich sicher 2. (stärkere) Leuchtintensität / Reichweite
28 char[8] STAR02D2 Immer 0 (fast*)
36 int X X - Koordinate
40 int Y Y - Koordinate
44 int Z Z - Koordinate
48 char[40] STAR02D3 Immer 0 (fast*)
------------------------------------------------------------------------------------------------------------------------------------------------------------
Die Namen der Einträge tragen als ersten Buchstaben (hinter der Gruppennummer), immer entweder ein F oder L, wenn sie nicht mit "Light" beginnen. Das gesamte Namenschema, das auch Objekte tragen, würde ich gerne noch knacken..
EDIT: Fackeln tragen bisher immer ein F, Sonnenlicht/einfall ein L oder "Light"
Ich denke ich gehe mal so vor, dass ich ein Lichtsystem/-shader in meine Engine einbaue, alle Einträge an ihrer Koordinate platziere, und dann einfach mal gucke, ob was leuchtet, dass nicht leuchten soll
EDIT2: Weil es nur eine kleine Sache ist als edit: Dass genau die .NEI bestimmen, welche Nachbar-Objektgruppen gezeichnet werden, hat sich bestätigt. Entfernt man zB. in der Stadt alles aus der .NEI, wird immer nur die aktuelle Gruppe gezeichnet.
Kollision scheint aber von allen Gruppen aktiv zu sein.
Auch interessant: Die Gruppengrenzen haben stark etwas mit den Zufallsbegegnungen zu tun. Also zB. Käsetoast, oder dass die Wachen an einem vorbeilaufen. Wenn man eine Gruppe wechselt, wird es sehr oft getriggert.
Manchmal aber auch, wenn man eine zu einer Geraden erweiterten Linie anderer Gruppen übertritt. Das aber nicht bei allen, was mich etwas wundert. Aber evtl werden hier einfach sowohl X-Grenzen als auch Y-Grenzen sortiert gehalten, und wenn sich eine wechselt, kann es zu einem Wurf für eine Zufallsbegegnung kommen. Gruppen können sich auch überlappen. Ich bin mir noch nicht ganz sicher, wie gehandhabt wird, wenn man sich in mehreren Gruppen befindet.