Öhm. Genau i0n0s. Wie ich in dem Projektcode ja geschrieben habe handelt es sich zwar um eine Developerversion ohne Versionsnummer ABER wenn niemand wirklich Einspruch erhebt, dann wird der Quellcode auch so als Version 0.8 veröffentlich. Falls tatsächlich noch wirkliche Änderungen an der Schnittstelle stattfinden dann denke ich werden diese wohl für die Meisten keine Auswirkungen haben.

Postprocessor: Es handelt sich dabei nicht um eine Skriptschnittstelle. Dort wird eine Funktion an die Bibliothek übergeben die immer dann aufgerufen wird, wenn ein Zeichen erstellt werden soll. Die Funktion bekommt dann den Zeichencode und eine ID von einem Image übergeben. Mit den tsImage* Funktionen kann dieses dann beliebig manipuliert werden. Wärend dessen können auch Einstellungen der Zeichen verändert werden. Also die Angaben über Advance (Schrittweite) oder die Baseline (Grundlinie). Die genaue Beschreibungen gibt es dann in der Hilfe. Oder falls es jemand jetzt fragt.

Im Falle des Wellenprocessors lasse ich mir nur stumpf den Pointer der Bildzeile (ScanLine) geben und verschiebe die Zeile um 1-3 Pixel nach Recht oder Links. Errechnet wird die Verschiebung mit einem simplen Sinus. Alles in Allem 50 sehr übersichtlich gestaltette Zeilen Code. Nichts besonderes. In Kombination mit den bestehenden Processoren ergibt sich dann das Gesamtbild.

Diese Processoren könnte man auch irgendwo sammeln aber ich vermute mal stark, dass sich die Anzahl doch eher in Grenzen halten wird.

Zeilen: Das sind ~10300 Quellcodezeilen. Allerdings bin ich großzügig was Leerzeilen angeht. Kannst du dir aber auch selber alles anschauen, denn die Code befinden sich alle im Bibliothekspaket. Und der WellenProcessor befindet sich direkt in den Quellen des Beispieles.

Hey~

also ich hab die TextSuite jetzt auch mal ausprobiert und.. mir sind direkt mal ein paar kleinigkeiten aufgefallen
Wobei ich nicht weiß, was hier schon besprochen wurde.. hab die 10 seiten nicht gelesen ^^

1) Da scheinen einige State-changes zu sein wenn man den text schreibt... da wär es super wenn du die wieder zurücksetzen würdest (oder später in der hilfe zumindest sagen was alles geändert wird).. aufgefallen war es mir besonders bei den texturen (ich hatte in dem projekt texturen deaktiviert) und bei der farbe.

2) Zur Farbe.. wenn man nach dem ändern der Farbe über den tsBefehl die farbe via glColor ändert, war's das mit dem tsBefehl... ich weiß, das ist schon dumm wenn man das tut *g* aber ka ob das nich evtl zu irritationen führen könnte

3) Ich habe nichts gefunden á la TextOut oder so.. also eine möglichkeit einfach ein Wort irgendwo hinzuschreiben.. (so wie das TextOut vom Canvas).. und 6 zeilen code für ein einziges Wort ist schon ne menge ^^

So, und dann noch eine persönliche Meinung von mir... es scheint als hättest du es anfangs mal Klassen-basiert gemacht und bist dann irgendwann zu dem State-basierten gewechselt... mir persönlich gefällt es 1000x beser mit klassen zu arbeiten, ist einfach übersichtlicher und angenehmer.. (Bei OGL bastelt sich ja idR auch jeder seine klassen aus dem OpenGL Code).. und grade bei etwas wie der TextSuite finde ich, würde sie das Klassen-System wesentlich besser anbieten.. ^^

Aber alles in allem, super arbeit! Magst du mir bei gelegenheit mal erklären wie du die font aus der TTF Datei ausliest?

Aya~

Da sind viele Altlasten in dem Thema. Deswegen macht das nichts. Aktuell sind nur 2-3 Seiten.

1) Selber zurücksetzen mag ich das eigentlich nicht, denn nachher änder ich das tausendfach hin und wieder zurück. Aber das werde ich in der Dokumentation aber auf jeden Fall erwähnen. Sind eigentlich nur Texturbindings und GL_TEXTURE_2D. Aber da muss ich später eh noch ein paar Sachen ändern, da es momentan nur Itterativ gezeichnet wird. Aber das kommt nicht mehr in diesem Release.

2) Na ja. Das ist im Endeffekt das Gleiche in sofern hast du recht. Aber sobald du ein anderes VALIGN als Top hast wirst du um den tsTextColor nicht drumherum kommen. Denn der arbeitet in diesem Fall verzögert, da der Text nicht so ausgegeben werden kann wie du ihn aufrufst. Bei einem VALIGN von TOP wird der Text sofort ausgegeben. Sonst muss ich ja wissen wie groß er ist und da wird dann alles im tsTextEndBlock gerendert. Dann ist das tsTextColor die einzige Möglichkeit die Farbe zwischen wörtern zu ändern.

3) Doch. Das hast du bereits gefunden. tsTextOut. Also sobald du es außerhalb eines Blockes benutzt wird der Text so an die Stelle ausgegeben an der sich aktuell OpenGL befindet. Als Beispiel dazu solltest du dir mal das SingleLine_* Beispiel anschauen. Der Text wird per Default an der Baseline ausgegeben. Kannst du aber mit tsSetParameter und TS_SINGLELINE ändern.

Klassensystem. Ja das stimmt. Das waren mal klassen und ich kenne die Argumente auch. Arbeite selber auch lieber mit Klassen. Im Endeffekt könntest du auch die TextSuiteClasses einbinden und mit den Klassen arbeiten. Funktionieren würde es eigentlich. Du musst nur schauen was in den passenden TextSuite Methoden so alles gemacht wird. Aber der Grund gegen die Klassen war recht einfach. Kompatibilität zu anderen Systemen und Sprachen. Ich denke so etwas in der Art gab es bisher noch nicht so häufig und genau aus diesem Grund wollte ich die Bibliothek nicht auf Pascal beschränken. Um ihr nicht die Möglichkeit zu nehmen sich international durchsetzen zu können.

Die Fonts lese ich persönlich nicht selber ein. Das Einzige was ich selber einlese ist der Name der Fonts unter Windows. Ansonsten benutze ich nur vorhandene Bibliotheken. Also die GDI oder SDL_ttf. Wobei ich noch FreeType fest eingeplant habe. Denn SDL_ttf hat so einige wirkliche Schächen. Falls du aber dazu konkrete Fragen hast schieß los.

Und sonst freut mich, dass es gefällt.

Ich hab das bei mir immer mit glPushAttrib(GL_ALL_ATTRIB_BITS) gemacht. Das sollte doch auch bei dir gehen.

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

gehen tut das natürlich, ist aber leider auch ein recht langsamer befehl (zumindest war das früher immer so).. und wieso tausende states speichern, wenn nur 2-3 verändert werden?

Also derzeit ist es noch nicht tragisch. Später werden es evtl mehr aber das dürfte dann trotzdem nicht so ins Gewicht fallen. Und ich weiß halt nicht wie die Bibliothek eingesetzt wird. Wenn man zum Beispiel tausend einzelne Wörter/Buchstaben ohne Blockmodus zeichnet, dann kann es wohl doch recht schnell zu einem anständigen Sümmchen kommen. Und das sind für mich komplett unterschiedliche Aufrufe. Müsste ich also ständig setzen und löschen. Weiß nicht ob das so gut ist. Denke wenn man das gut kommuniziert dann wird es fürs Erste ausreichen.

Evtl. für später könnte ich mir vorstellen, dass ich 2 Methoden anbiete die den Zustand sichern und wieder herstellen. Aber das mache ich von der Nachfrage abhängig. Und wie viele States da noch hinzukommen.

Du solltest nicht den DAU annehmen. Biete eine performante Methode an und eine für alle übrigen Zwecke. In der Doku muss an den wichtigen Punkten immer stehen, dass Methode 1 genutzt werden sollte.

Is doch wie bei OpenGL. Da kann man auch die gleichen Ergebnisse auf unterschiedliche Weise erreichen. Aber man bekommt von anfang an erzählt, welche Methode performant ist und welche nicht.

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

Hi,

im grunde hab ich auch nichts gegen das zurücksetzen der States, nur.. für mein empfinden wird der code unübersichtlich, wenn ich z.B. dashier im code hätte:



weil, das GL_TEXTURE_2D wird halt nirgendwo aktiviert (in meinem code) und daher kann es nach längerer pause doch etwas verwirrend sein, bzw sieht es einfach nicht hübsch aus

Das ist auch das einzige was mich daran stört.

Wie wäre es denn mit etwas á la:



also im grunde sowas wie push und pop Attribs, aber halt nur für die states die du auch benutzt

Aya~

Was meinst du damit?

Aber ja. Die Argumente verstehe ich. Ich muss aber gestehen, dass ich mir darüber bisher auch noch keine Gedanken gemacht habe bzw daran auch nicht gedacht habe.

Ja so etwas ähnliches wie tsPushStates und tsPopStates würde mir dazu auch spontan einfallen. Evtl müsste ich die States auch noch in verschiedene Kategorien fassen. Denn genau genommen ist glTranslate auch ein State. Aber der macht nicht überall auch wirklich Sinn. Manchmal allerdings schon.

Und zu viel Auswahl möchte ich dem Entwickler auch nicht an die Hand geben. Denn auf der einen Seite ist es arbeit für mich und verwirrend auf der anderen Seite. Man darf nicht vergessen, dass ich schon bereits fast 90 Methoden zur Verfügung stelle und es werden mit dem Laufe der Zeit nicht weniger oder aber einfacher. Von den unzähligen Parametern mal abgesehen.

Was man auch nicht außer acht lassen darf ist die Möglichkeit, dass es verschiedene Renderere geben wird. Von daher darf es nichts sein was fest auf OpenGL zugeschnitten ist. Derzeit und Primär zwar nur OpenGL aber ich muss dazu nur eine Klasse mit 6 Methoden austauschen.

Derzeit tendiere ich aber auch zu tsPopStates und tsPushStates. Mit Bitset (bei pop) für die einzelnen Bereiche die auch per tsSetParameter gesetzt werden können und automatisch nach den einzelnen Aktionen durchgeführt werden. Wobei das dann aber eigentlich ein Stack wäre. Und Stacks habe ich bisher noch gar keinen.

Aber ich denke da muss ich wohl mal 1-3 Nächte darüber schlafen.

Das mit dem DAU war so gemeint, dass du deine Nutzer nicht in Watte packen musst und alle Komplexität von ihnen fernhälst. Dein Tool ist ja dazu da anspruchsvolle ergebnisse zu liefern. Da kannst du denen auch zutrauen die States selber zu sichern und zu laden. Man muss nicht alles selber machen.

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

Hi,

ich hab gerade mal versucht die TextSuite einzubauen aber leider stürtzt mein Programm mit ner Access Violation ab sobald ich tsContextCreate ausführe. Mit Step by Step rumprobiere bin ich zu der Vermutung gekommen das es in dieser "procedure RaiseException; stdcall; external kernel name 'RaiseException';" Zeile passiert. (Die gehört zur TextSuit)

Ich habe hauptsächlich aus einem Beispiel kopiert, da mein Programm ohne die ganze SDL initialisierung auskommt habe ich die weggelassen, könnte es vielleicht dadran liegen? Das ist übrigens die erste Zeile in der InitTextSuite, davor initialisiere ich nur OpenGL.

Also ich muss gestehen ich habe so keine Ahnung was da passiert. Die RaiseException ist eine Methode von Windows und diese Unit binde ich nicht ein. Zu mindest nicht direkt. Ich erstelle eine TCriticalSection aus der SyncUtils und dort wird die Windows eingebunden. Es kann sein, dass es dabei einen Fehler gibt. Was ich gerade nicht verstehen kann warum.

Was benutzt für einen Compiler? Betriebssytem? Und ich denke mal der erste Befehl ist folgender?


Im Zweifel setzt mal das define TS_EXTERN_STATIC (oder auskommentieren) oben in der TextSuite.pas und sorge dafür, dass dein Programm die dll aus dem libTextSuite Verzeichniss findet. Wobei ich schon sehr daran interessiert wäre herrauszufinden warum das bei dir so ist wie es ist.

Ah okay ich hatte am Anfang die ganze errorabfrage rausgenommen weil ich dachte das die nur zum Fehlerfinden da ist aber die scheint ja doch ihren Sinn zu haben

Danke für den Tipp ich hoffe du bist nicht genervt falls ich nochmal nen Problem mit der Suite haben sollte.

Ja das tsInit hat einen ziemlich triftigen Sinn. Auch wenn es sonst überall eher unscheinbar ist. Bei mir ist es grundlegend wichtig. Ich hatte auch mit dem Gedanken gespielt im tsContextCreate, falls nötig, die Bibliothek zu initialisieren. Aber das würde nicht viel bringen, da sie dann trotz dessen ziemlich hilflos wäre und es eher verwirren würde. In der kommenden Version gibt es auch keine Exception mehr. Das hatte ich schon eingebaut gehabt. Allerdings tut sich dann auch nichts mehr, da lediglich ein Fehler gesetzt wird. Und der muss abgefragt werden.


Nerven: Aber ganz im Gegenteil! Bei allem was irgendwie auftaucht besteht für mich die Chance es besser zu machen oder Fehler zu finden die sich evtl nicht sofort als Fehler zu erkennen geben. Also sobald du/ihr irgendwelche Ideen, Anregungen, Fragen, Probleme, Merkwürdigkeiten, kuriose Arbeitsweisen etc habt. Immer sofort raus damit! Es soll ja schließlich die Arbeit erleichtern und unnötig verkomplizieren.

Okay dann trau ich mich mal und stelle das nächste Problem:

Ich erstelle einen Button und dieser soll die Größe der Schrift haben solange nichts anderes angegeben wird. Die lese ich mit:



Komischerweise bleibt textwidth im Gegensatz zu textheight (beides Integer) leer. Wodran kann das liegen? Und gibt es die Möglichkeit bei der Höhenangabe die Buchstabengröße (also case sensetive) betrachten?

Gruß, gucky[/code]