Reverse Engineering der NLT II

[cmfrydos]

Hatte das Spiel nicht nur eine DOS-Exe, sondern auch eine für Win32 bzw. Windows 95 in SVGA? Könnte sogar sein, dass es dann ein leicht unterschiedliches Seitenverhältnis hatte.

Vielleicht meinst du die Ingame-Einstellung, manche Videos und Vollbildgrafiken in SVGA anzuzeigen? Das gab es schon unter Dos, und wird dann immer umgeschaltet. Das normale Spiel läuft soweit ich weiß immer in 320x200.

Meine mich auch zu erinnern, dass Riva bei mir in 640x480 lief. Ob das aber die "korrekte" Auflösung ist, weiß ich nicht. ^^

Es ist zumindest die Optik, die sich mir eingebrannt hat.

So ist das auch bei mir. Ich mache es aber trotzdem mal in den Renderer-Einstellungen umstellbar, um vielleicht auch die mitzunehmen, bei denen es sich anders "eingebrannt" hat ;D

So, kurzes Update:

Letzte Woche konnte ich einige der offenen Bugs / Fehlen von Features fixen,
unter Anderem laufen Animationen jetzt rund, neu auch Türen und Weltveränderungen.
Externes Licht (von Fackeln etc.) ist jetzt drin, wobei Per-Pixel / Fragment Shading dem vom Spiel optisch am nächsten kam.
Ich habe noch Multisampling der Helligkeitsstufen getestet, dass die harten Schritte des Originals recht ansehnlich aufweicht.
Wird dann auch als optionales Grafiksetting mit dabei sein.

Die letzten Tage hauptsächlich damit verbracht die native Audiowiedergabe von Musik, Spielsounds sowie das Abspielen der Smacker-Videos
zu implementieren. Das bringt 100% stotterfreien Sound (der theoretisch noch mit Sound-Algorithmen wie einer gegen Clipping verbessert werden kann),
und SVGA-Videos in beabsichtigter Framerate. Auch die Videos könnte man später noch super, aber leider etwas rechenintensiver optimieren.
Getestet habe ich ECCV2022-RIFE zur Frameinterpolation, was aus den häufig nur mit 10FPS codierten Filmen ansehnlich flüssige 40 oder 80 FPS generieren kann.
Außerdem habe ich Video2x probiert, um die Auflösung zu skalieren, allerdings hatte ich hier mit meinen bisher getesteten Settings nur eine kleine Verbesserung für recht hohe Rechenzeit gewonnen. Die Idee wäre, dass man optionalerweise im Viewer erlaubt, "fremde" Videos zu spielen, die man eben vorher über Nacht selbst gerendert / aufpoliert hat.

Naja, generell habe ich zu viele Ideen und aktuelle Baustellen .
Mein Plan für kommende Woche ist daher, das Bestehende nochmal aufzupolieren, Bugs zu fixen,
Usability und Customizability zu erhöhen, und dann die neue Version und Code hier zu veröffentlichen.
Da wird der Probenlogger dann mit dabei sein, aber ich versuche so granular Einstellungen zu ermöglichen,
dass man z.B. nur Probenlogger (mit Bild in DosBox), nur neuen Renderer, aber vielleicht auch Probenlogger neben Spiel anzeigen kann.
In 16:9 hat man ja bisher entweder etwas verzogenes UI, oder schwarze Balken, also wieso nicht die Proben im freien Bereich anzeigen?

Eine Frage habe ich noch. Habt ihr hier andere aktuelle Versionen als die von GoG, zB. Heldenedition, oder die von Steam, und könnt mal schauen,
ob die Musik dort auch irgendwo als Musikdateien rumfliegt, und wenn ja, wo? Bei GoG liegen die Stücke z.B. in /MUSIC/ als .ogg's,
was sich heutzutage deutlich leichter abspielen lässt als die Tracks auf einer CD-ROM.


Edit: Habe noch etwas fürs Wiki @Shihan.
Bin immer mega happy, wenn ich dort schon Infos finde, die mich weiter bringen.
Das zu .AAF .RAW und .SMK hat mir enorm geholfen, braucht aber ein kleines Update:

Spoiler

.ASF-Dateien: (AudioSample File/Format?)
Hierbei handelt es sich um .RAW Audio Dateien (PCM, Mono 8 Bits pro Sample) denen noch ein 20-Byte Header vorangestellt wurde,
wobei im 17. und 18. Byte die Samplerate (in Little-Endian) steht. In Riva kommen nur Werte von 22050 und 11025 vor.
Der Rest des Headers ist immer identisch.

.AAF Dateien:
Mit diesen Dateien werden die Videosequenzen koordiniert.
Es steht schon einiges im Wiki, hier eine Ergänzung des Formates der Spureinträge:

Die ersten 4 Bytes geben nur die Gesamtlänge aller folgenden Einträge an.
Nicht alle Einträge sind wie bisher angenommen 18 Bytes lang, manche sind variabel (Typ 2 und 3).

0x00 VideoID
0x02 FrameID
0x04 Typ, bisher entweder 1, 2 oder 3

Bei Typ == 1: (AudioEffekt)
0x06 AudioID
0x08 Volume1 (Verwendung noch unbekannt)
0x0a Volume2 (Nehme ich derzeit an, dass es das "richtige" Volume ist)
0x0c SampleRate / Pitch
0x0e Noch Unbekannt
0x10 Noch Unbekannt

Bei Typ == 2: (Texteinblendung)
0x06 Unbekannt
0x08 Unbekannt
0x10 Unbekannt
0x12 Unbekannt
0x14 Start eines ASCII-Kodierten, nullterminierten Strings. Nach der Null beginnt der nächste Spur-Eintrag

Bei Typ == 3: (Frageneinblendung)
0x06 Unbekannt
0x08 Unbekannt
0x10 Unbekannt
0x12 Unbekannt
0x14 Start dreier ASCII-Kodierter, nullterminierter Strings. Erst Frage, dann zwei Antwortmöglichkeiten. Nach der Null der zweiten Antwortmöglichkeit beginnt der nächste Spur-Eintrag

Die Texteinblendungen kommen zB. in den Fragesequenzen in der Mine vor, aber ich meine, dass es auch an anderer Stelle Wahlmöglichkeiten gibt.
Z.B bei dem homosexuellen Koch, oder zur Liebesromanze unter Wasser.

Zum unbekannten Datenblock der .3DM:
Das zu den U1 und U2 getauften Werten war etwas Quatsch, und wohl doch nicht allgemeingültig.
Es scheint zwar schon Radien anzugeben, aber dass einer einen Radius angibt, in dem das Licht maximal ist, stimmt so nicht (überall)
Also leider keine neue Erkenntnis außer der Erkenntnis dass es doch noch keine echte Erkenntnis gab.
Sorry, dass das hier so iterativ hin und her geht und Informationshappen nacheinander reintröpfeln.
Dass macht sicher zum Teil keinen Spaß das später ins Wiki zu übertragen...

[cmfrydos]

Kurzes Update:

Irgendwie kommen immer mehr kleinere Dinge dazu, die vor einem Release des Viewers / ResolutionMods noch gefixt werden sollten. Könnte sich also noch etwas verzögern..

Mir ist heute aber eingefallen, dass ich noch kleinere Erkentnisse zu den .ALF Archiven gewonnen hatte, die es teilweise ermöglichen, diese auch so zu packen, dass das Spiel diese einliest. Das scheint nach Wiki bisher noch nicht geklappt zu haben.

Anmerkung: Die folgenden Daten sind noch etwas ungewiss, da es uns noch nicht gelungen ist, ein Riva-Archiv so zu packen, dass das Spiel dieses fehlerfrei nutzen kann. -- Hendrik

In den Riva-Archiven sind die Dateien jeweils Modulen zugeordnet. In der Regel gehört eine Datei in ein bestimmtes Modul, es ist jedoch auch möglich, eine Datei mehreren Modulen zuzuordnen. Im Archiv müssen die Module in einer bestimmten Reihenfolge (nämlich der gleichen wie in der .MOD-Datei, siehe dort) stehen, und innerhalb dieser die Dateien, ebenfalls in fester Reihenfolge. Auf die Module wird über ihren Namen im Archiv zugegriffen. Der Zugriff auf die Dateien erfolgt über deren Index im Archiv und nicht über den Dateinamen.

(https://github.com/shihan42/BrightEyesWi...BCber-Riva)

Bei der Analyse der Dateizugriffe stellte sich heraus, dass auf Archivdateien über zwei UInt16 zugegriffen wird, eins für das Modul (minus 1), das andere für die Datei in diesem Modul. Welche ALF gemeint ist, ergibt sich eigentlich immer aus dem Kontext. Modul und Datei steht meistens zusammen in einem Register, also zB. als 000A0002 was die 3. Datei im 10. Modul repräsentiert.

Die Reihenfolge der Module ergibt sich aus der Reihenfolge in der ensprechenden .MOD Datei zum .ALF Archiv.
Diese Reihenfolge muss nicht identisch sein mit der Reihenfolge der Module in der .ALF! Bei der Riva.ALF ist es dies beispielsweise nicht. Man packt die Module also, wie man sie in der .ALF vorgefunden hat. Das Spiel greift dann auf ein Modul i so zu, dass es den i. Namen in der .MOD nimmt, und dann das Modul in der .ALF sucht, dass diesen Namen trägt. Aus Performancegründen steht diese Permutation wahrscheinlich in einem Array und wird nur ein einziges Mal bestimmt.

Auf welche Datei zugegriffen wird, kann man anhand der DSA3::entries des NLTPackers ablesen (https://github.com/Henne/BrightEyes/blob...3.cpp#L338), wenn man für "Dummy-Einträge" ebenfalls einen leeren Eintrag vornimmt. Die Dummies stehen gewissermaßen für gelöschte Dateien.

Beim Entpacken muss man sich folglich den Index der Dateien und Module merken, wobei manche Indices nicht belegt sind, und dann in der selben Reihenfolge wieder packen.

Eigentlich macht Hendrik da alles richtig, aber irgendwie ist die -c Option (Neupacken) von NLTPack noch etwas verbuggt, da synchronize() die Dateien der .FN nicht mit denen in der Ordnerstruktur matcht (ist vielleicht nur ein falscher Path-Delimiter oder so). Davon, und dem Kopierschutz (s.u.), abgesehen verstehe ich nicht wirklich, wieso das Packen damit noch nie geklappt hat.

Naja, mit meiner gekaperten C#-Version des Packers kommt so dann ein funktionierendes RIVA.ALF Archiv bei raus, was ich durch Modifizieren von Soundfiles verifizieren konnte.

Es gibt nur ein Problem bei den meisten Archiven: Nur auf RIVA.ALF, RIVAHELP.ALF, RIVAHINT.ALF wird über die Festplatte zugegriffen, der Rest liegt auf der CD, und ist somit nicht direkt modifizierbar. Bei Entpacken der .ISO und Neupacken mit geänderter ALF beschwert sich der Kopierschutz von Riva. Wie dieser funktioniert kann ich noch nicht genau sagen. Falls dieser mit Hashwerten der Dateien arbeitet, könnte es so gut wie unmöglich sein, jene Archive zu modifizieren, ohne den Kopierschutz der .EXE durch einen Patch zu umgehen. Und letzteres hört sich leider ziemlich I**egal an.. Hoffentlich sind es aber nur Metadaten der CD, die beim Neupacken verloren gehen, nur kenne ich mich damit leider nicht wirklich aus.

Vielleicht lösen wir in Zukunft noch dieses Problem, und wären dann in der Lage, Riva vollständig zu modden.

[Rabenaas]

Hoffentlich sind es aber nur Metadaten der CD, die beim Neupacken verloren gehen, nur kenne ich mich damit leider nicht wirklich aus.

Ich meine mich dunkel zu erinnern, dass ich ein ähnliches Problem schon mal für die "möglichst wenig Platz"-Experimente gelöst habe. Mal ganz schlicht: Hat das Image den richtigen CD-Titel?

[cmfrydos]

Mhh, was waren das für Experimente?

Aber Platz ist denke ich das richtige Stichwort. Wenn ich die .iso neu packe ist sie um einiges kleiner,
außerdem werden die ersten X MB genullt, wo vorher noch vereinzelt Daten standen.
Die .iso von GOG ist auch nicht nach Standard, kann aber von DosBox und manchen Mountern problemlos gelesen werden. Leider ist es auch nicht nur Kopierschutz. Mounte ich 2 mal die Riva, je alt und neu, und wechsele Ingame, stürzt das Spiel beim Neuladen ab - versucht 1.6GB an Ram zu allockieren, wieso auch immer..
Bin etwas planlos, gibt 1000 iso writer, mit einem wirds wohl klappen. Am sichersten wäre es wohl selbst einen zu schreiben, und nebenbei prüfen (und mitnehmen), was es so an Auffälligkeiten gibt. Heißt aber auch FAT zu implementieren.. Alternativ könnte man die DosBox modifizieren, dass sie die Dateien on-the-fly austauscht

Edit: Ja, Titel ist korrekt

[Alrik Alrikson]

[...]
Eine Frage habe ich noch. Habt ihr hier andere aktuelle Versionen als die von GoG, zB. Heldenedition, oder die von Steam, und könnt mal schauen,
ob die Musik dort auch irgendwo als Musikdateien rumfliegt, und wenn ja, wo? Bei GoG liegen die Stücke z.B. in /MUSIC/ als .ogg's,
was sich heutzutage deutlich leichter abspielen lässt als die Tracks auf einer CD-ROM.
[...]

Ich habe die CD-Version von TopWare, da werden gar keine Musikdateien installiert, sondern diese von CD abgespielt.

[cmfrydos]

[...]
Eine Frage habe ich noch. Habt ihr hier andere aktuelle Versionen als die von GoG, zB. Heldenedition, oder die von Steam, und könnt mal schauen,
ob die Musik dort auch irgendwo als Musikdateien rumfliegt, und wenn ja, wo? Bei GoG liegen die Stücke z.B. in /MUSIC/ als .ogg's,
was sich heutzutage deutlich leichter abspielen lässt als die Tracks auf einer CD-ROM.
[...]

Ich habe die CD-Version von TopWare, da werden gar keine Musikdateien installiert, sondern diese von CD abgespielt.

Wow, dass ist die Erstausgabe von 1996/1997, oder?
Dh. da mustest du vermutlich noch selbst DosBox mit aufsetzten. Also prinzipiell müsste das gehen, dass ich da die Musiktracks einlese, muss aber aufpassen, dass das nicht zu stark mit der DosBox um die CD konkurriert. Werde es mal mit einer normalen AudioCD testen..

[Alrik Alrikson]

[...]
Eine Frage habe ich noch. Habt ihr hier andere aktuelle Versionen als die von GoG, zB. Heldenedition, oder die von Steam, und könnt mal schauen,
ob die Musik dort auch irgendwo als Musikdateien rumfliegt, und wenn ja, wo? Bei GoG liegen die Stücke z.B. in /MUSIC/ als .ogg's,
was sich heutzutage deutlich leichter abspielen lässt als die Tracks auf einer CD-ROM.
[...]

Ich habe die CD-Version von TopWare, da werden gar keine Musikdateien installiert, sondern diese von CD abgespielt.

Wow, dass ist die Erstausgabe von 1996/1997, oder?
Dh. da mustest du vermutlich noch selbst DosBox mit aufsetzten. Also prinzipiell müsste das gehen, dass ich da die Musiktracks einlese, muss aber aufpassen, dass das nicht zu stark mit der DosBox um die CD konkurriert. Werde es mal mit einer normalen AudioCD testen..

Ja genau, 1996 habe ich die CD geschenkt bekommen. Damals lief das noch nativ unter DOS und heute binde ich ein von der CD gezogenes Image ein und starte dieses dann über D-Fend Reloaded.

[Rabenaas]

Mhh, was waren das für Experimente?

Die Experimente hier:
https://www.crystals-dsa-foren.de/showth...p?tid=1419

Ich würde die Sache ziemlich einfach angehen. Damals hatte noch niemand einen CD-Brenner. Ein Spiel entsprechender Größe auf eine CD-ROM zu brennen, war eigentlich schon genug Kopierschutz. Mountest Du das Image nach D? Und mountest Du nur das ISO, oder CUE?

EDIT: Ah, wusste ich es doch, dass da etwas war.    Guck mal hier.

EDIT2: Und hier.

[cmfrydos]

Ah, sehr cool... Das was du unter "Cuesheet" unter 2 genannt hast, ist in meiner GoG Installation eine .ins, dache es wäre ein eigenes DosBox Format. Aber kann ich das dann einfach .cue nennen und damit die iso mounten? Dachte .cue geht nur mit .bin, bin deshalb etwas unsicher. Aber wenn ich wirklich so die Riva .iso (bzw. nennt sich ja .gog) mit Musik gemounted bekomme, stehen dich Chancen wohl sehr gut, dass das mit den angepassten .ALFs klappen könnte, danke für den Tipp! Schaue es mir mir morgen gleich an.

Edit: jetzt bin ich schon ganz durcheinander, will ja eine eigene .iso mounten.. Habe das glaube ich schon erfolglos über eine eigene .ins probiert, aber versuche mal morgen statt einer .iso eine .bin zu erzeugen..

[Rabenaas]

Hey, also "ins" sagt mir nix. Über eine CUE kannst Du eine BIN mounten. BINs sind eigentlich Bit für Bit Dumps einer CD. Die CUE ist nur dazu da, dem Programm zu sagen, wo welcher Track beginnt. Du kannst alternativ den Datentrack einer CD als ISO und die Musiktracks als WAV, MP3 bzw. OGG speichern und über das CUE zu einer "virtuellen" CD zusammenfassen.

[Luigi]

Ich glaube das ist bei GOG durchaus üblich:

Z.B. bei "Dungeon Keeper Gold"

GAME.INS-Datei ist die CUE-Datei
gog.game-Datei ist das ISO-IMAGE bzw. der erste Track bzw. Datentrack der "BIN-Datei"
keeper02.ogg bis zur keeper07.ogg sind die Musik-Tracks der "BIN-Datei"

Aber die Schwarze-Auge-Trilogie habe ich nicht von GOG.

So sieht die INS-Datei von Dungeon Keeper Gold von Gog aus.

FILE "game.gog" BINARY
  TRACK 01 MODE2/2352
      INDEX 01 00:00:00
FILE "keeper02.ogg" MP3
  TRACK 02 AUDIO
      INDEX 01 00:00:00
FILE "keeper03.ogg" MP3
  TRACK 03 AUDIO
      INDEX 01 00:00:00
FILE "keeper04.ogg" MP3
  TRACK 04 AUDIO
      INDEX 01 00:00:00
FILE "keeper05.ogg" MP3
  TRACK 05 AUDIO
      INDEX 01 00:00:00
FILE "keeper06.ogg" MP3
  TRACK 06 AUDIO
      INDEX 01 00:00:00
FILE "keeper07.ogg" MP3
  TRACK 07 AUDIO
      INDEX 01 00:00:00

PS:
oder auch Descent2-GOG
hier die "DESCENT_II-inst"-Datei, hier eine normale BIN-Datei mit Daten- und Musik-Tracks.

FILE "DESCENT_II.gog" BINARY
TRACK 01 MODE1/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 01 14:18:48
TRACK 03 AUDIO
INDEX 01 15:04:48
TRACK 04 AUDIO
INDEX 01 20:05:48
TRACK 05 AUDIO
INDEX 01 23:47:48
TRACK 06 AUDIO
INDEX 01 27:22:48
TRACK 07 AUDIO
INDEX 01 29:42:48
TRACK 08 AUDIO
INDEX 01 34:09:48
TRACK 09 AUDIO
INDEX 01 37:50:48

[cmfrydos]

Vielen lieben Dank für eure Hilfe!

Wie der Programmierer der CUE-Unterstützung von dosbox mitgeteilt hat, gibt es auch die Möglichkeit, Riva ohne Patch mit Musik im OGG-Format ans Laufen zu kriegen. Der entscheidende Punkt ist, dass jedesmal der Beginn für Audiotracks den Zähler auf Null setzen muss (INDEX 01 00:00:00). Ich bin mir zwar unsicher, ob das logisch ist, aber es funktioniert.

Ich poste hier mal das entsprechende cuesheet

Code:

FILE "dsa3.iso" BINARY
  TRACK 01 MODE1/2048
...

Der richtige Mode war entscheidend. Ich hatte zuvor lediglich bei FILE die Datei angepasst, aber nur mit MODE1/2048 lädt es jetzt auch selbst erstellte .iso's!   Das Riva .gog Image wurde wie in Dungeons Keeper und Descent2 mit MODE1/2352 geladen, vermutlich ist 2352 für ein .bin oder ein .bin ähnliches Format, da dort in Descent2 ja auch die Audiodaten liegen.

Ich werde noch berichten, ob es mir damit dann auch gelingt, zB. Videos oder Texturen in den anderen .ALF's zu verändern.

EDIT: Die Zahl nach dem Mode steht für die Sektorengröße, wobei 2352 für RAW Daten ist (Daten + ECC/EDC Fehlerkorrekturdaten) und 2048 für 'Cooked' Daten, bei denen ECC/EDC regeneriert wird.
(https://github.com/libyal/libodraw/blob/...rack-types)
(https://hydrogenaud.io/index.php/topic,42415.0.html)

[cmfrydos]

Kurzes Update: Ich konnte mittlerweile herausfinden, wo die Texte gezeichnet werden. Der Suchstring 0x535156575583EC0489042481FA befindet sich in V1.12 bei 0x214490. Bei 0x214BAC werden dann die einzelnen Buchstaben gezeichnet. Damit kann ich jetzt Texte abfangen, wie zum Beispiel diesen für die Heldenübersicht:
"LE~\xf047\xf0/47@AE~\xf00\xf0/0@@MR1@RS4@@Ausdauer65@Last710 U.@BP~~8".

Farbe(n) und Position stehen praktischerweise mit dabei. Was die einzelnen Sonderzeichen bedeuten (manche sind mit \x00 - \xff dargestellt), lässt sich nach ein paar Beispielen leicht erschließen. Allerdings funktionieren Tabs beim Nachzeichnen noch nicht zu 100%. Dafür müsste ich noch herausfinden, wie breit jedes Zeichen in der Originalfont ist. Außerdem werden manchmal Texte auf "Zwischentexturen" gezeichnet, d.h., sie werden nicht direkt auf den Monitor gezeichnet, sondern quasi zwischengespeichert.

Habt ihr vielleicht Ideen für schöne, zu Riva passende .ttf Fonts? Was haltet ihr von "Bitter"? Hier mal ein Vergleich damit:


   

Ich bin gerade noch dabei, das Zeichnen von Grafiken abzufangen und habe dabei schon 0x30C8D1 gefunden, wo man klar X.Y-Bildschirm-Positionen für das zu zeichnende Bild erkennen kann. Es bleibt noch zu entschlüsseln, aus welchem Speicher wohin (manchmal auch in Zwischentexturen) geschrieben wird und ob es gegebenenfalls auch noch Source-Koordinaten gibt. Es bleibt auch spannend zu sehen, ob dort die Grafiken bereits unkomprimiert im Speicher stehen. Das Spiel hat ja ein halbes Dutzend verschiedener Formate..

[aeyol]

Ach, das ist schon schwierig mit dem Font. Der originale Pixelfont hatte ja abgesehen vom i und l wohl gar keine Serifen, insofern kann man da eigentlich nur willkürlich entscheiden, ob man nun einen Serifenfont für geeigneter hält, oder nicht. Ich finde Fonts ohne Serifen tendenziell am Bildschirm angenehmer zu lesen.

Definitiv würde ich einen Font wählen, der mehrere Schnitte unterstützt, und "Gottheit" und "Rondra" sowie den Charakternamen etwas fetter machen. Aber eventuell kannst du das gar nicht machen?

[cmfrydos]

Definitiv, eine serifenlose Schriftart wäre besser geeignet. Was mir auffällt, ist dass die originale Schriftart etwas "fetter" und breiter ist, was bedeutet, dass die Texte horizontal mehr Raum einnehmen.

Ich finde, wir sollten eine Hauptschriftart suchen, die das Ambiente von DSA/Schatten über Riva einfängt, dabei aber dem Original treu bleibt. Also vielleicht keine Pixelart. Das ist natürlich objektiv schwer zu beurteilen, aber die Schriftart sollte dem Original nahe genug sein, um erstmal alle Texte des Spiels damit darstellen zu können.

Darüber hinaus wäre es spannend, bestimmte Hauptdialoge oder Seiten, wie die Heldenübersicht, manuell anzupassen. Technisch ist es kein Problem, die bestehenden Texte abzufangen, zu erkennen, zu modifizieren und dabei Steuerzeichen für den Schriftschnitt einzufügen, ähnlich wie es schon bei der Schriftfarbe im Original der Fall ist.

Die einzige echte Hürde: Die Schriftart sollte frei verwendbar und als TrueTypeFont (.ttf) verfügbar sein.

[aeyol]

Hier wäre ein Font mit etwas zurückhaltenderen Serifen, als Bitter sie hat: https://fonts.google.com/noto/specimen/N...Noto+Serif

Da könntest du es mit dem Schriftschnitt Medium oder Semibold probieren.

Legal und frei verwendbare Schriften zu finden, ist heutzutage eigentlich keine echte Hürde mehr.

"These fonts are licensed under the Open Font License. You can use them in your products & projects – print or digital, commercial or otherwise."

[cmfrydos]

Super, Noto Serif sieht vielversprechend aus. Ich werde sie heute Abend mal ingame testen und berichte dann, wie sie sich macht.

[aeyol]

Ein Font, der zu Riva evtl auch gepasst hätte, wäre Benguiat ITC gewesen. Das wiederum ist aber leider ein kommerzieller font, und es gibt da auch meines Wissens keine wirklich frei nutzbaren Alternativen.

Bin aber gespannt, wie Noto Serif sich im Kontext so macht.

[cmfrydos]

Habe Fortschritte gemacht: Die GUI-Bilder klappen jetzt schon größtenteils, abgesehen von u.A. einem kleinen Fehler am Mauszeiger. Aber nun zurück zu den Schriften: Ich habe mal mit Noto Serif Medium begonnen:

   
Direkt fällt auf, dass mein aktueller Ansatz Probleme mit verschiedenen Seitenverhältnissen hat. Bei breiteren Bildern füllt der Text nicht die gesamte Fläche. Deshalb werde ich für den Vergleich vorerst bei 4:3 bleiben:

   
Als nächstes die Schrift in Semi-Bold:

   
Interessanterweise sind die Leerzeichen im Original deutlich breiter, also habe ich beschlossen, sie zu verdoppeln, und außerdem die Schriftgröße leicht zu erhöhen:

   
Nachdem ich zu Medium zurückgewechselt habe, sieht es schon ziemlich nah am Original aus:

   


Es wirkt, als ob etwas zwischen Medium und Semi-Bold optimal wäre, tendenziell näher an Medium. Theoretisch kann die Schrift das auch, man muss nur herausfinden, wie sie entsprechend generiert werden kann. Ob die breiteren Leerzeichen wirklich zur Lesbarkeit beitragen, bin ich mir noch nicht sicher...

Ich denke, auch für die Textboxen könnte es irgendwann sinnvoll sein, diese "früher abzugreifen", also einen eigenen Textumbruch und passendere Boxen zu erstellen, die nicht den ganzen Bildschirm füllen. Was meint ihr dazu?

[aeyol]

Ich fürchte, du bräuchtest einen Monospace-Font, um den vorhandenen Font originalgetreuer abzubilden. Monospace-Fonts wirken aber üblicherweise moderner/technischer, sofern es nicht grad Retro-Pixel-Fonts sind.

Vielleicht noch der hier (nur ein Schriftschnitt verfügbar): https://fonts.google.com/specimen/PT+Mono

Also ich finde es mit Noto Serif schon gut, wäre aber einfach neugierig, wie es hiermit wirken würde.

So richtig angenehm zu lesen finde ich den erhöhten Zeichenabstand in den letzten Beispielen nicht. Da sind wir mittlerweile einfach besseres gewohnt. Also ja, ein eigener Textumbruch und passende Boxen wären definitiv gut.
Auch wenn alles natürlich eine ästhetische Abweichung vom Original mit sich bringen wird. Aber mit etwas Geschick kann man, auch wenn es anders aussieht, dennoch die Stimmung einfangen.