@Openglerf


Die Dependecy ist gar nicht groß und ist auf ungefähr jedem Linux-like-OS zu finden (=> imo fast jedem ordentlichem OS). Der Speicherverbrauch ist vermutlich nicht signifikant größer als bei deiner Methode und du hast vmtl. kein Hinting, etc.

Und: Was für Perspektive, Animationen und Effekte brauchst du, die nicht mit vorgerendertem Text in einer Textur gehen?

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Genau das ist der Punkt. Bei Windoof gibts das alles nicht. Und ich will nicht jedesmal zig MegaByte libs mit ausliefern.
Ein Versuch war's wert. Ich werd mich aber jetzt wieder auf die TextSuite konzentieren. Die kann das fast genauso gut. In manchen Dingen ist sie meiner Meinung nach sogar besser. Ich kann mir den FontLoader (FreeType, GDI, SDL, ...) und den Rendere (OpenGL, OPenGL ES, ...) selbst aussuchen, ohne das ich irgendwas an der Handhabung ändern muss. Die TextSuite macht das alles von allein.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Bei Windows kannst du eine einzelne DLL mitliefern. Das sind Windowsuser sowieso gewöhnt...

Und wieso zur Hölle willst du mehrere FontLoader / Renderer haben? Dein Programm braucht nur eins und mehrere zu supporten ist nur fehlerträchtig. Lieber dafür eine feste Kombination, die bombenfest läuft.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Mit einer könnt ich ja leben, aber die Liste wird immer länger:

Und das sind nichmal alle. Zur Zeit scheiterts an der libffi-6.dll und wer weiß was danach noch kommt.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Also wenn ich dich jetzt richtig verstanden habe, willst du einfach nur die verwendeten Glyphen in der Textur speichern. Problem waere halt das unicode zu viele Zeichen hat und der Font ggf. unterschiedliche Metrics?

Wenn ja mach doch einfach eine Hashmap ueber das Zeichen und mehrere B-Baeume. Jeweils ein B-Baum waere dann fuer eine Textur verantwortlich und speichert das Packing. Also im Prinzip wie hier.

_________________
Meine Homepage

Hey,

so ähnlich hab ich's jetzt gemacht. Ich hab nen Quad-Tree aufgesetzt, der speichert wo die Textur noch freie Plätze hat. Die Fläche, die der Quad-Tree abdeckt, ist noch frei. Die Kind Knoten werden nur angelegt, wenn diese nötig sind. Das bedeutet, eine leere Textur hat nur den Root-Knoten und eine komplett volle Textur hat gar keine Knoten mehr. Ein Knoten kennt nur seine Kind-Knoten (falls vorhanden), Position und Größe rechne ich jedesmal bei der Rekursion mit (das bischen + und - kostet ja nix, außer bisl Stack-Speicher). So hab ich einen sehr geringen Speicherverbrauch für die Verwaltungs-Strukturen, und kann Glyphen trotzdem schnell und positions-genau einfügen und muss nicht Pixel für Pixel durch die Texture rennen.

€: könnte sein, das der B-Baum die Verteilung der Glyphen etwas besser macht, aber dafür brauch ich auch mehr speicher für die einzelnen Koten. Ich vergleich die beiden mal, wenn meine Implementierung fertig ist.

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Was fuer Speicher, da reicht doch ein short pro Knoten voellig aus.

_________________
Meine Homepage

Is richtig, ich sag auch nich, das es Unmengen frisst. Der Unterschied zwischen dem B- um dem Quad-Baum ist folgender:

• der B-Baum benötigt mit zunehmenden Glyphen im Baum mehr Koten. Der Speicherverbrauch steigt linear mit der Anzahl der Glyphen. Wenn man viele kleine Glyphen hat, dann geht das relativ schnell in den Kilo-Byte Bereich.
• beim Quad-Tree wird der Speicherverbrauch zwar auch erst steigen umso mehr Glyphen dazu kommen, weil die Tiefe des Baums wächst, aber umso voller die Textur wird, umso weniger Knoten gibt es im Quad-Tree, denn der Quad-Tree deckt nur den freien Bereich ab. Wo die Glyphe liegt und wie groß sie ist, speichert die Glyphe selbst. So hab ich den Speicherverbrauch nur da wo ich ihn wirklich brauch, nämlich in der Textur (es gibts ja u.U. mehrere), die noch nich vollständig gefüllt ist und noch Elemente aufnehmen kann.

Natürlich sind das nur Kilo-Bytes, aber warum Speicher "verschwenden", wenn man es auch ohne Probleme mit weniger hin bekommt.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Jap, wobei ich da eher mit effektiven Unterschied von ein paar Bytes rechnen würde. Von daher denke ich du solltest eher darauf achten wie sich was im Gesamtpaket auswirkt. Wer weiß vielleicht ist auch sogar ein einfaches Array hier die beste Lösung, denn Letter und Digit braucht man schließlich immer komplett...

_________________
Meine Homepage

Ich verwende übrigens einen Algorithmus, der dort "Cygon" genannt wird, von hier: https://devel.nuclex.org/framework/wiki/RectanglePacking
Mit den Ergebnissen in Kombination mit teilweiser Sortierung, bin ich relativ zufrieden, auch wenn definitiv noch Optimierungspotential besteht. Dafür ist er in 50 Zeilen implementiert. Ein älteres Beispielbild, das ich gerade zufällig noch herumliegen hatte, habe ich angehängt.

Bergmann:

Wenn du Lazarus mit gtk verwendest (ist wimre Standard) hast du die ganzen Dependecy's so oder so schon...

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

@OpenglerF: Danke, guck ich mir dann mal in Ruhe an.

@end: GTK ist nur unter Linux standard, unter Windows ist es die WinAPI.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Bei AngelCode werden die Glypheninfos seperat in eine Datei geschrieben, so kann man beschreibung und texturausgabe getrennt in die eingestellten Formate exportieren.
Diese kann man dann z.B. in ein eigenes Format bringen, welches für die Hardware und API am besten geeignet ist.
Bei Texturen z.B. signed distant field mit dxt5 bzw. eine der advanced Erweiterungen, ohne den ganzen dds header gedönst.
Die Beschreibung ist ein Dictionary, welches auf Bytecodes die Glyphen anbietet.
Dort braucht man in der Regel nicht so viel wissen und sollte nicht gerade ISO's vollständig implentieren.

Bei Spielen sind 99% der Probleme, die in Schriftsetzungs, Textprogrammen und ähnlichen hat nicht gegeben.
Einzig schriftrichtung und X/Y Offset sind elementar wichtig.
Viele weitere Informationen benötigt man, wenn man z.B. korrekt Schriftarten mischen will.

Alle Spiele die ich bisher in der Produktion gesehen hab haben die Informationen prebaked geliefert und das Rendering hat nur den X/Y Offset und einige noch Schriftausrichtung enthalten.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Dxt5 für Schrift?
Man braucht doch nur einen Kanal, Dxt5 bringt 4 Kanäle mit sich und führt besonders bei Distance Fields möglicherweise zu Artefakten. Da nimmt man doch lieber R8/R16.
"COMPRESSED_RED_RGTC1​" könnte man vielleicht probieren.

Ich persönlich versuche einen hybriden Modus zu implementieren:
Ein Teil der Daten kann voraus generiert werden, aber bei Bedarf will ich auch Zeichen nachladen.

DXT5 ist die standard Antwort, für no fancy Stuff, benutzen wir in einigen Projekten mit Unity.
Wie gesagt sind Advanced formate wesentlich besser geeignet.
Wenn man auf die Performancevorteile von DXT verzichten kann, ist halffloat eher meine Wahl.

Mit OpenGL4 kann man um vieles mehr machen.
Lookuptables über Quadtree(interger/bitset texture target) und einem Texture array.
Tesselation Unit und Quadratische Splines.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004