Themabewertung:
  • 2 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Der HEX-Thread / Spielstandsprobleme
(10.01.2019, 15:14)20mithrandir schrieb: Den Zwölfen zum Gruße!

Nachdem ich den jährlichen Nordlandtrilogie Run mit der Schicksalsklinge gestartet hatte, bin ich über die alten Beiträge zu den DSA 1 Heldenporträts gestoßen. Kunar hatte da sehr viele Details herausgearbeitet. Ich habe mal ein (kaum getestetes) kleines Tool geschrieben, mit dem man neue Grafikdateien in die CHR Dateien importieren könnte. Dazu werden sie auf die DSA Palette gemappt mit einem Distanzalgorithmus, den ich mir von hier abgeschaut habe:
* https://www.compuphase.com/cmetric.htm


Das Ergebnis ist allerdings nur bedingt schön :D, siehe Attachement (Screenshot mit 6 neuen Charaktergrafiken).

Das Tool habe ich auf Github gestellt (kann jeder gerne clonen/forken/beitragen):
* https://github.com/ptaucher/dsatools/tree/develop

Eine aktuelle Version (sehr raw draft allerdings, ganz ohne Klimbim und Fehlerbehandlung) gibt es auch als Attachement (einfach mit java starten bzw. "java -jar dsatools-0.0.1.jar" in einer Konsole).

Ich wollte nur mal fragen, ob dazu überhaupt noch Interesse bestünde. Ich hab's eigentlich nur mal schnell gemacht, als eine Art Machbarkeitsstudie :D

Ich finde es super! Sollte irgendwo verlinkt werden, wo es nicht untergeht :D
Zitieren
Ok. Dann werde ich morgen oder übermorgen noch einmal ein bisserl herumtüfteln (z.B. in die DSA Palette umwandeln bevor die Grafik skaliert wird), und mal schauen, ob es nicht doch brauchbare Ergebnisse liefert mit meinen Testportraits (und mal noch zwei, drei dazu suchen).
Zitieren
So. Ich habe herausgefunden, dass das Problem mit der Qualität hauptsächlich am Skalieren selbst liegt und habe da ein paar Algorithmen ausprobiert (so ca. 20 ; - ) ... am besten scheint Lanczos3 von der Image Scaling Bibliothek von Morten Nobel zu sein:
https://mvnrepository.com/artifact/com.m...ling/0.8.6

Nachdem ich das jetzt verwende habe ich einen Test mit den zwölf angefügten Portraits gemacht. Ich habe die Möglichkeit eingebaut, mehrere Dateien auf einmal zu konvertieren. Es wird dann für jede eine CHR Datei erstellt mit dem Porträt drinnen (aktuell sind das alle Gaukler, müsste man dann editieren oder halt nur die Bild Bytes herauskopieren ; - ).

Siehe Screenshot von den zwölf Charakteren. Die Originale und generierte CHR Dateien findet ihr in TEST.zip.

Außerdem habe ich die CHR Dateien angehängt, die ich mit sämtlichen DSA Portraits erstellt habe (1 bis 3 inkl. NSCs) in DSA.zip. Vielleicht helfen die jemandem.


Angehängte Dateien Thumbnail(s)
   

.zip   DSA.zip (Größe: 463,51 KB / Downloads: 2)
.zip   TEST.zip (Größe: 319,66 KB / Downloads: 2)
.zip   dsatools-0.0.2.jar.zip (Größe: 1.009,53 KB / Downloads: 2)
Zitieren
Finde ich sehr cool. Ich nehme an, mit ein kleinwenig Vorab-Optimierung der Grafiken bekäme man auch noch die grauen Flächen in einigen der Gesichter weg.
Zitieren
Wollte ich auch schreiben. Sehr cool.

Besonders der Screenshot "hat was". :up:
Zitieren
So Jungs. Ich habe einen Bug korrigiert, der die CHR Dateien leider unbruachbar gemacht hatte (sorry for that). Die aktuelle Version 0.0.2 könnt ihr via Github herunterladen (hoffe ich):

* https://github.com/ptaucher/dsatools/blo...-0.0.2.jar

Ich habe das noch einmal mit vier Ausgangsbildern getestet (siehe Attachements -> 3 x Conan und 1 x ich selbst ; - )
Dazu habe ich die In-die-DSA-Palette konvertierten Dateien aus einem Durchlauf etwas nachbearbeitet (mit Faststone Image Viewer und Artweaver ... beides Freeware).
1. Ausgangsbild -> Konvertieren (z.B. ConanA1)
2. Ergebins aus 'large_palette' nehmen und nachbearbeiten (z.B. Weichzeichner drauf und Farbintensität anpassen)
3. Ausgangsbild 2 -> Konvertieren (z.B. ConanA2)
4. Ergebins aus 'large_palette' nehmen und nachbearbeiten (z.B. Hintergrund rausradieren/angleichen)
5. Ausgangsbild 3 -> Konvertieren (z.B. ConanA3)

Die Ergebnisse schauen eigentlich ganz brauchbar aus. Ich bin ja kein 'Profi' bei Bildbearbeitung und habe das nur sehr 'rasch' ausprobiert :D

Also die beiden erwähnten Tools findet ihr hier:
http://www.faststone.org/FSViewerDownload.htm
https://www.artweaver.de/de/download

Weiß jemand, wo die Binärdaten für die Porträts in Schweif und Riva zu finden sind? Es gab da ja mal (wenn ich mich recht erinnere) so ein nltpack tool, wo man die DAT Dateien auspacken konnte. Vielleicht besteht ja doch auch eine Möglichkeit hier etwas auszutauschen, um auch in Teil 2 und 3 mit dem Arnold als Charakterbild herumzulaufen?


Angehängte Dateien Thumbnail(s)
       

.zip   TEST.zip (Größe: 3,65 MB / Downloads: 0)
Zitieren
In Sternenschweif und Schatten über Riva wird keine Kopie des Porträts in den Charakterdaten gespeichert, sondern nur der Index des Porträts in CHEADS.NVF und CHEADS2.NVF (Porträtvarianten für krank/verletzt) aus STAR.DAT bzw. RIVA.ALF.
Zitieren
Die Variante mit eigenem Portrait finde ich gerade besonders witzig. Stelle mir da Portraits der Pen&Paper-Rollenspielgrupe vor. :lol:
Zitieren
Danke für den Hinweis @Borbaradwurm. Ich habe mal in die HEADS.NVF (und CHEADS.NVF/CHEADS2.NVF) aus Sternenschweif geschaut ... und testweise die ersten 1024 bzw. die letzten 1024 bytes angeschaut. Entweder muss ich da ganz andere Offsets benutzen, oder es ist eine andere Palette als für die Schicksalsklinge benutzt worden. Ich bekomme mit der DSA1 Palette sonst nur Müll (siehe Attachement). Weiß jemand, wie das File aufgebaut ist ... bzw. kann jemand bestätigen, dass hier eine andere Farbpalette zum Einsatz kommt?


Angehängte Dateien Thumbnail(s)
   
Zitieren
Die Palette ist eine andere und die ist in der NVF-Datei gespeichert.
Zitieren
Danke. Das schaut schon vielversprechend aus. 

Auf Anhieb finde ich aber nicht, wo die Palette (mit Palettengröße) beginnt, da mir nicht klar ist, was genau 'Kompressionsgröße 1 bis n' und 'Pixeldaten 1 bis n' bedeutet. Also was 'n' in dem Fall ist :) ... 

Ich habe in CHEADS z.B.
* 0x02
* 135 Texturen
* 32 Breite
* 32 Höhe
* Dann kommen anscheinend die Kompressionsgrößen (z.B. 132, 132, 152, etc.)
** > Wenn das jetzt auch 135 x 4 Bytes wären, ginge das von 0x0007 bis 0x0223 ... es schaut aber eher so aus, als würde es bis 0x0226 gehen
* Dann müssten 'Pixeldaten' kommen, also auch 135, wäre dann von 0x0224 bis 0x02A9 (oder von 0x0227 bis 0x02AE)
* Dann wäre die Anzahl der Farben (03 6A) 27139 oder (bei 136 statt 135) dann (25 A8) 35365
* >  Ich weiß nicht, ob das realistisch ist

Sorry, wenn das ein bisserl unbeholfen meinerseits rüber kommt :D


Angehängte Dateien Thumbnail(s)
   
Zitieren
n bezeichnet in der Tabelle die Anzahl der enthaltenen Texturen.
Formel fürs Offset der Farbanzahl bei NVF-Typ 2:
Code:
Größe des NVF-Headers (= 3)
+ Größe des Texturenblocks (= 4)
+ Größe des Kompressionsblocks (variabel = Anzahl der enthaltenen Texturen * 4)
+ Größe des Pixeldatenblocks (variabel = Summe aller Kompressionsgrößen im Kompressionsblock)
oder wenn die Farbanzahl bekannt ist:
Code:
Dateigröße - (2 + (Farbanzahl * 3))

Anzmerken wäre noch das CHEADS.NVF in STAR.DAT und CHEADS.NVF in RIVA.ALF nicht dieselbe Datei sind.

Ich weiß zufällig das die Farbanzahl in beiden Fällen 256 ist, dadurch ergeben sich folgende Offsets

Offset der Farbanzahl in CHEADS.NVF aus STAR.DAT ist 81955, Wert ist 0x0001 = 256.
Offset der Farbanzahl in CHEADS.NVF aus RIVA.ALF ist 81963, West ist 0x0001 = 256.

Wobei VGA-Paletten mit 256 Farben mit Vorsicht zu behandeln sind: z.B. die Porträts definierien nicht  alle 256 Farben der DOS-VGA-Hardware-Palette.
Zitieren
Wow. Danke nochmals für die detaillierte Antwort. Das hilft mir sehr weiter.
Zitieren
Ok. Also ist die Palette einfach die letzten 256 * 3 = 768 bytes, wenn ich das richtig verstehe. Aber wie komme ich zum byte Wert dieser 3-UnsigneByte-Farben, die ich da herauslesen kann? z.B. die erste wäre dann einfach #000000 -> ist das dann 0 (und die letzte Farbe i der Palette 255) als byte Wert?
Zitieren
(29.01.2019, 17:01)20mithrandir schrieb: Ok. Also ist die Palette einfach die letzten 256 * 3 = 768 bytes, wenn ich das richtig verstehe. Aber wie komme ich zum byte Wert dieser 3-UnsigneByte-Farben, die ich da herauslesen kann? z.B. die erste wäre dann einfach #000000 -> ist das dann 0 (und die letzte Farbe i der Palette 255) als byte Wert?
Ja, da die NVF-Palette enthält Farben als:
Code:
uint8_t r;
uint8_t g;
uint8_t b;
Das bedeutet um dem Farbindex aus den Pixeldaten den Offset der Farbe zu errechnen:
Code:
(Offset-der-Farbanzahl + 2) + (Farbindex * 3)
Wobei die Farbkanäle (RGB) in 6 Bit codiert sind (VGA Hardwarelimitatiton). Die kleinste verfügbare Interger Variable des Intel 386 war 8-bit weshalb die Farben zu dunkel aussehen. Um die Farbkanalwerte von 6-bit zu 8-bit zu konvertieren:
Code:
(6-bit-Wert * 255) / 63 = 8-bit-Wert
Der Konvertierungsfaktor von 4 aus den Bright-Eyes-Wiki ist übrigens falsch (richtig ist ≈4.04762).
Zitieren




Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste