Hauptmenü
Sie sind hier
TeX/KOMA-Script ähnliche Typographie für Computerspiel
Hallo ihr Lieben,
vorab möchte ich mich entschuldigen, dass ich hier gleich mit einer Frage anfange, die nicht wirklich etwas mit KOMA-Script zu tun hat. Allerdings bin ich seit Jahren LaTeX-Nutzer und möchte meinen Schatten überwinden und ein kleines Computerspiel in der Programmiersprache C++ entwickeln. Nun ist es so, dass ich durch die langjährige Nutzung von LaTeX und KOMA-Script relativ ordentlich aussehende Dokumente und Texte gewöhnt bin.
Ich frage mich daher, welche Möglichkeit sich mir bietet, in besagtem Computerspiel zumindest dem Textsatz mehr Augenmerk zu schenken, als einfach eine fertige Programmierbibliothek zu nutzen. Im Folgenden werde ich kurz auf die für mein Projekt genutzten Programme und Programmier-Bibliotheken zu sprechen kommen und dann meine zwei Ansatzideen zu dem Projekt schildern.
Zu den verwendeten libraries
SFML ist ein aktiv weiterentwickeltes Multimedia-Framework welches Anbindingungen an einige Programmiersprachen bietet und auf mehreren Betriebssystemen lauffähig ist. Für die Grafikdarstellung wird noch OpenGL (eventuell in Zukunft auch Vulkan) verwendet. Zum Laden von Schrift wird auf das FreeType Packet gesetzt. Allerdings werden von SFML nur wenig features wirklich genutzt/weiterverwendet. Siehe diese oder jene Header-Datei.
Meine Überlegung zur Umsetzung
Ich überlege nun, ob ich eine eigene Text-Klasse schreiben soll, die die 'core conventions' von FreeType nutzt und typografisch angepasst wird, indem ich versuche in ausgewählten TeX/LaTeX Packt-Quellcodes (von Knuth, zum Beispiel von 'TeX – A sophisticated typesetting engine' und komascript) Alogrithmen zu finden, die mir helfen, die typografische Darstellung der Zeichen, Wörter und Linien direkt in meinem Spiel zu arrangieren.
Oder ist es einfacher jeden Text, der im Spiel vorkommen soll direkt in TeX oder LaTeX code schreiben zu lassen, jede Textdatei von pdfLaTeX oder xelatex verarbeiten zu lassen und dann eine Möglichkeit zu finden, die DVI oder PDF Datei bei Bedarf zu laden und mit OpenGL zu rendern.
Das Problem bei Zweiterem ist, dass der Vorgang lange dauern wird und ich gerne eine Lösung hätte, die das Layout automatisch dynamisch per Spiellaufzeit anpasst. Etwa wenn die Auflösung geändert wird. Außerdem wüsste ich nicht, wie ich problemlos eine PDF-Datei laden und an OpenGL weiterleiten kann.
Jeder der mir dabei ein bisschen Unterstützung in jedweder Form liefern möchte ist herzlich willkommen, sich zu melden.
Mit freundlichsten Grüßen an alle Typografiefreunde
Oparilames
Aktuelle KOMA-Script Release
Die aktuelle KOMA-Script-Release finden sich primär im Dateien-Bereich des Projekts KOMA-Script auf SourceForge.
Schnelle Bugfixes und Prereleases finden sich im KOMA-Script-Repository.
Näheres zur aktuellen und früheren Releases ist dem Beitrag »Welches ist die aktuelle KOMA-Script-Release und wo finde ich sie?« zu entnehmen.
Beispiele aus der 7. Auflage des KOMA-Script-Buchs
Hingucker
Sponsoren
In der Reihenfolge der Spendeneingänge:
2024
Paul Kloß, Manuel Kuehner, Julian u. a.
2023
Paul Kloß, Manuel Kuehner, Martin Bierbaum, Ulrich Groh, Elke Schubert u. a.
Näheres zu Kosten und Betrieb ist in einem Blog-Beitrag zu finden. Natürlich sind auch Spenden ohne Namensnennung möglich.
Newsfeeds
Interessantes Unterfangen
Um wieviel Text und welche Art Text geht es denn? Für mal eben drei Zeilen hier und einen Kasten mit einem »Blubb« dort, lohnt sich so etwas ja kaum. Wenn dagegen eine komplette Storry erzählt werden soll, dann verstehe ich das Anliegen schon eher. Dann stellt sich auch die Frage, ob der Text dynamisch entsprechend irgendwelcher Gegebenheiten (beispielsweise Auswahl eines anderen Fonts) neu umbrochen werden soll oder nur in unterschiedlicher Auflösung neu gerendert ohne ihn jedoch neu zu umbrechen. Für ersteres bräuchte man schon den Umbruchalgorithmus von TeX. Für zweiteres könnte müsste man letztlich nur einen DVI-Treiber schreiben. Das ist gar nicht so schwer. Ich habe noch zu Atari-Zeiten selbst mehr als einen DVI-Treiber geschrieben. Heutzutage würde ich allerdings vom erweiterten DVI-Format von XeTeX ausgehen, da dieses auch Unicode-Zeichen verarbeiten kann. Falls die Lib mit SVG-Grafiken umgehen kann, könnte man natürlich im zweiten Fall auch die fertig umbrochenen Texte in SVG umwandeln. Dazu der Hinweis, dass dvisvgm auch PS und PDF verarbeiten kann.
Hallo Markus,
Hallo Markus,
dir sei gedankt, dass du höchstselbst antwortest. Nun es geht hauptsächlich um Dialogtexte und ein integriertes Nachschlagewerk mit Informationen zur Spielwelt in einem Rollenspiel.
Die Texte sollen auch dynanisch neu umgebrochen werden können, ja. Aber das kann ja im Nachhinein noch hinzugefügt werden, wenn die eigentliche Darstellung klappt.
SVG-Datein habe ich selbst noch nie genutzt. Was Wikipedia darüber schreibt liest sich jedoch, als wäre da jede Menge Balast mit dabei, der bei DVI und PS geringer gehalten ist?
Ja, aber
Für DVI musst Du Dir einen eigenen Treiber schreiben. Das könnte man beispielsweise auf Basis von dvitype (ohne Rendern) oder dvipng (Rendern inklusive) sicher mit vertretbarem Aufwand tun. Aber, wenn Du dann dynamischen Umbruch brauchst, musst Du erst einmal DVI erzeugen.
Ich würde mir überlegen, ob ich DVI wirklich als Zwischenformat brauche und will. Eigentlich brauchst Du ja nur den Parshaper von TeX, also den Absatzumbruch. Makros interpretieren oder dergleichen musst Du nicht. Der Parshaper bekommt letztlich den »Text« eines Absatzes und bricht den in eine vertikale Liste von Zeilen um, wobei er auch gleich die Wortabstände produziert (in TeX gibt es ja keine echten Leerzeichen, sondern nur Abstände). Wobei man selbst bei den Wortabständen ggf. Vereinfachungen treffen könnte. Wie das funktioniert, ist recht gut dokumentiert.
Für Unicode ist übrigens genau das als eine von zwei Möglichkeiten laut Wikipedia dokumentiert. Der Algorithmus von TeX ist auch im Gnu-Utility fmt implementiert. Eventuell wäre also eine interne Version davon ein Ansatz für das Problem. Ansonsten ist der Algorithmus, nach dem TeX arbeitet, in der Literatur recht gut dokumentiert.
Ich würde mir also schon gleich am Anfang überlegen, was alles tatsächlich benötigt wird und ob es dann noch sinnvoll ist, ein Zwischenformat wie DVI zu erzeugen und zu interpretieren.
Danke!
Hallo Markus,
ich habe zur Zeit unerwartet viel um die Ohren, habe mir deine Antwort aber wahrgenommen und gehe den Möglichkeiten grade selbst auf den Grund.
Deine Argumentation gegen DVI hat mich überzeugt, ich denke ich werde versuchen die Text innerhalb meiner Software formatieren und kein tool schreiben, welches Texte für das Spiel in LaTeX Dokumente umwandelt, diese mit (pdf)latex oder (pdf)xelatex in DVI/PDF Datein umzuwandeln und eine Renderroutine im Spiel implementieren, die diese Datein dann wieder ausgibt, wie anfangs angedacht.
fmt werde ich mir angucken, mit der Programiersprache bin ich eher vertraut als mit plain TeX/LaTeX, ergo werde ich nachdem ich dessen Code mal angeschaut habe, genauer sagen können, ob mir das als Ausgangsbasis für Umbrüche reicht (sieht mir so aus). Die Feinarbeiten werde ich selbst versuchen zu implementieren.
Ich dachte halt nur, dass in TeX mehr als nur ein Zeilenumbruch geschieht. (Grob beim Überfliegen sieht es immernoch danach aus) Ich dachte (und denke eigentlich immernoch), dass hier der Grauwert innerhalb einer Zeile berücksichtigt wird, Kerning angewand wird und so weiter. Hinzu kommt, dass ich zu typearea keine Dokumentation gefunden habe (Abseits vom Quellcode oder der normalen KOMA script Dokumentation), was hilfreich wäre.
Auch habe ich noch nie versucht TeX oder LaTeX Pakete zu entwerfen, aber so wie es aussieht, werde ich mich da durch arbeiten müssen um den Paketen auf den Schlich zu kommen, die für mich von Interesse sind. Zusätzlich werde ich wohl mal wieder einen Blick in die gute alte Lesetypografie werfen, die ich mir zugelegt habe, als ich anfing mich für Typografie zu interessieren.
Es eilt ja nicht und ich würde mich wieder melden, wenn ich erste »Erfolge« erzielt oder eine Frage habe, die ich durch eigene Recherche nicht habe beantworten können.
Falls du (oder sonst jemand) Interesse an einem Prototypen hat, könnte ich ja eine Tech Demo mit Schwerpunkt Text veröffentlichen, sobald ich glaube etwas Vorzeigbares geschafft zu haben.
Lass mich aber eins sagen: »Danke für dein bisheriges Interesse und den guten Rat!«
Falls du noch einen Buch- oder Artikeltipp hast, würde ich das sehr begrüßen.
Sei es zu TeX oder zu Webtypografie, da ich mich nur in meiner Freizeit etwas damit beschäftige und weder ein Webdesigner noch Schrifthersteller noch Mediendesigner oder etwas in der Richtung bin.