Im Prinzip ist es vollkommen egal, im Moment mache ich es mit LWJGL. Ich nutze noch die BufferUtils-Klasse von LWJGL, aber das kann man sehr leicht selbst machen. Dann sollte es auch mit JOGL laufen.

Vielleicht kannst du da eine Art Factory schreiben, der man anfangs sagt welche Lib genutzt wird, und die das entsprechend umswitched.

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

Das Einzige was da wirklich spezifisch sein dürfe sind die Bufferklassen. Da ich gerne Pointer übergebe und die dann mit Daten befülle. Und Pointer sind ja so eine Sache mit Java. Eventuell gibt es ja auch einen Weg eine eigene Bufferklasse oder so etwas zu erstellen. Dann wäre man gar nicht mehr von einen der Beiden abhängig, denn die TextSuite könnte man theoretisch auch ohne OpenGL benutzen.

So etwas wie tsImageModifyByte finde ich nicht gut. Mit allen Sicherheitsabfragen etc macht die Benutzung keinen Spaß mehr und dann könnte man es eigentlich gleich lassen. Die Bibliothek hat aber eine sehr offene Lizenz. Also wenn jemand will dann viel spaß.

So meinte ich es auch. Das einzige, was ich von LWJGL nutze ist eine Klasse, die mir ByteBuffer.allocateDirect(size).order(ByteOrder.nativeOrder()).asIntBuffer() in BufferUtils.createIntBuffer(size) umwandelt. Das hat nichts mir einer OGL Lib zu tun, sondern ist halt nur eine nützliche Utilityklasse. Das ganze ist ansonsten komplett unabhängig von der verwendeten OGL Lib.

Eine tsImageModifyByte Funktion finde ich auch nicht gut, ich habe es nur mal angesprochen. Ich werde mal schauen, was sich da machen lässt.

Edit: Ich habe gerade eine vielversprechende Methode gefunden, die es erlaubt im nativen Code einen Java-ByteBuffer an einer speziellen Speicheradresse zu erstellen. Das teste ich mal - aber nichtmehr heute.

Das mit dem ByteBuffer war tatsächlich ganz unproblematisch. Ich kann in der Wrapper-Library einen ByteBuffer erstellen, der als Daten den Pointer von tsImageGetData() verwendet:

In Java kann ich jetzt ganz unkomplitziert die Daten verändern:


Das ihr auch seht, dass es funktioniert (natürlich ist das nicht das obige Code-Beispiel):

So, ich habe jetzt eigentlich alles implementiert. Getestet habe ich natürlich noch nicht alles, aber ich denke das meiste Funktioniert. Ein paar Dinge muss ich natürlich noch machen, trotzdem kann man schonmal ein bisschen damit rumspielen.

Wer es selbst schon mal ausprobieren möchte kann mir eine PN schreiben.

Ich kann euch eine erste Version des Java Wrappers anbieten.

In dem Package ist auch ein Sample für die Anbindung mit LWJGL dabei. Mit JOGL sollte es aber genauso funktionieren, wäre toll, wenn das mal jemand testet. Es sind noch ein paar ToDos da, und manche Sachen sind noch nicht richtig getestet. Trotzdem ist jede Funktion von TextSuite (theoretisch) verfügbar, inklusive SDL, GDI ect.

Leider bin ich noch nicht dazu gekommen die Wrapper-Libary unter Linux zu kompilieren. Ich habe im Moment auch kein Linux-System greifbar, deswegen kann ich euch das auch nicht in Aussicht stellen. Der Wrapper komplett plattformunabhängig, deswegen sollte er sowohl unter Windows, Linux, MaxOS, ect. funktionieren. Wenn jemand möchte kann er die Library dort gerne kompilieren.

Es wäre schön, wenn jemand mal ein bisschen damit rumspielen kann und mir ein wenig Feedback gibt. Viel Spass damit!

Schick, werd ich mir mal in nicht näher spezifizierter Zukunft anschauen

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich bin auch daran interessiert, komme aber wenig zum GL Coden z.Z. Deshalb nicht denken, dass es keine Interessenten gibt. Die Interessenten werden im Moment nur "aufgehalten".

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

Ich hätte daran Interesse, wobei ich auch nicht sagen kann, wann ich es dann konkret ausprobieren kann, da hier abseits des "Zielprojektes" im Leben gerade viel los ist.

Schön, dass sich ein paar dafür interessieren

Ich habe jedoch ein kleines Problem mit TextSuite unter Linux. Ich wollte schön meine C++ Wrapper-Library erstellen und dann mit Java laufen lassen. Das kompilieren ging gut ohne Fehler, nur in Java hab ich dann einen Fehler bekommen, von wegen tsInit() sei nicht referenziert. Ich habe dann mal ldd -d drüber laufen lassen, und bemerkt, dass das Linken mit TextSuite nicht funktioniert hat. Kann man überhaupt .lib-Dateien unter Linux verwenden? Eine .a-Datei habe ich nicht gefunden.

Hat jemand mal versucht TextSuite unter Linux mit C++ zu verwenden? Das C++ Linux Sample scheint nicht zu existieren (ist das gleiche wie unter Windows, keine ausführbare Datei, das Source-File benutzt windows.h).

Hey Lossy,

Da ich mit deinem Code generell recht gute Erfahrungen gemacht habe, wollt ich jetzt mal die TextSuite ausprobieren. Dazu eine Primärfrage: Kann die TextSuite irgendwie mit VBOs? Wenn nein, so wie ich das sehe müsste man ne Renderer-Klasse schreiben. Wie groß schätzt du den Aufwand dafür ein?

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also die TextSuite kann nicht mit VBOs umgehen. War zwar angedacht dass das irgendwann mal kommt. Aber na ja. Tu dir also keinen Zwang an. Den Aufwand schätze ich nicht so klein ein wie man das vermuten mag aber auch nicht übermäßig groß. Großteil liegt wohl in der Logik begraben. Den Nutzen schätze ich allerdings auch nicht so sonderlich groß ein. Denn ich denke der Großteil des Aufwandes geht beim Parsen drauf etc. Was bei mehr Verwaltung logisch auch nicht weniger wird. Der Renderer ist auch noch der Parser für Text. Ist nicht wirklich optimal. Besser wäre ein externer Parser der auch in der Lage wäre geparste Texte im Speicher zwischen zu speichern. Dann müsste man komplexe Texte nicht doppelt parsen.

Ansonsten ein neuer Renderer müsste es gar nicht werden. Eher ein Parameter des Renderes den man setzt der das steuert. Sollten VBOs nicht unterstützt werden hätte man direkt einen Fallback. Ein seperater Renderer hätte keine Texturdaten und würde dann auch nichts darstellen können. Der aktuelle enthält außerdem den Textur/Speichermanager. Derzeit wird auch nur in einer einzigen Methode (TtsRendererOpenGL.DrawChar) gezichnet. Diese ist auch so konzipiert, dass nur mit absoluten Werten gezeichnet wird. Also das könnte man nehmen und in ein VBO packen.

Problem. Die Zeichen können wild über Texturen verstreut liegen. Also musst du immer schön überprüfen in welcher Textur man sich gerade befindet und gegebenfalls das VBO zeichnen. Indexbuffer wäre da wohl nur semisinnvoll. Die Zeichen sind Quads und es würden nur jeweils 2 Punkte doppelt benutzt werden. Wenn die Reihenfolge der Zeichen nicht zwangsweise vorrausgesetzt wird, dann könnte man die auch Texturweise gruppieren und anschließend zeichen. Wobei anschließend auch so eine Sache ist. Entweder wäre man im Blockmodus oder bei den einzeiligen Ausgaben nur innerhalb eines tsTextOut. Alles was außerhalb geschieht kann man nicht mehr kontrollieren. Es sei denn man würde da noch etwas ranbasteln um so etwas zu gruppieren. Aber davon halte ich nicht viel.

PS: Nicht zu vergessen. Die Farbe müsste logisch auch mit in das VBO.

I see. Das Ding ist, natürlich, die Brücke zu OpenGL 3 bei einem neuen Projekt nicht gleich wegzusprengen. Geht also weniger um Performance...

grüße

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hm, ich hab so eine VBO-Font geschrieben, weil ich im letzten Jahr alles auf VBO+Shader+OpenGL3-Fähigkeit umgestellt hab. Bin noch nicht fertig, ich stecke noch mitten in der Matrizen-Umstellung . Für die Font habe ich lange rumgesucht, da gabs nicht wirklich viel im Netz zu finden. Was rausgekommen ist, ist nichts weiter als meine alte Freetype-Font in neuer Ausstattung. Die Features sind die gleichen: Texture Font mit proportional Spacing (kein Kerning!), verschiedene Farben möglich, auf Basis von Wide Chars und 8859 Code-Pages, also so etwas wie Kyrillisch geht auch. Das wars schon.