Ich hab noch nen Bug:
Wenn TS_CREATOR_ADD_RESIZING_BORDER aktiviert wird, stimmen die mit tsTextGetWidth / =tsTextGetHeight ermittelten Werte nicht mehr exakt.
Dazu im Anhang ein Bild, was dieses Verhalten zeigt: Oben ohne Resizing-Border, unten mit. Die Textbreite/-höhe wird ermittelt und mit glScissor genau auf den Bereich begrenzt. Mit dem Resizing-Border passts nicht mehr.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Tschuldige. Hat ein bisschen gedauert. Bin erst jetzt dazu gekommen mir das mal anzuschauen. Ja. So wie es scheint verändert sich die Position des Textes (2 Pixel nach Unten Rechts). Ist im 3D nur nicht aufgefallen. Ich werde schauen, dass ich das so schnell wie möglich gefixt bekomme. Kann dazu aber gerade nicht wirklich eine Angabe machen.
Ich hatte gerade den Gedanken, dass man ja um die ganze Geschichte einen Wrapper für Java machen könnte oder? Weil ich noch immer keine Vernünftige Methode gefundn habe, in Java Schriften darzustellen und das müsste doch so gehen... irgendwie hinkt JOGL da ziemlich hinterher
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Das sollte durchaus möglich sein. Denn Jogl bedient sich eigentlich auch nur einer externen DLL (vermute ich mal sehr stark). Und die biete ich ja auch direkt mit an. Ich habe nur leider überhaupt keine große Ahnung von Java. Sonst hätte ich das vermutlich selber schon irgendwann mal gemacht. Wobei da aktuell auch noch eine Unterstützung für FreeType fehlt bevor das sinnvoll nutzbar ist. SDL_ttf mag ich mittlerweile überhaupt nicht mehr.
Allerdings wenn ein Grundheader besteht und sich der Pflegeaufwand in Grenzen hält, dann kann man darüber verhandeln, ob ich den Header bei neuen Releases gleich mit pflege und direkt in den Packeten mit verteile. Der Name des Originalurhebers bleibt natürlich erhalten etc.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Was macht die Klasse denn so besonderes? Okay die ist nativ in Java implementiert. Damit würde man sich vielleicht ein (oder mehreren) DLLs ersparen. Allerdings würde ich jetzt mal spontan behaupten, denn meine Bibliothek vermutlich einiges mehr kann.
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7804 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Hi Philipp: Wir hatten ja den Textrenderer bei der JOGL_GUI schonmal auf dem Screen.
Was ich da aber noch so in Erinnerung habe ist, dass die Klasse selber nicht ausgereift war und Probleme gemacht hatte. Deshalb habe ich das damals nicht weiter verfolgt.
Falls jemand für die Textsuite einen JavaWrapper bauen könnte, wäre das super und sicherlich auch für die JOGL_GUI interessant.
Sinnvoll wäre das allerdings nur, wenn es nicht nur eine DLL sondern auch eine SO gäbe.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Hi Philipp: Wir hatten ja den Textrenderer bei der JOGL_GUI schonmal auf dem Screen. Was ich da aber noch so in Erinnerung habe ist, dass die Klasse selber nicht ausgereift war und Probleme gemacht hatte. Deshalb habe ich das damals nicht weiter verfolgt.
Ich weiss nicht, ob das auch dein Problem war Flash, aber ich vermute es einfach mal:
Der Textrenderer verfolgt ein Schema ala:
Code:
textRenderer.beginRender();
textRenderer.drawText(x,y,text);
textRenderer.endRenderer();
In Begin und End setzt er die Orthomatrix und setzt sie wieder zurück, setzt ein paar Flags. So weit so akzeptabel. Das Tödliche für eine Gui ist, dass er in beginRender() auch ein LoadIdentity ausführt. Wenn man also eine Gui baut, deren Items mit relativen Positionsangaben und den dazu korrelierten glTranslates arbeitet, zerhaut ein glLoadIdentity zwischendrin alles. Das Button wird also hübsch relativ zur Fensterposition gezeichnet (wenn man so weitsichtig war button.render() mit glPush und glPop zu umschließen), aber für das Label des Buttons ist alles verloren. Die Position des Windows (Parent des Buttons) hat überhauptkeinen Einfluss mehr auf das Label des Buttons und das zerhaut so ziemlich jeden Gui ansatz. Man kann da versuchen ein wenig mit rekursiven Positionsberechnungen herumzufrickeln, aber das ist erstens extrem unperformant und zweitens nur die Behelfslösung für einen fehlerhaft implementierten Textrenderer.
Das war das Problem am Textrenderer und soweit ich weiß, hat sich das noch immer nicht geändert...
Auch wenn es jetzt ein ganzes Jahr her ist: Ich bin gerade dabei einen Java Wrapper für TextSuite zu schreiben. Ich wusste garnicht, dass das hier im Thread angesprochen wurde.
Jetzt aber zu meiner Frage: Ich habe ein Problem mit der tsFontSetCharParameteri(WideChar, tsInt, tsInt);-Funktion. Nachdem ich bemerkt habe, dass die Java chars offenbar vollkommen inkompatibel mit den benötigten Typen sind (auch mit verschiedenen casts), habe ich einfach mal in meiner JNI-DLL ein paar Werte hardgecodet:
Ich bekomme aber jedes Mal beim Aufruf von tsGetError() den "invalid value"-Fehler zurück. Ich habe schon etliches probiert, rumgecastet wie blöd, Elemente von nullterminierten Strings, sogar schon normale Hex-Werte - aber nichts funktioniert. Im C++-Sample wird leider keine Funktion benutzt, die chars annimmt.
Gibts da eine spezielle Vorgehensweise, bzw. hat schonmal jemand getestet ob das wirklich funktioniert? Vielleicht gibt es ja irgendwelche Inkompatiblitäten bei C/C++ Characters und Delphi Characters.
Achja, als IDE/Compiler verwende ich MS Visual Studio 2010.
Ich hoffe jemand kann mir was genaueres dazu sagen
Edit:
Selbst wenn ich tsStringAnsiToWide() aufrufe und mir damit einen WideChar hole (was auch funktioniert), bekomm ich "invalid value" zurück.
Ok, ich habe noch ein paar Dinge ausprobiert, bin aber nur bedingt weiter gekommen.
Wenn ich mit tsPostAddCustom() einen Callback definiere und in diesem Callback dann tsFontSetCharParameteri aufrufe funktioniert alles wunderbar. Ich habe mich natürlich schon gefreut, dass ich die Lösung gefunden habe: Einfach diese Callback-Funktion selbst aufrufen und dann sollte es doch gehen, oder ?
War natürlich nicht der Fall und ich bekomme wieder den gleichen "invalid value"-Fehler. Offenbar steht der Fehler in zusammenhang mit der Aufrufkonvention von JNI. Das ist folgende:
Ich habe aber keine Ahnung, warum das funktioniert, wenn der Callback von libTextSuite.dll aufgerufen wird, aber nicht, wenn ich es aus der JNI-Funktion selbst tue.
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ich bin mal so dreist und verlinke einfach auf die Dokumentation von tsFontSetCharParameter. Von daher würde ich vermuten, dass du versuchst ein Buchstabe zu manipulieren der noch gar nicht erstellt wurde? Alternativ zu Char geht durchaus auch Word. Was nicht gehen dürfte ist ein AnsiChar. Also ein Byte. Zu mindest bei dieser Methode. Was die Javasachen angeht. Keine Ahnung.
So, nachdem dieses "Missgeschick" aus dem Weg geräumt war, habe ich ein bisschen weiter gemacht. Es sind bis auf drei, vier Funktionen alle implementiert und laufen - jedenfalls theoretisch.
Fonts erstellen und rendern funktioniert gut (Blockmodus noch nicht getestet), und man kann auch Postprocessing verwenden. Der Callback für den Postprocessor kann so verwendet werden:
Code:
TextSuite.tsPostAddCustom(new IPostProcessProc() { @Override public void execute(int ImageID, char CharCode, Object data) { int TempImageID = TextSuite.tsImageCreate(); TextSuite.tsImageAssignFrom(TempImageID, ImageID);
// fill with color TextSuite.tsImageFillColor3ub(TempImageID, 0xE0, 0xE0, 0xFF, TextSuite.TS_CHANNELS_RGB);
// original image will be the shadow so blur image ImageBlurArguments res = TextSuite.tsImageBlur(ImageID, 2, 8, TextSuite.TS_CHANNEL_ALPHA, true);
// fill with color TextSuite.tsImageFillColor3ub(ImageID, 0x00, 0x00, 0xFF, TextSuite.TS_CHANNELS_RGB);
// blend cloned original image over blured original TextSuite.tsImageBlend(ImageID, TempImageID, res.expandSizeX, res.expandSizeY + 5, true);
// the glyph rect has changed so get it IntBuffer buf = BufferUtils.createIntBuffer(4); TextSuite.tsFontGetCharParameteriv(CharCode, TextSuite.TS_CHAR_GLYPHRECT, buf);
int left = buf.get() + res.expandSizeX; int top = buf.get() + res.expandSizeY + 5; int right = buf.get() + res.expandSizeX; int bottom = buf.get() + res.expandSizeY + 5;
Ein paar Probleme gibt es allerdings noch. Und zwar ist es ja möglich mit tsImageGetData bzw. Scanline die Pixeldaten auszulesen und zu verändern. Das funktioniert mit Java aber leider nicht (ich habe bis jetzt jedenfalls keine Lösung gefunden).
Wenn ich keinen Workaround finde kann man es evtl. so machen, dass die Postprocessing-Callbacks auch in einer externen Library programmiert werden. Man könnte auch ein paar Extrafunktionen einbauen, mit denen man die Daten verändern kann. Beispielsweise tsImageModifyByte(ImageID, Position, Value), um das Byte an 'Position' mit 'Value' zu überschreiben. Das ist zwar sicher nicht performant, aber mir fällt im Moment nichts besseres ein.
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste
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.