Das sieht richtig gut aus. Wenn du das noch weiter verbessern kannst - Hut ab!

Wie machst du das Postprozessing? Die Umrahmung (Strikes) und den Schatten?
Ich hab auch ne Controll-Unit geschrieben. Allerdings in C++ mit SDL und dann portiert auf Java. Text war immer ein problem. Ich konnte den zwar lesen - aber toll aus sah der nie.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Freut mich, dass es gefällt. So war das ja auch ein bisschen geplannt.

Im Groben sieht es so aus, dass ich mir von SDL ein Zeichen rendern lasse und das Surface übergebe ich an eine Methode der PostProcessorKlassen. Diese können dann damit machen was sie wollen.

Der Rand ist einfacher als man sich das vielleicht vorstellt. Ich erweitere das Surface um jeweils ein Pixel und Clone dieses anschließend. Eines dient als LookupSurface und in das Andere erstelle ich den Rand. Dann erstelle ich mir eine Liste mit Punkten die ich in meine Berechnungen mit einfließen lassen möchte. Bei der Größe 1 sind dort genau 5 Pixel enthalten. (Oben/Unten/Links/Rechts und Mitte). Dann wende ich diese Liste auf jedes Pixel an. Beim Rand suche ich mir einfach den maximalen Alphawert aus. Simpel aber wie man sieht schauts ja wohl doch recht gut aus. Diesen Wert weise ich auf den Alphakanal zu und RGB wird mit der Farbe gefüllt die übergeben wurde. Aus diesen beiden Surfaces blende ich dann ein resultierendes Surface. Das ist mein Ergebnissurface und wird dann an den nächsten PostProcessor übergeben oder wandert in die Textur.

Beim Schatten ist das nicht großartig anders außer, dass ich eine größere Liste/Matrix habe die auf jedes Pixel angewendet wird. Und dann wird auch der Durchschnitt berechnet. Stink normaler Gausscher Weichzeichner.

Wenn man so will ist das auch ein bisschen vergleichbar mit den Layern wie sie in Gimp verwendet werden nur, dass nach jedem Effekt der Layer zusammengeführt wird.

Die ganzen internen Abläufe werde ich wohl noch mal ein bisschen überarbeiten müssen um unnötigen Erstellerreien und Umkopieraktionen einsparen zu können. Ich denke mal das wird das noch mal ein bisschen beschleunigen. Wobei der Gaussche Weichzeichner ist schon ganz schön häftig.

*mir fehlen gerade die Worte vor Begeisterung*

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Respekt! Dein Fonts kann man jetzt richtig für längere Texte verwenden. (OpenGL-Schreibprogramm ) Haste schon ne Rechtschreibprüfung drinnne.

Ne aber mal im ernst. Das is wirklich großes Tennis was du hier bietest. Die Leute von den DGL-Control Units werden da bestimmt schon große Augen machen.... So ne Textausgabe macht sich ja immer gut....

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Schön zu hören, dass es durchaus sinnvoll ist was man tut. Das steigert ungemein die Motivation.

Ob man längere Texte wirklich richtig verwenden kann weiß ich noch nicht. Habe schon länger keine Geschwindigkeit mehr gemessen. Aber ich bin zuversichtlich, dass es nicht zu langsam sein wird. Dafür verwende ich dort genügend Pointer (Schon fast zu viele). Was mir allerdings noch ein riesen Dorn im Auge ist sind die Abstände zwischen den Zeichen. Die finde ich noch ziemlich grausam, vor allem da ich das schon mit Fonts gesehen habe die nicht so ideal sind wie in den Beispielen. Aber auch da gibt es so die ein oder andere Stelle die nicht gut aussieht. Es ist ja aber noch nicht fertig.

Aber so gesehen. Ich mache das alles ja nicht ganz uneigennützig. Habe ja selber auch ein paar Komponenten die derzeit auf eine Textausgabe warten. Und so wirklich sinnvolle Alternativen gibt es leider auch keine. Und wo ich gerade schon mal dabei war konnte ich es auch gleich richtig machen. In Spielen sieht man solche Blocksätz bei größeren Texten ja auch recht häufig. Das sieht einfach viel besser aus als wie wenn man das Linksausgerichtet ausgibt.

@Flash: Ja ich mache Augen.
Die Schrift sieht traumhaft aus. Die Unicode-Unterstützung ist aber der Gipfelpunkt, würde ich sagen.

Hallo Lossy,
Deinem Beispielbild entnehme ich, dass die GDI nicht immer besser aussieht als SDL_ttf. Es scheint mir mal so, mal andersrum zu sein.

Und es sieht aus, als ob Du Kerning dabei hättest, oder?


Finde ich gut


Finde ich nicht schön von Dir, mich derart unverschämt abzuhängen. Ich werde mich bei Jonas beschweren.

EDIT: >* Frechdachsmodus aus *<

Hi Traude,

Den ersten Satz habe ich irgendwie nicht ganz verstanden. Bzw was hast du in dem Bild entdeckt?

SDL und GDI arbeiten natürlich anders. Deswegen kann das Ergebniss nicht gleich aussehen. Die GDI macht die Horizontalen Linien auch irgendwie breiter als SDL. Vor allem benutze ich für die GDI ClearType was aber nicht dargestellt wird sondern von mir stumpf runter gerechnet wird. Da GDI zwischen 6-14 (bis zu 22 manchmal) kein AntiAliasing unterstützt. Da muss ich aber auch noch was tun. Mit dem Unterschied meinte ich in erster Linie die Abstände zwischen den Buchstäben. Als Beispiel schaut dir mal in der 7. Zeile das p bei komplett und das w bei verwahrlosten an.


Kerning: Nö. Das ist da noch nicht eingebaut. Über SDL_ttf bekommt auch keine Kerninginformationen. Und mein Eigenes na ja. Das hängt noch irgendwo sonst wo rum. So richtige Fälle für Kerning gibt es dort aber auch nur einen einzigen. Und zwar das Ta bei Taxi. Alle anderen Kombinationen sind fürs Kerning ja nicht so relevant.



Ach Quatsch. So etwas würde ich doch nieee tun. Aber was hat eigentlich Jonas damit zu tun?

Ich habe aber auch einen entscheidenden Nachteil derzeit. Meine Texturen können Fragmentieren. Je nachdem wie viele Fonts erstellt und wieder freigegeben werden kann das durchaus echt hässliche Ausmaße annehmen. Dazu habe ich zwar auch noch eine Idee aber noch keine Ahnung wie ich das richtig anstellen soll.

präziser ausgedrückt: Ich dachte immer, dass die GDI-Schrift der SDL-Schrift überlegen ist, was das "schöne" Aussehen betrifft (Antialiasing...). Scheint aber doch nicht immer der Fall zu sein.

Jonas ist für mich eine moralische Instanz.


Wie wärs mit einem Brainstorming Thread? Hab gute Erfahrungen damit gemacht: die Leute lesen es gern und manchmal kommen echt brilliante Ideen.

GDI: Das Problem ist, dass die TTFs Bereiche definieren können und dort auch sagen können was gemacht wird. Für Arial sieht das so aus.
0-6 Smoothed
7-13 Hinted
14 + Hinted and Smoothed

Das bedeutet, dass Schriften zwischen 7-13 Punkten nicht geglättet werden. Das Hinting ist etwas was die Schrift ohne Kantenglättung durchaus wohlgeformter darstellt als das bei SDL der Fall wäre. Aber dafür ist es bei SDL so, dass die Schrift dauerhaft geglättet ist weswegen das nicht so wirklich auffällt. Warum das bei der Windows nicht so ist? Höchstwahrscheinlich sind das altlasten. Leistungsfähig sind die Rechner dazu alle mal.

Und da ist das alles nicht so hübsch finde benutze ich derzeit immer ClearType. Aber das wiederrum ist für die Darstellung auf TFTs optimiert. Weil der TFT das irgendwie hardwarebedingt besser kann. Wenn du mal mit einer Bildschirmlupe oder so schaust. In der Titelleiste siehst du, dass bei ClearType links und rechts die Ränder einmal nach Blau und ein mal in Richtung Magenta laufen. Das habe ich nur stumpf nach Grau gerechnet. Ich muss aber mal schauen, dass ich den normalen Glättungsmodus auch irgendwie sinnvoll mit einbaue. Dann sind die Kanten auch schärfer. Bzw wäre es auch möglich die Farben für ClearType direkt mit rauszureichen um echtes ClearType unterstützen zu können. Das würde den ein oder anderen auch freuen. Aber ich schweife gerade ab.

Brainstorming: Geht ja durchaus auch hier. Aber ich muss mal schauen. Derzeit ist mir das noch nicht so wichtig, weil das in erster Linie etwas internes ist und ich die Schnittstelle erst einmal richtig festzurren möchte. Das kann man später noch problemlos erweitern. Und man merkt dann nichts davon.

Nun, Fragmentierung des Textur-Speichers geht alle an, die vorhaben, mehrere Schriften gleichzeitig im Grafikkartenspeicher zu haben. Das Problem wirst also nicht nur Du haben. Ich habe dazu was gefunden: http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/linux/bks/SGI_Developer/books/Volumizer2PG/sgi_html/ch04.html#LE17959-PARENT
Die relevante Überschrift lautet: "Texture Memory Usage", handelt von 3D-Texturen, ist aber glaub ich auch auf 2D-Texturen anwendbar. Eine Anregung, die man im Hinterkopf behalten kann. Vermutlich ist Dir das nichts Neues.


EDIT: Das dort erwähnte "ROI" heißt "region of interest". Ich war ganz verwirrt. Für mich heißt das nämlich "return on investment".

Danke für den Link. Interessantes Thema. Mein Problem geht aber hauptsächlich eher in die Richtung, dass ich kleine Bilder in Texturen verwalten muss und dann halt so, dass dort Stellen frei werden die wieder benutzt werden können. Auch das gibts noch nicht. Derzeit ist das alles sehr sehr primitiv. Da muss ich auf jeden Fall noch etwas tun. So viel steht auf jeden Fall fest. Aber in denke, dass die meisten für den Anfang sowieso nur eine Hand voll Fonts erstellen werden und dann wäre das auch nicht ganz so tragisch.

Ich muss mir halt irgendwo merken welche Bereiche bereits belegt sind und dann kann ich mir ein passendes Plätzchen suchen. Aber das sollte nach Möglichkeit nicht allzuviel Zeit in Anspruch nehmen. Wird zwar nicht soo häufig aufgerufen aber gibt auch noch genügend andere Sachen die getan werden müssen.

Wobei ich natürlich auch berücksichtigen muss falls jemand 1000er Zeichen erstellen möchte. Die würden bei 512er Texturen unweigerlich zu irgendwelchen Problemen führen. Wobei ich mal behaupte, dass so etwas recht selten sein dürfte. Da könnte ich auch damit leben, das er die Texturgröße höher drehen muss.

Du meinst dann vielleicht sowas: http://www.blackpawn.com/texts/lightmaps/?
Zumindest könntest du effektiv mit diesem Algorithmus die Buchstaben in die Texture packen, müsstest dafür aber die Texturkoordinaten mitspeichern, da diese sich nicht leicht berechnen lassen.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Die Koordinaten kann ich derzeit eh nicht berehnen also von daher muss ich mir die sowieso merken. Aber ich befürchte, dass der (oder ein) Baum ein echtes Problem bekommt, wenn man oben raus ein Element löscht. Das ist ja das Spannenste. Also, dass Stellen wieder frei gegeben werden und neu verwendet werden.

Mir schwebte da auch was durch den Kopf wo die Textur in 4x4 große Teile unterteilt wird und man dann dort einzelne Felder als Frei oder belegt markiert. Dann suchst man sich für Zeichen einen Block mit 3x3 Feldern und packt da die Textur rein. Der Verschnitt davon ist zwar mitunter relativ groß dafür ist aber die Verwaltung relativ einfach und dadurch, dass die Struktur entsprechend flach ist sollte es recht einfach sein einzelne Bereiche wieder zu verwenden.

Wobei ich mir die Seite von SGI noch mal näher angeschaut habe. Irgendwie um so häufiger ich mir das anschaue um so weniger verstehe ich was die da machen. Bzw sind die anscheined an den passenden Stellen sparsam mit Infos.

Klingt für mich ziemlich wie die Hauptspeicherverwaltung die das OS machen muss. Eventuell findest du da nen Algorithmus der für dich passt.

_________________
Blog: kevin-fleischer.de und fbaingermany.com