25.03.2023, 12:43
(18.03.2023, 16:47)cmfrydos schrieb: Ich habe den Code über das Watcom Disassembly Tool (https://github.com/fonic/wcdatool) bekommen [..]Cool, das hatte ich nicht auf dem Schirm. Muss ich mir auch mal ansehen. Ghidra ist zwar der Knaller, hat aber bei so altem Zeugs schonmal Schwierigkeiten. Die Kenntnisse über Watcom-Compiler und deren Calling Convention musste ich Ghidra erst beibringen. Danach kam aber ziemlich viel gutes Zeug raus.
(18.03.2023, 16:47)cmfrydos schrieb: Bisher konnte ich etwa 20 Funktionen verstehen, vielleicht 30, wenn man so etwas wie Bildschirmschoner und wahrscheinlich, weil in anderem Codesegment, DOS-Renderschleife mitzählt, die ich nur identifizieren konnte, aber mich ersteinmal nicht interessieren ;D.
Das repräsentiert, wenns man großzügig schätzt, vielleicht 30 der 4083 Funktionen, und etwa 500 der 44109 Funktionsaufrufen.
Hauptsächlich verstanden habe ich bisher nur 3 Würfelfunktionen, 4 Probenfunktionen(und unterfunktionen), 9 EW/TW/ZW Getter/Setter/Adder und eine GebeIndexVonElementInListe Funktion
Wäre es möglich, dass Du mir Deine Asm-Listings und Infos mal zukommen lässt? Dann würde ich die mit meinen Erkenntnissen zusammenbringen und in mein Wiki posten (nebst Deinen neuen Entdeckungen im 3DM). Das würde bestimmt auch Deinen Aktivitäten im Proben-Logger-Thread helfen
Stand heute habe ich eine handvoll Funktionen ganz sicher identifiziert. Dazu gehören viele C-Library-Funktionen und ein paar aus der Watcom-Runtime. Viele weitere kann ich dank der Debug-Ausgaben, die noch drin versteckt sind, zumindest mal einzelnen Code-Files zuordnen. Dazu gehören Funktionen aus:
Die Anzahl der Funktionen ist eine Untergrenze. Vermutlich bekommen viele dieser Dateien am Ende noch mehr Funktionen zugeordet. Habe das etwas konservativ geschätzt.
Es gibt noch mehr Verweise auf CPP-Dateien, aber die konnte ich noch keinen Funktionen zuordnen. Insgesamt hab ich ca. 1400 Funktionen mit Namen versehen können. Die Angaben sind allerdings nicht in Stein gemeißelt, weil das Python-Skript dafür stark heuristisch vorgegangen ist. Aber die Richtung sollte stimmen und könnte helfen.
Überlege mir aktuell, wie man das so dokumentieren kann, dass es lesbar bleibt und Du schnell die Funktionen mit Deinen Asm-Listings und dem Dosbox-Debugger übereinander bringen kannst.
(21.03.2023, 09:56)cmfrydos schrieb: @Shihan, ich glaube du kennst dich mit der Thematik besser aus. Bestätigungen, oder Erklärungen würden mir sehr helfen. Natürlich auch von anderen.
Würde das Licht in meiner Engine gerne so nah wie möglich zum Original implementieren.
Deine Ausführungen passen für mich. Was Du mit diesem Halo-Effekt meinst, spukte auch schon vor meinem inneren Auge herum.
Würde auch denken, dass Gouraud-Shading die Grundlage ist. Das hat den Vorteil, dass man nur die 3-4 Vertices berechnen muss und den Rest im Polygon einfach interpolieren kann. Deshalb glaube ich nicht, dass es Per-Pixel-Shading ist, weil man dabei für jedes identifizierte Pixel ("fragment") diese Berechnungen machen müsste. Das würde in einem Software-Renderer dieses Alters wohl nicht schnell genug laufen. Per-Pixel hat ja erst richtig an Bedeutung gewonnen, als die Graphikkarten zur parallelen Fragment-Auswertung in der Lage waren.
Und ja, um die Face-Infos an den Pixel-Shader zu bringen, geht man den Weg über den Vertex-Shader. Da muss man sich auch keine Sorgen machen, dass die redundanten Informationen Probleme bereiten... die Hardware lacht darüber