Ja. So ein bisschen hast du da wohl auch recht. Wobei ich gestehen muss, dass ich keine Ahnung habe wonach man da suchen kann/sollte etc. Bzw ist normaler Hauptspeicher ja 1D ich habe Y * 1D Teile. Die alle in einem festen Abstand zueinander liegen.

Ich habe mir aber schon eine Testanwendung gebastelt in der ich so ein paar Sachen mal testen kann und dann auch sehen kann wie die einzelnen Bereiche angeordnet werden und wie viel Speicher tatsächlich genutzt wird. Mit der derzeitigen Technik und zufälligen Buchstaben größen, was nicht unbedingt realistisch ist, erhalte immer so eine Auslastung von 60-75% der Textur. Ich habe aber schon so ein paar Ideen die mal umsetzen und testen muss. Ich will ja nichts perfektes. Es genügt, wenn ich den Speicher nicht unnötig verschwende und wiederverwenden kann. Zu langsam sollte es auch nicht sein. Aber vielleicht erweist sich meine Idee ja auch als blödsinn.

Bei interesse kann ich die Anwendung/Source ja auch mal hochladen. Ist aber nichts wildes nur eben mal so dahingeklatscht.

Es ist ein Packing Problem, aber nicht eins von der klassischen Sorte, wo man einmal alles "zusammenpackt" auf eine optimale Weise, sondern wo man flexibel sein muss, weil andauernd was dazukommen oder wegfallen kann. Vielleicht ist es möglich, das Ganze grundsätzlich so aufzufassen wie eine Datei auf der Harddisk.

Dort ist es doch so, dass Dateien in Blöcke aufgeteilt sind und die Blöcke intern verwaltet werden. Die Blöcke einer Datei können über die HDD verstreut liegen, deshalb muss man die HDD von Zeit zu Zeit defragmentieren, weil zusammenhängende Blöcke schneller in den Hauptspeicher hereingeschaufelt werden können.

Vielleicht wäre es denkbar, Schriften (möglichst gleicher Größe) jeweils in eine Textur zu packen, und einen Buchstaben so aufzufassen wie einen Block auf der Harddisk. Dann könnten die Buchstaben einer Schrift auch über die Textur verstreut sein (soll heißen die Buchstaben einer Schrift müssen hier nicht unbedingt nebeneinander liegen). Ich weiß jetzt nicht ob das möglich ist (Performance?). Aber so könnte man vielleicht die Lücken besser ausfüllen, insbesondere, wenn die Schriften nicht immer die gleiche Anzahl von Zeichen bereitstellen.

Ist aber vermutlich eine ziemlich komplizierte Verwaltung nötig. Buchstaben gleicher Größe (auf dem Bildschirm) haben vielleicht annähernd die gleiche Höhe auf der Textur (die Varianz der Höhen ist gering, wenn man mit einer Maximalgröße arbeitet sogar Null) aber ziemlich verschiedenene Breiten (die Varianz der Breiten tendiert dazu, hoch zu sein), das bedeutet, man müßte vermutlich beim Laden einer Font häufig defragmentieren (Buchstaben umstellen, um mehr Platz zu schaffen).
Traude

Die Buchstaben einer Größe ist leider nicht so einfach, da ich nur das wirklich das nutze was auch wirklich belegt ist. Also ein Punkt belegt im Vergleich zu einem großen W einen lächerlich kleinen Bereich. Ein kleines w liegt ziemlich genau dazwischen. Und die Zeichen liegen derzeit so in der Textur wie sie erstellt wurden. Also sie können wild gemischt sein. Das er beim Zeichnen mitunter wechseln muss spielt derzeit noch keine Rolle. Aber den Aufwand um die Texturen zu defragmentieren finde ich derzeit etwas viel Aufwand. Denke aber nicht, dass es wirklich nötig sein wird.

Meine Überlegungen sind deinen aber nicht unähnlich. Nur nicht ganz so flexibel. Ich würde einfach stumpf die Textur in 4x4 oder 8x8 große Blöcke zerteilen und wenn jetzt ein Zeichen abgelegt werden muss, dann schaue ich nach ob ich einen (Beispiel) 2*2 Blöcke frei habe. Das herraus zu finden sollte aufgrund der Blöcke relativ einfach werden. Im Gegensatz zur Festplatte habe ich dann zwar maximal 3 "Cluster" die nur teilweise gefüllt sind aber bei 4x4 ist der Verlust nicht so groß wie es derzeit der Fall ist. Ich hätte aber so den Vorteil, dass ich intern eine fixe Struktur habe. Das macht das Handling wieder einfacher.

Im Endeffekt geht es mir ja nicht darum die Textur perfekt auszunutzen. Laut Murphy ist es dann sowieso so, dass ich einen simplen einzelnen Punkt auf einer zweiten Textur habe. Wenn ich ehrlich bin würde ich sogar über ~90% Belegung sogar nur noch ganz kleine Zeichen in eine Textur packen. Weil die Wahrscheinlichkeit, einen größeren freien Bereich finden zu können, recht klein ist. Und Geschwindigkeitstechnisch ist es so, dass der Platz nur belegt werden muss, wenn die Zeichen erstellt werden. Wer in einer Renderschleife ständig Schriften erstellt und wieder löscht dem gehört das Delphi gelöscht. Das Hauptaugenmerk lege ich auf der Wiederverwendbarkeit des Platzes.

Ich selber habe sogar den am meisten statischen Ansatz, viel unflexibler als Deiner: ich teile meine Schrifttextur in 16x16 Quadrate, punktum. Leicht zu bedienen und zu finden. Die obige Idee ist eigentlich nur der Versuch, es total zu verallgemeinern, und von der theoretischen Seite zu betrachten. Und wie man sieht, bin ich bei meinem Ansatz im Theoretischen steckengeblieben. Auf die Idee, zu sagen: Punkte schauen eigentlich überall gleich aus, vielleicht auch ein paar andere Zeichen? bin ich gar nicht gekommen. Das kann leicht passieren, wenn man im Wolkenkuckucksheim rumphilosophiert.

Die 16x16er Variante habe ich ja auch schon mal gemacht. Wenn es ausreicht ist das ja vollkommen in Ordnung. Aber dein anderer Vorschlag ging ja in eine völlig andere Richtung. In die selbe Richtung hatte ich ja auch gedacht. Und ganz ehrlich. Das was ich da überlegt habe ist auch vollkommen theoretisch. Ob das was taugt oder nicht stellt sich erst dann herraus wenn man es implementiert hat. Das wäre nicht der erste Code den ich nach der Implementation wieder ändere. Habe ich aktuell auch gerade wieder. Merkt man halt immer erst später. Und drüber disskutieren kann man ja über alles. So lange man sich nicht an Kleinigkeiten aufhängt.

Ich kann dir wirklich nur den Tannebaum empfehlen. Standardwerk für die OS-Vorlesung. Der hat diverse Verfahren erklärt. Wobei der Vorteil hier ist, dass du nicht zwingen eng beieinander liegende Felder brauchst. Ob das a und das b nachbarn sind oder nicht ist ja egal. Du musst halt nur noch irgendwo speichern, was wo liegt...

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

Also zum Thema (oh) Tannebaum habe ich nur ein englisches Buch "Excursions in Modern Mathematics" von 1994 gefunden. Ich kann mir aber nicht vorstellen, dass du das meintest. Also wenn du mir da einen Link etc mal zukommen lassen könntest.

Wobei ich aber auch gestehen muss, dass ich ein bisschen befürchte, dass die Speicherverwaltung eines OSs da etwas kompliziert bzw wenn nicht sogar etwas zu viel Aufwand ist. Zu mindest klingt das so für mich. Ich mag auch nicht ausschließen, dass ich etwas überragiere.

Moderne Betriebssysteme

In der (Uni-)Bibliothek deines Vertrauens solltest du das finden.

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

Das Teil ist einfach klasse! Vorallem die Beispiele die dabei sind. Codemässig konnte ich es mir noch nicht anschauen, aber allein der Aufbau des Codes für die DLL verspricht sehr sehr viel.
Leider sieht die VCL-Schrift schlechter aus als die SDL-Schrift. Das kommt aber daher das du verschiedene Lademethoden nimmst oder?

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

Hey du hast es ja sogar für Linux geschafft. Das lässt ja auch für die glBitmap hoffen...

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

Codeaufbau: Die Stellen die man sich besser nicht anschauen sollte die sind gut versteckt. In erster Linie ist es der Textparser. Der ist derzeit noch Bestandteil des Renderers und das macht das alles sehr unübersichtlich. Selbst für mich. Aber das werde ich mit dem neuen Textparser in der nächsten Version dann sowieso noch mal komplett ändern.

SDL vs GDI: Ich weiß zwar gerade nicht was du mit Laderoutine meinst aber das liegt an dem Hinting was die GDI macht. Dabei versucht er die Schrift auf die Pixel anzupassen. In diesem Fall ist das allerdings eher nachteilig. Bei dem Font "Bitstream Cyberbit" sieht es mit der GDI sogar besser aus als mit SDL. SDL (Freetype) geht eher her und glättet die Schrift einfach. Dadurch kann es gerne mal passieren, dass ein L keine klare Kanten hat sondern eine Weiche. Es hat beides Vor und Nachteile. Aber ich denke ich werde wohl die Schriftgröße noch ein bisschen anpassen. Sollen ja beide die gleichen Chancen haben.

Linux: Japp. Habe Linux von Anfang an berücksichtigt bzw musste ja eigentlich auch sehr viel selber schreiben (außer SDL und GDI). Und dann waren das alles eher nur Kleinigkeiten um es zum Laufen zu bewegen. glBitmap. SDL Kompatibel ist es schon so mehr oder weniger. Es fehlen aber nur noch einige Sachen. Wenn ich keinen Bock mehr habe Dokumentation zu schreiben werde ich das wohl auch fertig machen.

Einfach nur toll... Freu mich schon, wenn ich das benutzen kann! Deine pas Dateien sind schon ziemlich groß, wieviele Zeilen du wohl schon hast
Was ist denn das für ein Text den ich nicht lesen kann, da mir offensichtlich die Sprache nicht ganz so vertraut ist,
und was bedeutet er? Hatte mich eigentlich auf deutsch oder englisch eingestellt .
Erklärt der Text irgendwelche Features deines Projektes, oder ist er nur sowas wie: "Franz jagt im komplett..."?

Am besten finde ich die Präprozessor Dinger...
Die Wellenschrift bekomm ich wahrscheinlich nicht mal mit Gimp so toll hin, und wenn wäre es ja nur statisch

_________________
http://texelviews.delphigl.com

Das freut mich

Quellcode: Die TextSuite.pas hat eigentlich kaum wirklich Funktionalität. Die leitet die ganzen Sachen nur an die TextSuiteClasses.pas weiter. Aber diese unzähligen Abfragen ob alles Richtig ist. Das zerrt ganz schön an der Größe. Und 95% der TextSuiteWideUtils.pas sind nur Ansi Codepages. Also Arrays mit 256 words. Also so gesehen ist das gar nicht mal so viel Code.

Text: Der Text ist lateinisch und hat keine Bedeutung. Das Lorem Ipsum ist typisch für Blindtexte. Die sind nur als Platzhalter da.

Wellen: Da habe ich eine schlechte Nachricht für dich. Die sind nicht fest eingebaut sondern sollen nur den CustomPostProcessor demonstrieren. Mit anderen Worten wenn du nur die Bibliothek benutzen würdest würde das nicht gehen. Denn die Wellen sind Teil der Anwendung. Aber dadurch hat jeder die Möglichkeit eigene PostProcessoren zu schreiben. Na ja. Und den WellenProcessor darf natürlich auch jeder kopieren wie er will.

Genau, Postprocessor nicht Präprocessor
Aber wenn man sich die selbst schreiben kann ist es ja umso besser, solange es nicht zu kompliziert ist.
So kann man wenigstens noch etwas eigene Kreativität reinbringen. Und verschiedene Effekte sind dann möglich.
Kann man die auch in eine Datei abspeichern, sowas wie ein script? Wäre nämlich toll, da man sich dann eine eigene Datenbank aufbauen kann, und die bei Gelegenheit leicht mit anderen teilen.
Wieviele Zeilen und Denkarbeit umfasst denn zum Beispiel dieser Wellenprocessor? Nur damit ich mal ne Vorstellung habe...
Ich bin gespannt auf das erste Release.

_________________
http://texelviews.delphigl.com

Der erste (Prä)Release ist doch draussen

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