Ich hab noch nen Fehler gefunden.
Und zwar wird der über tsSetParameteri(TS_FONT_CHAR_SPACING,x); gesetzte Zeichenabstand bei zentrierter Schrift nicht richtig in der Berechnung der Zeichenposition einbezogen, was dazu führt, dass sich die Zeichen horizontal verschieben.
Kann es außerdem sein, dass der Parameter ChannelMask bei tsImageBlur rein garnichts bewirkt?
_________________ 2+2=5 For extremely large values of two
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Hattest du meine Frage von Oben gesehen? Es würde mich helfen ein Standardfont finden zu können, wenn du mir sagen könntest wo du das gesehen hattest.
Channelmask. Ja da hast du wohl anscheinend leider recht. Die Funktionen setzt am Anfang für jeden Kanal eine Funktion und aktuell wird anscheinend nur die für den Alpha gesetzt. Alle anderen werden auf ignore gesetzt. Als Hotfix kannst du das ja bitte eben selber in der Methode TtsImage.Blur (Datei TextSuiteClasses Zeile 1691-4) die Maske auswerten und die beiden Funktionen verteilen, wenn du das eben benötigst. Werde ich aber in meinen Bugtracker aufnehmen und fixen.
Zeichenabständen: Also ich schau mir das mal an. Wenn du davon evtl nen Bild hättest wäre das auch hilfreich.
Nun, wirklich genau hatte ich mir das mit den nicht vorhandenen Buchstaben noch nicht angeguckt. Ich hatte einfach beim Editor (notepad.exe) verschiedene Schriftarten probiert, und dort waren die (in meinem Fall japanischen) Zeichen bei nichtvorhandensein in der Schriftart immer gleich.
Ich hab jetzt noch ein bisschen weiter geforscht, die bei Notepad immer verwendeten Zeichen stammen (für Japanisch) aus der Schriftart "MS UI Gothic", beim Eingeben wird mit großer Wahrscheinlichkeit "SimSun" (da sehen sich viele Ähnlich, deshalb nur wahrscheinlich) verwendet.
Auf einem Rechner ohne "Dateien für ostasiatische Sprachen installieren" (XP Home, Sp2) ist keine der genannten Schriftarten vorhanden.
Screenshot von dem Zeichenabstand ist im Anhang. Oben ganz normal, in der Mitte mit vergrößertem Zeichenabstand und unten mit verkleinertem.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ah. Das meinst du. Ist das eigentlich noch der ursprüngliche Blockmode aus dem Sample oder ist das der Single Line Modus? Denn ich hatte gerade mal geschaut im Blockmodus sollte sollte das hoffentlich nicht passieren.
Das Problem liegt aber daran, dass das Spacing auch zum letzten Zeichen der Zeile hinzugerechnet wird. Und dann ist sie breiter als sie normal dargestellt wird. Das sieht dann komisch aus. Ich will in der nächsten Version aber sowieso den Parser komplett überarbeiten. Aber das werd ich wohl für jetzt noch fixen. Wobei ich kurioser weise auch einen Eintrag in meinem Bugtracker habe.
Zu dem Standardfont: Schon mal danke. Ich werde mir das mal anschauen. Evtl fällt mir ja was sinnvolles zu ein. Wobei man sicher auch noch etwas gebrauchen könnte um die Systemfonts zu enumerieren und Informationen von den Fonts einzuholen. Und die beiden Sachen könnte man sicher miteinander irgendwie kombinieren. Denn die Infos von den Fonts bräuchte man so oder so.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Wilson hat geschrieben:
Das ist Single-Line-Modus, und im Blockmodus trat es wirklich nicht auf.
Gut. Denn sonst hätte ich ein echtes Problem. Aber ich finds auch recht unpraktisch, dass ich da an der Stelle überhaupt eine solche Unterscheidung habe. Eben genau wegen solchen Sachen. Aber das steht ganz groß als nächstes auf dem Plan.
Habs mir den Link mal angeschaut und ist auf jeden Fall ganz interessant zu sehen wie das in Windows gelöst ist. Aber ich denke ich werde das so nicht machen können. Denn das ist sehr stark von Windows abhängig. XP oder W2K. Und dann auch nur mit der GDI. Ich habe aber noch einen Linuxpart bzw SDL_ttf und später FreeType2 auch unter Windows. Da will ich dann natürlich nicht für jede Kombination eine extra Lösung einbauen müssen. Ideal wäre für mich eine für Windows und eine für Linux. Alles andere sollte egal sein.
Aber ich denke es wird auch eine Möglichkeit benötigt die alle Systemfonts enumeriert. Wenn mal jemand eine Anwendung damit schreiben möchte. Also ich. Dann sollten die Systemschriften benutzt werden. FireFox ist dafür ein sehr schönes Beispiel. Hab mal damit rumgespielt. Ein einziges Font mit armenischen Zeichen und ihm sie die Standardeinstellungen für die Sprache egal. Er bedient sich bei allen Schriftarten. Ich denke so etwas in dem Dreh sollte ich dann auch machen. Denn ansonsten ist das nichts halbes oder ganzes.
ich benutze die TextSuite in meinem Projekt. Muss echt sagen, ich habe keine bessere Möglichkeit zur Textausgabe in OpenGL gefunden, Respekt!
Ich weiß nicht ob es dir bekannt ist, aber ich habe gemerkt, dass die TextSuite ein paar Memoryleaks erzeugt. Ich red jetzt nicht um den heißen Brei, hier ist die Stelle:
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Markus hat geschrieben:
ich benutze die TextSuite in meinem Projekt. Muss echt sagen, ich habe keine bessere Möglichkeit zur Textausgabe in OpenGL gefunden, Respekt!
Danke.
Markus hat geschrieben:
Ich weiß nicht ob es dir bekannt ist, aber ich habe gemerkt, dass die TextSuite ein paar Memoryleaks erzeugt. Ich red jetzt nicht um den heißen Brei, hier ist die Stelle:
Nein. Das war mir bisher nicht bekannt. Ich versuch mich jetzt einfach mal rauszureden in dem ich sagen, dass das vermutlich daran liegt weil diese Klasse früher mal ein Record war. Danke fürs melden. Ich werde das in der nächsten Version fixen.
PS: Finde demnächst bitte größere Fehler. Alleine der Aufwand den ich dafür in meinem Bugtracker treiben muss ist größer als das Beheben des eigentlichen Fehlers.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Auch wenn ich (wegen Java) die Textsuite nicht nutzen kann: Hat das neue Feature außer auf die Texturgröße noch andere auswirkungen? Z.B. auf Geschwindigkeit, Allgemeine Qualität der Ausgabe etc.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Wenn du in Java DLLs benutzen kannst (was afaik bei opengl ja auch so gemacht werden muss) dann könntest du sie auch benutzen. Ganz zu anfang hatte ich zwar eine klassenbasierte Schnittstelle. Habe mich aber sehr schnell dagegen entschieden und eine C kompatible Schnittstelle gewählt. Eben um kompatible zu so ziemlich allen Sprachen sein zu können. Einen Header für C + .DEF/.LIB + .DLL/.SO liegt im übrigen allen Packeten bei.
Was die Größe der Glyphen angeht. Alle Glyphen bekommen einen Rand von 2 Pixeln. Von diesem Rand wird das äußere Pixel nicht dargestellt. Das innere Pixel zwar schon aber das ist überwiegend transparent. Eventuell stelle ich das später noch auf 1 Pixel Rand um. Das genügt normal auch. Bin mir aber noch nicht 100%tig sicher, ob da nicht vielleicht noch irgendwelche Seiteneffekte entstehen können. Deswegen erst mal 2. Das ist sicherer.
Die Zeichengeschwindigkeit dürfte es nicht beeinflussen. Es wird zwar 1 Pixel auf jeder Seite mehr gezeichnet aber das dürfte nicht mal messbar sein. Beim Erstellen der Glyphen wird aber zusätzlicher Code ausgeführt. Die Glyphen werden aber auch nur ein mal erstellt. Der Code geht ein mal durch die Bilddaten und passt die Farbe der Pixel an, die komplett unsichtbar sind und neben sichtbaren Pixeln liegen. Klingt komplizierter als es ist. Der Code dürfte von der Zeit her aber kaum auffallen. Da dauert das Rastern der Buchstaben in der passenden Fontbibliothek vermutlich deutlich länger.
Qualitativ sollte es sich schon ändern. Zu mindest wenn man die Buchstaben skaliert, sollte es sich deutlich verbessern. Es sollten keine Klötzchen mehr zu sehen sein und solche Rundungen wie bei 'O', 'D' etc. sollten auch vernünftig rund erscheinen. Konnte teils abgeschnitten wirken.
Wenn man die Texte pixelgenau darstellt, dann hat diese Option allerdings so gar keine Auswirkungen. Nicht mal optische. Da das alles nur dazu gedacht ist um die Misstsände bei der OpenGL Texturfilterung zu umgehen. Und die Filterung wird bei 1:1 Darstellung ja nicht benutzt.
erstmal ein ganz großes Lob und Dankeschön für deine Mühe! Ein solches Paket ist genau das, das ich gerade brauche. Die glBitmap-Ausgabe ist nicht nur hässlich, sondern auch vollkommen unflexibel.
Ich habe allerdings ein Problem: Es wird nichts gezeichnet
Ich verwende Version 0.8.0 und den Code des Beispiels "SingleLine_VCL". Dieses Beispiel funktioniert einwandfrei, auch selbst compiliert!
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Morschen. Danke. So was hört man gerne.
Zitat:
Hast du eine Vorstellung, wo da der Fehler liegen könnte? Irgend eine Eigenheit deiner Bibilothek?
Die Bibliothek hat keine Eigenheiten. Das ist alles Absicht. Aber ja. Ich denke ich weiß woran das bei dir liegt. Wärend dem Zeichnen rufst du glOrtho auf. Das mit zNear = 0 und zFar = 1. Direkt danach verschiebst du die Matrix aber um -10. Damit werden die Quads die die TextSuite zeichnet direkt verworfen.
Ich denke ich weiß woran das bei dir liegt. Wärend dem Zeichnen rufst du glOrtho auf. Das mit zNear = 0 und zFar = 1. Direkt danach verschiebst du die Matrix aber um -10. Damit werden die Quads die die TextSuite zeichnet direkt verworfen.
Autsch.
Aber das war leider nicht der einzige Fehler. Im eigentlichen Code habe ich ihn auch schon behoben - nur in diesem Test hat er sich wieder eingeschlichen. Selbst mit -128...128 als Near-/Far-Wert klappt's nicht. Und ich habe keine Ahnung, woran das liegen könnte.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Hmmm. Okay. Du kannst im übrigen auch testen ob die Ausgabe generell sichtbar wäre, wenn du zum Beispiel nur mal ein simples Quad (Position 0, 0 mit mindestens Größe von 20*20 und einem Z Wert von 0) zeichnest. Also direkt vor dem Aufruf von tsTextOut und nach dem Translate etc. Dann sollte das Quad sich genau dort befinden wo der Text ist. Wenn das nicht sichtbar wäre, dann ist irgendwas faul. Bzw kannst du auch den Parameter TS_DEBUG_DRAW_CHAR_RECTS aktivieren. Dann zeichnet die Bibliothek selber Quads an den Stellen der Zeichen. Diese Quads sind aber nur so groß wie die Zeichen sind.
Folgende Punkte können die Textausgabe auch noch beeinflussen.
- Andere aktive Texturtargets (außer GL_TEXTURE_2D. Das wird neu gebunden). Wenn mehr als ein Target aktiv ist, dann weiß OpenGL nicht mehr welche Textur benutzt werden soll.
- Wenn durch glFrontFace oder glCullFace die Hinterseite der Quads zur Vorderseite deklariert wurde und Backfaceculling aktiv ist. Dann siehst du von der Schrift nur die Hinterseite die aber nicht dargestellt wird. Alternativ mal explizit Backfaceculling deaktivieren.
- Sollte sich an der Stelle schon etwas befinden, dann musst du den Tiefentest anpassen bzw. deaktivieren. Also bei Schrift in einer GUI oder so etwas kann das passieren.
Wenn das alles keine Erlösung bringt, dann würde ich dich bitten mir das Projekt mal zuzuschicken. Dann schaue ich selber mal. Sofern das möglich ist. Wenn nicht möglich, dann bedenke, dass die Schrift nur aus texturierten Quads erstellt wird und die sich genau so verhalten als wie wenn du selber ein Quad mit einer Textur darauf zeichnen würdest. Also alles was dein Quad beeinflussen würde wird auch die Schrift beeinflussen.
PS: Welche Farbe hat eigentlich dein Framebuffer? Nicht, dass es so etwas ist wie die ostfriesische Nationalflagge. Also weißer Adler auf weißem Grund. Nur eben in Schwarz. Du stellst ja die Farbe der Schrift auf Schwarz.
erstmal vielen Dank für deine Mühe, du bietest ja richtigen Kundensupport!
Ich bin die von dir genannten Punkte einmal durchgegangen - und am einfachsten lag's: Am Backfaceculling. Allerdings nicht im klassischen Fall - dass einfach die Zeichenrichtung verwechselt wurde -, sondern an der Richtung des Koordinatensystems. Ich habe ein einheitliches mathematisches (unten-links der Ursprung) verwendet, aber das gefällt der TextSuite wohl gar nicht. Lediglich die Basislinien im Debugmodus wurden gezeichnet, was mich zuerst ganz schön durcheinanderbrachte.
Ich habe jetzt das GUI-Koordinatensystem an das von Windows angepasst, so klappt auch alles ganz gut. Aber das wäre doch die Gelegenheit, die TextSuite auch andersrum zeichnen lassen zu können.
Grüße,
Yogu
Edit: Wenn du dir das Projekt dennoch mal ansehen willst: Yogularm 2 Snapshot 10. Den Source habe ich nicht hochgeladen, bei Interesse einfach nachfragen. Er ist aber ziemlich schwierig zu verstehen, da an sehr vielen Stellen initialisiert bzw. gezeichnet wird.
Noch eine kleine Frage am Rande (ich hoffe mal, das ist gestattet - schließlich geht es hier ja um Schrift ): Darf ich Verdana in mein Projekt mit einbinden? Also die Dateien verdana*.ttf mit einbeziehen? Muss ich einen Hinweis einfügen? Schließlich gibt es Verdana ja auch kostenlos zum Download.
Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.