spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »dot«

Zitat von »BlueCobold«

Und mal davon abgesehen sind am Ende ohnehin alles nur Pixel, da ist auch ein Systemfont niemals schärfer als ein Bitmapfont.

http://en.wikipedia.org/wiki/ClearType

Auch ClearType ist auf einem Bildschirm nur Pixel.

Du wirst aber keine Bitmapfont vorberechnen können, die qualitativ an ClearType rankommt (ClearType ermöglicht z.B. subpixelgenaue Platzierung von Glyphen und so). Aber ja, das hat vor allem bei kleinen Schriftgrößen seine Vorteile...

Ich nehme an, BlueCobold hat da mit "Systemfont" auch "Vektorfont" gemeint.
Und Vektorfonts können deshalb in der Praxis schon schärfer sein als Bitmapfonts, weil ein Bildschirmpixel eben mehrere Subpixel als Fontpixel enthalten kann.
Normalerweise verwendet man natürlich keine "Systemfonts" sondern eigene Vektorfonts.

Im Prinzip sehe ich das so wie LetsGo.
Auf einen Titelbildschirm kann es von Vorteil sein, wenn die Buchstaben alle individuell gestaltet sind.
Bei den Texten in Menüs oder Fließtext finde ich Skalierbarkeit und maximale Leserlichkeit und Schärfe wesentlich wichtiger. Außerdem sind viele Effekte trotzdem möglich.

Zitat von »Spiele Programmierer«

Und Vektorfonts können deshalb in der Praxis schon schärfer sein als Bitmapfonts, weil ein Bildschirmpixel eben mehrere Subpixel als Fontpixel enthalten kann.

Das ändert nichts an der Tatsache, dass final auf einem Bildschirm ein Pixel eben nur eine einzelne Farbe haben kann. Was mit Vektor basierten Fonts funktioniert, ist diese um gebrochene Pixel-Positionen zu verschieben. Das geht bei Bitmap Fonts natürlich nicht (zumindest nicht ohne Unschärfe durch Interpolation zu erzeugen). Das ist meist aber auch gar nicht notwendig in einem Spiel.

Zitat von »dot«

Du wirst aber keine Bitmapfont vorberechnen können, die qualitativ an ClearType rankomm

Doch. Solange man ClearType Fonts als Pixel auf einem Bildschirm darstellen kann, solange kann man auch genau diese Pixel-Konstellationen in einem Bitmap Font verwenden. Offensichtlich.

Zitat von »BlueCobold«

Zitat von »dot«

Du wirst aber keine Bitmapfont vorberechnen können, die qualitativ an ClearType rankomm

Doch. Solange man ClearType Fonts als Pixel auf einem Bildschirm darstellen kann, solange kann man auch genau diese Pixel-Konstellationen in einem Bitmap Font verwenden. Offensichtlich.

Du schlägst also vor, alle möglichen Subpixelkonstellationen jeder Glyphe vorzuberechnen!? Das wären (wenn man vertikales Antialiasing mal außer acht lässt) für 8 Bit per Pixel auf einem typischen LCD Display mit 1×3 vertical stripe pixel geometry überschlagsmäßig dann wohl mehr als §4 \cdot 255 \cdot 254 = 259080§ Möglichkeiten pro Glyphe pro Font. Vor allem im Zusammenhang mit Unicode würde mich sehr interessieren, wie genau du dir das vorstellst...

Bitmapfonts haben ihre Vorteile; sie sind simpel, einfach zu erstellen und in vielen Fällen bis zu einem gewissen Grad ausreichend etc. Aber es hat schon seine Gründe, wieso man, vor allem in ernsthafteren Anwendungen, mit Vektorfonts arbeitet...

Zitat von »BlueCobold«

Zitat von »Spiele Programmierer«

Und Vektorfonts können deshalb in der Praxis schon schärfer sein als Bitmapfonts, weil ein Bildschirmpixel eben mehrere Subpixel als Fontpixel enthalten kann.

Das ändert nichts an der Tatsache, dass final auf einem Bildschirm ein Pixel eben nur eine einzelne Farbe haben kann. Was mit Vektor basierten Fonts funktioniert, ist diese um gebrochene Pixel-Positionen zu verschieben. Das geht bei Bitmap Fonts natürlich nicht (zumindest nicht ohne Unschärfe durch Interpolation zu erzeugen). Das ist meist aber auch gar nicht notwendig in einem Spiel.

Zitat von »dot«

Du wirst aber keine Bitmapfont vorberechnen können, die qualitativ an ClearType rankomm

Doch. Solange man ClearType Fonts als Pixel auf einem Bildschirm darstellen kann, solange kann man auch genau diese Pixel-Konstellationen in einem Bitmap Font verwenden. Offensichtlich.

Das Problem bei der Speicherung als Bitmap ist, dass beim Rendern, sollten die Subpixel angesprochen werden, nicht nur die Fordergrundfarbe (die Schriftfarbe), sondern auch die Hintergrundfarbe relevant ist.
Wenn Kanten geglättet werden wird (allgemein gesprochen) ein Pixel zwischen 2 Farben aufgeteilt (es wird interpoliert). Hat man einen weißen Hintergrund und eine schwarze Schrift ist so jeder einzelne Zwischenschritt dieses Übergangs ein Grauton. Das heißt, dass jeder Farbkanal gleichmäßig in seinem Wert angepasst wird, wodurch alle Subpixel gleichzeitig Teil des Übergangs sind. Wenn man weiß, in welcher Reihenfolge für einen Pixel die Subpixel vorliegen, kann man beim Rendern darauf eingehen und den Übergang nicht für alle Farbkanäle berechnen, sondern erst für den ersten Subpixel, wenn dieser gänzlich der anderen Farbe gehört (ihr Anteil am Gesamtpixel also mindest so hoch ist, wie der Anteil des Subpixel am Pixel) den nächsten usw.
Das ganze (zumindest ansatzweise) visualisiert:

Von rechts nach links sieht man einen Übergang von einer Farbe (bspw. weiß) zu einer anderen (bspw. schwarz). Zu beachten dabei ist, wie dank oberem Text evtl. erkennbar, dass bei einem Berücksichtigen der Subpixel immer 2 der Subpixel genau den Farbwert einer der beiden Farben entspricht, wodurch die Größe des Übergangsbereichs (der Teil des Pixels, der zwischen beiden Farben interpoliert wird) kleiner und somit das Ergebnis besser ist.

Wenn man schon zu einer Zeit mit grafiken zu tun hatte, als es noch keinen Alphakanal gab (oder mit dem RPG-Maker gearbeitet hat, ohne zu große Anpassungen vorzunehmen), dürfte noch wissen, dass es als Ersatz "colorkey"s gab, die den Farbwert bestimmten, der beim Zeichnen ignoriert werden sollte, damit dort der Hintergrund durchscheinen konnte. Dadurch hatte man aber die Einschränkung, dass keine Übergänge zwischen dem Inhalt eines Bilds und seinem Hintergrund möglich waren. hatte man in seinem Bild dennoch solche Übergänge bspw. von schwarz zu weiß (colorkey), wurden alle nicht-weißen (grauen) Pixel des Übergangs gezeichnet wurden, wodurch das Ganze auf einem anderen Hintergrund (bspw. blau) nicht gut aussah.
Mit Hilfe des Alpha-Kanals kann man mittlerweile bestimmen, wie deckend der Pixel dargestellt werden soll, damit der Hintergrund entsprechend teilweise/ganz/gar nicht sichtbar sein kann. Dies gibt es aber nur für ganze Pixel, nicht aber für Farbkanäle und erst recht nicht für Subpixel. Eine Schriftart unter Berücksichtigung der Subpixel zu rendern und dann als Bitmap-Font zu speichern ist also entsprechend unsinnig, da es nur auf dem richtigen Hintergrund keinen Unterschied macht.

Außerdem besitzt nicht jeder Bildschirm die gleiche Subpixel-Anordnung. Damit meine ich nicht nur, dass die Farbkanäle vertauscht sein könnten, sondern auch, dass es entsprechende Muster gibt, bei denen die Pixel nur aus 2 Farbkomponente (mit abwechselnder Zusammensetzung) aufgebaut sind, dass es andere Anordnungen geben könnte (vertikal statt horizontal aufgereiht) und dass es andere Subpixel-Formen gibt. (Beispiele findet man u. A. im englischen Wikipediaartikel)
Die Subpixel kann man beim Rendern also nur dann berücksichtigen, wenn man ihre Anordnung kennt. Diese kennt man grundsätzlich nur dann, wenn das Rendern auf dem Gerät durchgeführt wird.


Nachtrag:
@dot:
Genauso wie es Gründe hat, dass man in Spielen dennoch Bitmap-Fonts verwendet. Schriften auf Vektorbasis sehen zwar wesentlich hübscher aus und auch Skalierungen sind damit absolut kein Problem (was das Aussehen angeht), allerdings müssen die Texte (unter Umständen, bspw. bei jeglicher Art von Bewegung, Rotations oder Skalierung der Texte) gezeichnet werden, wo Bitmaps ein wenig performanter sein dürften.

Zitat von »Sacaldur«

@dot:
Genauso wie es Gründe hat, dass man in Spielen dennoch Bitmap-Fonts verwendet. Schriften auf Vektorbasis sehen zwar wesentlich hübscher aus und auch Skalierungen sind damit absolut kein Problem (was das Aussehen angeht), allerdings müssen die Texte (unter Umständen, bspw. bei jeglicher Art von Bewegung, Rotations oder Skalierung der Texte) gezeichnet werden, wo Bitmaps ein wenig performanter sein dürften.

Sagt ja niemand, dass man tatsächlich in jedem Frame jede einzelne Glyphe am Schirm als Vektorgrafik rendern muss, das wäre natürlich unglaublich ineffizient, vor allem bei kleinen Fonts. Man könnte aber z.B. ganze Lines an Text einmal in eine Texture rasterisieren und diese dann rendern (so macht es afaik z.B. Direct2D und vermutlich auch WPF). Oder einen Ansatz wie den von Spiele Programmierer verwenden...

Zitat von »dot«

Du schlägst also vor, alle möglichen Subpixelkonstellationen jeder Glyphe vorzuberechnen!?

Nein. Das wäre dumm und das weißt du selbst. Allein die Idee ist hirnrissig.
Man braucht genau eine Glyphe pro Character. Wieso auch mehr. Wie ich schon sagte sind Subpixel-Konstellationen nicht notwendig.

@Sacaldur:
Too long, didn't read. Sorry, aber deine Beiträge sind immer ganze Geschichten, dafür muss man echt zu viel Zeit haben. Vielleicht nächstes Mal *etwas* kürzer? Du musst nicht immer so stark abschweifen oder in's Detail gehen. Andererseits dürfte es dir wohl einfach fallen mal ein Buch zu schreiben

Zitat von »Sacaldur«

Eine Schriftart unter Berücksichtigung der Subpixel zu rendern und dann als Bitmap-Font zu speichern ist also entsprechend unsinnig, da es nur auf dem richtigen Hintergrund keinen Unterschied macht.

Das ist Quatsch. Denn genau dafür kann man den Alpha-Kanal verwenden. Wenn ein Subpixel auf das Pixel einen 70%igen Einfluss hat, dann hat es den. Unabhängig vom Hintergrund. Wenn dem nicht so wäre, musst man beim Rendern von ClearType ja immer den Untergrund mit angeben. Macht man aber nicht. Ist auch total unnötig.

Zitat von »BlueCobold«

Wie ich schon sagte sind Subpixel-Konstellationen nicht notwendig.

Wenn du Qualität äquivalent zu ClearType willst, dann schon und genau um diese Aussage ging es mir. Ich sage nicht, dass jeder Hobbycoder unbedingt Vektorfonts verwenden muss. Aber zu behaupten, dass man mit Bitmapfonts die selbe Qualität hinbekommt, ist leider falsch.

Zitat von »dot«

Wenn du Qualität äquivalent zu ClearType willst

Nein. Es gibt sicher marginale Abstriche, aber die sind irrelevant. Man muss sich halt bewusst sein, dass alle Glyphs desselben Chars identisch aussehen. Ich sehe daran aber kein Problem für die Praxis. Und das ist dann auch schon alles.
In der *reinen Theorie* ist natürlich ein Unterschied vorhanden. Ganz logisch. Da braucht man auch gar nicht drüber diskutieren. Es ging aber darum, ob es Sinn macht. Und ja, das macht Sinn. Sehr viel sogar.