TextSuite will nicht

[EWeiss]

Kann ich in TextSuite auf die gleiche art und weise wie mit

Delphi-Quellcode:

glPrintBitmap(10, PlaystateYPos, SongName, 1);

Text ausgeben ?

Scheinbar nicht denn es wird nichts gerendert.
Habe mir mal das Sample SingleLine angeschaut dieses bassiert aber auf 'glOrtho'
Ich verwende aber 'gluPerspective'

mit kleinen änderungen wird mir der Text im Sample angezeigt aber auf den Kopf und nicht an der position wie ich sie gerne hätte.
Edit;
na gut das geht mit glScalef(1, -1, 1) dann stehts nicht auf den Kopf

In meinen Code geht gar nichts. :roll:
Ich benötige diese wegen UniCode da bei Bitmaps einige zeichen Fehlen und das ändern auf andere Sprachen zu aufwendig ist.

Delphi-Quellcode:

// setting color or with glColor
tsTextColor3f(1, 1, 1);
glEnable(GL_BLEND);

// activate large font
tsFontBind(fLargeFontID);

begin
  // set align to left
  tsSetParameteri(TS_ALIGN, TS_ALIGN_LEFT);
  glPushMatrix;
    glTranslatef(0, 0, 0);
    tsTextOutA(SongName);
  glPopMatrix;
  //glPrintBitmap(10, PlaystateYPos, SongName, 1);
end;

werd da irgendwie nicht schlau draus..
Die Initialisierung ist ok nur das rendern will nicht.
Denke ein ViewPort problem.

Delphi-Quellcode:

glTranslatef(0, 0, 0);

soll eingentlich diese werte enthalten

Delphi-Quellcode:

glTranslatef(10, PlaystateYPos, 0);

habe sie auf 0 gesetzt zum testen will aber nicht. :wall:

gruss Emil

[Lossy eX]

Evtl solltest du auch noch erwähnen um was es sich handelt bzw einen Link darauf. Denn noch ist die Bibliothek recht unbekannt. ;)

Mit der Version die ich auf meinem Rechner habe wird das Zeichnen einfacher, denn dann entfällt glPushMatrix und glPopMatrix. Allerdings ganz so einfach wie glPrintBitmap wird es nie werde, denn mein Augenmerk liegt auf Flexibilität und möglichst wenigs Einschränkungen.

Zu deinem Problem. Es handelt sich bei den Buchstaben um simple Quads. Aber Quads mit Größen von bis zu 20-25 OpenGL Einheiten. Das musst du beim Zeichnen berücksichtigen. sowohl in Position als auch in der Größe. Obendrein kommt hinzu, dass Bitmapfonts direkt in den Framebuffer gezeichnet werden wärend die Quads aus der TextSuite aber 3D sind. Ich würde empfehlen, wenn du 2D Schrift haben willst, dann solltest du vorher mit glOrtho in den 2D Modus wechseln. Und dann musst du auf die passende Einheiten achten. Wie in den Beispielen.

Im Zweifel bitte Fehler überprüfen. Dazu ist tsGetError und tsGetErrorFunction gut. Aber einige Teile der Hilfe sind noch nicht geschrieben bzw. werden noch umgebaut. Lokal bei mir.

[EWeiss]

@Lossy

Zitat:

Evtl solltest du auch noch erwähnen um was es sich handelt bzw einen Link darauf. Denn noch ist die Bibliothek recht unbekannt.

Ja hätte ich tun sollen ;)

Ist klar das es nicht so einfach wie glPrintBitmap ist.
Das ist auch mein problem.

Mein problem
Ich möchte wie bei glPrintBitmap die x und y position zur 'gluPerspective' erhalten
bedeutet dass ich muss erst in den 'glOrtho' modus schalten und dann wieder zurück
so wie bei glPrintBitmap ?

Dachte ein einaches

Delphi-Quellcode:

glTranslatef(10, PlaystateYPos, 0);
tsTextOutA(SongName);

würde reichen scheint aber nicht so zu sein.. muss dann wohl noch selbst in
'glOrtho' wechseln um die Positionen zu setzen

Habe mit deinen SimpleLine example experimentiert aber die zeile hat sich
nie auf die von mir angegebene position gesetzt.

Vielleicht bin ich auch zu doof dafür ;)

EDIT:
Damit das hier

Delphi-Quellcode:

glTranslatef(10, PlaystateYPos, 0);
tsTextOutA(SongName);

überhaupt funktioniert mache ich jetzt folgendes

Beide Funktionen kapsel ich in eine extra procedure.

Delphi-Quellcode:

procedure glPrintXY(x, y : GLFloat; fWidth, fHeight: GLFloat; text : pchar; fontset : tsFontID; Textalign: Integer);

begin
  tsFontBind(fontset);
  glDisable(GL_DEPTH_TEST);                                // Disables Depth Testing
  glMatrixMode(GL_PROJECTION);                            // Select The Projection Matrix
  glPushMatrix();                                           // Store The Projection Matrix
  glLoadIdentity();                                         // Reset The Projection Matrix
  glOrtho(0,640,0,480,-100,100);
  glMatrixMode(GL_MODELVIEW);                             // Select The Modelview Matrix
  glPushMatrix();                                           // Store The Modelview Matrix
  glLoadIdentity();                                         // Reset The Modelview Matrix
  glTranslated(x, y, 0);                                   // Position The Text (0,0 - Bottom Left)
  glScalef(1, -1, 1);
  tsSetParameteri(TS_ALIGN, Textalign);
  tsTextOutA(text);
  glMatrixMode(GL_PROJECTION);                            // Select The Projection Matrix
  glPopMatrix();                                           // Restore The Old Projection Matrix
  glMatrixMode(GL_MODELVIEW);                              // Select The Modelview Matrix
  glPopMatrix();                                           // Restore The Old Projection Matrix
  glEnable(GL_DEPTH_TEST);                                // Enables Depth Testing

end;

und rufe sie hier auf

Delphi-Quellcode:

procedure TMainForm.FormPaint(Sender: TObject);
begin
  glClear(GL_COLOR_BUFFER_BIT);

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity;
  gluPerspective(45, ClientWidth / ClientHeight, 4, 256);
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;

  // setting color or with glColor
  tsTextColor3f(1, 1, 1);

  glPrintXY(15,
            13,
            ClientWidth,
            ClientHeight,
            'TextSuite Sample - Single Line',
            fLargeFontID,
            TS_ALIGN_LEFT);

  // Check for Errors
  CheckError;

  SwapBuffers(fDC);
end;

Delphi-Quellcode:

procedure TMainForm.FormResize(Sender: TObject);
begin
  if fInitialized then begin

    ReSizeGLScene(ClientWidth , ClientHeight);
    FormPaint(Self);
  end;
end;

Delphi-Quellcode:

procedure ReSizeGLScene(glsWidth : GLsizei; glsHeight: GLsizei);
begin
    If glsHeight = 0 Then                     // Prevent A Divide By Zero By
        glsHeight := 1;                       // Making Height Equal One

    glViewport(0, 0, glsWidth, glsHeight);    // Reset The Current Viewport
    glMatrixMode(GL_PROJECTION);              // Select The Projection Matrix
    glLoadIdentity;                           // Reset The Projection Matrix
    gluPerspective(45, glsWidth / glsHeight, 1, 1000.0);
    glMatrixMode(GL_MODELVIEW);                // Select The Modelview Matrix
    glLoadIdentity;                            // Reset The Modelview Matrix

End;

Frage mich jetzt nur warum ich so einen umweg machen muss um den Text zu positionieren
Welchen vorteil hat dann die TextSuite wenn es nur so umständlich geht ?

Der gerenderte Text ist auch unansehnlich.
Oder was mache ich falsch das es so ist.

In 320x240 sieht man gar nichts obwohl der Font eine größe von 14 hat.
In 1280 ist zu groß und total unansehnlich.

gruss Emil

[Lossy eX]

Zitat:

Ich möchte wie bei glPrintBitmap die x und y position zur 'gluPerspective' erhalten bedeutet dass ich muss erst in den 'glOrtho' modus schalten und dann wieder zurück so wie bei glPrintBitmap ?

Nein. Ich mache das nicht. Werde ich auch nicht, denn das Ortho ist abhängig von Fenster was ich nicht wissen kann und es kostet Zeit. Mitunter sogar reichlich. Von daher solltest auch du das Pro gezeichnetem Frame auch nur ein einziges mal machen.

Aber wie gesagt. Stell dir die Zeichen als ganz normale Quads vor die an Stelle 0, 0, 0 gezeichnet werden. Wenn du dort ein Quad hinmalst wo der Text hin soll und es nicht erscheint ist was falsch. Ist es da sollte es richtig sein. Und immer auf Fehler prüfen. Hab ich geschrieben. Wenn irgendwas nicht stimmt mache ich nichts. Bzw setze nur einen Fehler. Evtl auch mal culling deaktivieren.

PS: Mag sein, dass es alles etwas kompliziert erscheint aber ich denke es hat durchaus seinen Sinn. Bzw das ein oder andere ist ja auch noch in arbeit um es einfacher zu machen.

Zitat:

Frage mich jetzt nur warum ich so einen umweg machen muss um den Text zu positionieren

Nichts für ungut aber so wie du das machst ist das bähhhh. Aber richtig. Habe ich oben geschrieben. Du setzt zu viele States und musst sie ständig wieder zurücksetzen. Schau dir die Beispiele an die in dem Packet dabei sein. Da setze ich nur die allernötigsten States. Und du solltest bei dir eine ganz klare Trennung zwischen Perspective und Ortho machen.

Zitat:

Der gerenderte Text ist auch unansehnlich.
Oder was mache ich falsch das es so ist.

Dazu kann ich nur ganz klar sagen JA. DU machst etwas falsch. Die Bibliothek ist in erster Linie auf Pixelgenaues zeichnen ausgelegt und glaube mir. Ich habe darauf geachtet! Mit glOrtho stellst du auch eine "Auflösung" ein. Und diese Einheiten sollten 1:1 sein, wenn du Pixelgenau arbeiten willst. Dann sieht der Text auch richtig aus. Wenn du die tatsächliche Auflösung doppelt so groß einstellst wie die OpenGL Einheit ist, dann wird ALLES auch doppelt si groß. Auch die Schrift und da kann die Bibliothek ja nichts dafür, oder?

[EWeiss]

Zitat:

Nein. Ich mache das nicht. Werde ich auch nicht, denn das Ortho ist abhängig von Fenster was ich nicht wissen kann und es kostet Zeit. Mitunter sogar reichlich. Von daher solltest auch du das Pro gezeichnetem Frame auch nur ein einziges mal machen.

Na ja so einfach ist es nicht.
Kann es über eine Variable regeln und nur neu zeichnen wenn sich diese ändert
Aber selbst dann komme ich nicht drumherum sie mehrmals aufzurufen zum beispiel wenn das Window in der größe verändert wird.

Zitat:

Dazu kann ich nur ganz klar sagen JA. DU machst etwas falsch.

Deshalb meine Frage mit der anmerkung ob ich etwas falsch mache.
Denn wenn ich die Bibliothek (vorschaubilder) ansehe sieht das fantastisch aus.
Keine frage ;)

Zitat:

Nichts für ungut aber so wie du das machst ist das bähhhh. Aber richtig. Habe ich oben geschrieben. Du setzt zu viele States und musst sie ständig wieder zurücksetzen. Schau dir die Beispiele an die in dem Packet dabei sein. Da setze ich nur die allernötigsten States. Und du solltest bei dir eine ganz klare Trennung zwischen Perspective und Ortho machen.

Daraus ersehe ich das es richtig ist.. oder was meinst mit bähhhh ;)

Zitat:

Wenn du die tatsächliche Auflösung doppelt so groß einstellst wie die OpenGL Einheit ist, dann wird ALLES auch doppelt si groß. Auch die Schrift und da kann die Bibliothek ja nichts dafür, oder?

ja in glPrintXY habe ich eine andere auflösung

Delphi-Quellcode:

glOrtho(0,640,0,480,-100,100);

würde ich diese auf die reale größe des Window einstellen

Delphi-Quellcode:

glOrtho(0,fWidth,0,fHeight,-100,100);

dann verändert sich der text in der größe nicht.

Habe das Sample mal hochgeladen ..
Wenn du zeit findest kannst du es dir mal bitte anschauen.

gruss Emil

[Lossy eX]

Zitat:

Daraus ersehe ich das es richtig ist.. oder was meinst mit bähhhh :wink:

Okay. So im nachhinein muss ich gestehen war das etwas unglücklich formuliert. Ich meinte, dass es richtig bähh ist. ;) Denn du hast ziemlich viele Matrixoperationen die vermutlich alle gar nicht nötig sind. Und um mal eine Hausmarke zu nennen. Vor 2-3 Jahren hatte ich mal was gemessen. In einer 3D Anwendung dann ein Mal in den Orthomodus gewechselt und wieder zurück. Sonst nichts. Und die FPS ging um ca. 10% runter. Keine Ahnung ob sich das heute noch genau so verhält aber ich denke ja.

Auch nicht vergessen solltest du, dass du noch eine GUI haben willst und wenn du noch 1-2 weitere Texte ausgeben willst, dann wechselst du mal eben locker flockig 4 Mal zwischen den Ansichten. Aber genau genommen würde auch folgendes ausreichen. Das ist jetzt auch ein Stück aus dem Anhang.

Delphi-Quellcode:

procedure TMainForm.FormPaint(Sender: TObject);
begin
  // Hier setzt du die Perspektive
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity;
  gluPerspective(45, ClientWidth / ClientHeight,  1, 1000.0);
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;

  // Hier rufst du deine Visualisierung auf.
  ...

  // Hier ortho
  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();
  glOrtho(0,fWidth,0,fHeight,-100,100);
  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity();

  // Text ausgeben
  glPushMatrix;  // leider in der version noch nötig aber ab der echten 0.8 nicht mehr
    glTranslate(...);
    tsTextOutA('Blahh');
  glPopMatrix;  // leider noch

  // Text ausgeben

  // Gui zeichnen

  CheckError;
  SwapBuffers(fDC);
end;

Damit kommst du mit einem einzigen glOrtho aus. Und warum funktioniert das genau so? Weil du zu Begin des Zeichnens IMMER die Perspektive setzt. Wenn alles 3D fertig gezeichnet ist kannst du die Ansicht auf 2D umstellen. Aber du brauchst sie nicht speichern und wieder zurücksetzen. Warum auch? Bei nächsten Frame setzt du sie ja sowieso wieder. So wie es in dem Anhang ist funktioniert das sicherlich auch. Allerdings machst du viel viel mehr als überhaupt nötig ist. Du sicherst Dinge und stellst sie wieder her obwohl sie gar nicht mehr benutzt werden. Und mit jedem Text steigt der Aufwand.

Ich hoffe ich konnte es damit etwas besser verdeutlichen.

Zitat:

dann verändert sich der text in der größe nicht.

Mal anders gefragt. Was genau hast du vor? Der Text soll proportional zur Größe des Fensters bleiben? Das ist nicht ganz so einfach. Bzw kann man dort sehr schnell grafische Mängel bekommen. Denn bei dem Text handelt es sich um Texturen ohne MipMapping. Und das verhält sich wie jede andere Textur auch. Wird sie größer dargestellt wird sie weich und sieht mitunter nicht mehr so scharf aus. Wird sie kleiner dargestellt, dann liegen einige Texel auf dem selben Pixel und OpenGL nimmt dann irgendeines.

Obendrein kommt noch die Art meines Zeichnens hinzu. Diese ist für pixelgenaue Darstellung ausgelegt und bei Vergrößerungen kann es passieren, dass die Interpolation von OpenGL abgeschnitten wird bzw die Zeichen teilweise ineinander fließen. Aber das könnte man bei einfachen Texten mit einem kleinen Trick umgehen.

Ich sage nicht, dass es unmöglich ist. Sondern, dass es mit gewissen Risiken verbunden ist. Bzw in diesem Fall mit grafischen Einschränkungen. Denn es sieht nur wirklich richtig gut aus, wenn man Pixelgenau arbeitet. Und das ist nicht nur auf die Font Bibliothek beschränkt sondern ein generelles Problem. Deswegen wäre es vermutlich praktisch, wenn du mal genau sagst was du eigentlich damit vor hast.


PS: Im übrigen ist die Größe 14 nicht vergleichbar mit der Schriftgröße 14 innerhalb von Windows. Dazu müsste dieser Wert von logischen Pixeln auf die aktuellen DPI gerechnet werden.

[EWeiss]

Gut dann erkläre ich es nochmal ganz kurz
Zwei Bilder im Anhang ..

Wie du unten bei den Songnamen und der Zeit sehen kannst verwende ich ein FontBitmap
um die Texte auszugeben.
Bei beiden bildern kann man den Text noch erkennen.

Mein problem ist aber das man damit keine anderen Sprachen darstellen kann
da der Fontsatz innerhalb des Bitmap auf englisch ausgelegt ist.

Dazu möchte ich die TextSuite verwenden damit das möglich ist.
Die Bitmaps verändern sich ja auch proportional zur größe des Fensters.
Ja ich weiss das sind Bitmaps und kein text ;)

gruss Emil

[Lossy eX]

Da gibt es 2 Möglichkeiten. Entweder du setzt die Größe mit glOrtho auf einen fixen Wert (640x480). Wobei ich da aber noch auf das Seitenverhältniss achten würde. Da musst du dann aber mal testen welche Schriftgröße sich anbietet. 14 find ich zu wenig. Eher so etwas wie 21. Aber wenn die Schrift vergrößert werden muss wird es matschig. Oder wenn sie verkleinert wird dann wird sie pixelig. Das hast du bei deiner SchriftTextur jetzt auch schon. Je nach Größe und Font kommt das aber unterschiedlich stark zur Geltung.

Dann solltest du nach dem Erstellen des Fonts aber noch ein paar postprocesor hinzufügen. Die sind eigentlich nicht dafür gedacht aber sollte auch gehen.

Delphi-Quellcode:

  tsFontCreateCreator(...)
tsPostAddBorder4f(1, 1, 1, 1, 1, 0);
tsPostAddFillColor3f(1, 1, 1, TS_CHANNELS_RGB);

Die sorgen dafür, dass zwischen den Zeichen mehr Platz ist und dass der RGB Wert weiß ist. Sonst können am Rand leichte schwarze Streifen entstehen, wenn die Schrift vergrößert wird. Bzw Rundungen wären abgeschnitten. Gegen das Verkleinerungsproblem gibt es nichts.

Oder Alternativ setzt du die Schriftgröße ins Verhältniss und benutzt für glOrtho die Größe des Viewports. Sollte sich das Fenster in der Größe verändern, dann erstellst du es im Verhältniss kleiner oder größer. Dann wäre das bei Größenveränderungen zwar nicht 100%tig gleichmäßig aber die Schrift immer Pixelgenau und entsprechend gut lesbar. Denn das Fenster wird man normal nicht immer größer und kleiner machen. Ich persönlich würde da wohl die sauberere Schrift vorziehen. Aber diese Entscheidung liegt bei dir.

[EWeiss]

Danke für den Tip mit den Border..

Zitat:

Ich persönlich würde da wohl die sauberere Schrift vorziehen. Aber diese Entscheidung liegt bei dir.

Auf jedenfall eine saubere Schrift.

das Sample sieht jetzt schon mal besser aus.

Delphi-Quellcode:

procedure glPrintXY(x, y : GLFloat;
                    fWidth,
                    fHeight : GLFloat;
                    text    : pchar;
                    fontset : tsFontID; Textalign: Integer);

begin

  tsTextColor3f(1, 1, 1);
  tsFontBind(fontset);
  tsSetParameteri(TS_ALIGN, Textalign);

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity(); 
  glOrtho(0,fWidth,0,fHeight,-100,100); 
  glMatrixMode(GL_MODELVIEW); 
  glLoadIdentity();

  glPushMatrix();
    glTranslated(x, y, 0);
    glScalef(1, -1, 1);
    tsTextOutA(text);
  glPopMatrix();

end;


procedure TMainForm.FormPaint(Sender: TObject);
begin

  glClear(GL_COLOR_BUFFER_BIT);

  glMatrixMode(GL_PROJECTION); 
  glLoadIdentity; 
  gluPerspective(45, ClientWidth / ClientHeight,  1, 1000.0); 
  glMatrixMode(GL_MODELVIEW); 
  glLoadIdentity;

  glPrintXY(15,
            13,
            Width,
            Height,
            'TextSuite Sample - Single Line',
            fLargeFontID,
            TS_ALIGN_LEFT);

  // Check for Errors
  CheckError;

  SwapBuffers(fDC);
end;

Kommt natürlich auch auf den Font an den man benutzt
Habe zum testen mal cyberbit.ttf genommen .. geht aber nicht als standard 12MB für einen Font ist schon arg ;)

Sample Ok kann ich gut mit leben
Vis unidentifizierbare Blöcke von irgendwas
Da ist arg was daneben.
EDIT:
openGL error 1282

Bilder im Anhang

gruss Emil

[Lossy eX]

Bei glPrintXY bitte ClientWidth und ClientHeight angeben. Das ist wichtig.

Der Fehler ist GL_INVALID_OPERATION. Da kann ich dir nichts sagen, da ich keinen Code sehe. Musste mal forschen was seit dem letzten mal passiert ist. Ich hätte jetzt auf deaktiviertem Blending getippt. Kann aber auch sein, dass du tsTextOutA in einem Bereich aufrufst wo das nicht erlaubt ist. Denn der erstellt beim ersten Aufruf eine Textur. Weil er Platz für die Zeichen braucht. Wenn das nicht geht kann das auch dazu führen.

Font: Du musst nicht unbedingt eines mit ausliefern. Du kannst die Bibliothek auch anweisen ein Font mit einem Namen zu benutzen. Wie das im Windows auch üblich ist. Also den Parameter TS_CREATOR auf TS_CREATOR_GDI_FACENAME und bei tsFontCreateCreator bei "filename", dann 'Arial' übergeben.

Aber eine kleine Warnung. Aktuell gibt es noch keine Möglichkeit fehlende Zeichen ausgleichen zu können. Der FireFox ist zum Beispiel in der Lage, bei einem Zeichen was in dem aktuellen Font nicht enthalten ist, sich dann in anderen Fonts zu bedienen. Mit anderen Worten. Das Dustimo Font ist zwar sehr schön und klein. Aber es enthält "nur" 373 Glyphen. Was aber schon viel mehr ist als andere freie Fonts bieten. Wenn du jetzt asiatische Zeichen damit darstellen wollen würdest, dann würde das nicht funktionieren, da du ausschließlich nur die in dem Font enthaltenen Zeichen zur Verfügung hast.

PS: Die benötigten Zeichen bleiben im übrigen auch so lange im Speicher der Grafikkarte bis sie gelöscht werden. Es könnte also von Zeit zu Zeit nicht unpraktisch sein mal die Zeichen zu löschen. Wobei ich gesehen habe, dass ich da vermutlich sogar noch nen Speicherleck habe. Das einfachste. Font löschen und neu erstellen dann sind sie in jedem Fall weg. Denn wenn du asitische Zeichen hast, dann gibts genügend Auswahl. Aber bei 10-15 Buchstaben pro Lied könnte das Stunden der Visualisierungen bedeuten um evtl. leicht etwas zu verbrauchen. Das dürfte vermutlich so nicht mal auffallen.

[EWeiss]

Zitat:

Der Fehler ist GL_INVALID_OPERATION. Da kann ich dir nichts sagen, da ich keinen Code sehe. Musste mal forschen was seit dem letzten mal passiert ist. Ich hätte jetzt auf deaktiviertem Blending getippt. Kann aber auch sein, dass du tsTextOutA in einem Bereich aufrufst wo das nicht erlaubt ist. Denn der erstellt beim ersten Aufruf eine Textur. Weil er Platz für die Zeichen braucht. Wenn das nicht geht kann das auch dazu führen.

Wo soll ich es denn sonst aufrufen als in der Render procedure
Eine andere möglichkeit sehe ich da nicht.
Der einzigste unterschied ist doch zu deiner ausführung vom Sample
das ich über eine procedure gehe damit meine Render procedure nicht zu unübersichtlich wird.

Versteh das nicht :wall:
Im Sample gehts in der vis sehe ich nur Quader anstelle der Buchstaben.

EDIT:
Grrrr... konnte nicht gehn :wall: :wall: :wall: :mrgreen:
Für Bitmaps reicht ein glEnable(GL_BLEND);
Bei der TextSuite wohl nicht.
Mußte also noch die glBlendfunc addieren.

Delphi-Quellcode:

glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
glEnable(GL_BLEND);

gruss Emil

[Lossy eX]

Bitmaps: Wenn es normale Bitmaps sind. Also wie die klassischen Bitmapfonts. Dann sollte es eigentlich auch ohne Blending gehen. Und für Texturen sollte man die blendfunc immer angeben.

[EWeiss]

Zitat:

Zitat von Lossy eX

Bitmaps: Wenn es normale Bitmaps sind. Also wie die klassischen Bitmapfonts. Dann sollte es eigentlich auch ohne Blending gehen. Und für Texturen sollte man die blendfunc immer angeben.

Wieder was dazu gelernt.. ;)
dann noch eine frage denke das es dann soweit funktioniert.

kann es sein das hier noch was fehlt ?

Delphi-Quellcode:

  tsPostAddBorder4f(1, 1, 1, 1, 1, 0);
  tsPostAddFillColor3f(1, 1, 1, TS_CHANNELS_RGB);

ohne werden die buchstaben richtig angezeigt
mit werden diese überlagert .. abgeschnitten.

Habe es mal mit einer anderen glBlendFunc versucht dann habe ich aber wieder blöcke anstelle der Buchstaben.

Delphi-Quellcode:

glBlendFunc(GL_SRC_COLOR, GL_ONE_MINUS_SRC_COLOR);

EDIT:
noch ein bild

EDIT2:
Noch zwei Bilder addiert
Unbenannt.jpg kleine Font Fehler ..
Und da kannst sehn warum ich nach deiner komponente gefragt hatte ;)
klein.jpg da geht das mit dem Font.

gruss Emil

[EWeiss]

Noch eine frage bzgl. TextBlock

Delphi-Quellcode:

//** HELP SCREEN
procedure GLHelpScreen();
begin

  glTranslatef(0, 0, -100);
  glScalef(1, -1, 1);

  glScalef(0.1, 0.1, 0.1);
  glTranslatef(-520, -400, 0);

  // set align to center
  tsTextColor3f(1, 1, 1);
  tsSetParameteri(TS_ALIGN, TS_ALIGN_BLOCK);
  tsSetParameteri(TS_VALIGN, TS_VALIGN_TOP);

  glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
  glEnable(GL_BLEND);

  tsTextBeginBlock(20, 20, 760, 560, TS_BLOCKFLAG_WORD_WRAP);
    tsFontBind(fHelpFontID);
    tsTextOutA('KEY - COMMAND'#13#10);
    tsTextOutA('--------------------------------------- '#13#10);
    tsTextOutA('F1        : This Helpscreen'#13#10);
    tsTextOutA('ESC       : Exit FullScreen'#13#10);
    tsTextOutA('Space     : Colorswitch on/off '#13#10);
    tsTextOutA('+         : Set Color'#13#10);
    tsTextOutA('P         : Polygone on/off'#13#10);
    tsTextOutA('Left      : Previous Title'#13#10);
    tsTextOutA('Right     : Next Title'#13#10);
    tsTextOutA('Up        : Decrease Volume'#13#10);
    tsTextOutA('Down      : Increase Volume');
  tsTextEndBlock;

  glDisable(GL_BLEND);
end;

Hier ist alles schön aufgeräumt
Beim rendern wird jedoch alles vor dem Doppelpunkt verschoben
Wie kann ich das verhindern ?

Wieder ein Pic zur vorschau des Fehlers
gruss Emil

[Lossy eX]

Blockmodus: Ganz klar. Du hast in deinem Editor eine Monospace Schrift. Dort haben alle Zeichen die gleiche Breite. Mit der TextSuite aber nicht. Entsprechend ist das Leerzeichen schmaler als andere Zeichen.

Unbekannt.jpg: Ja diese kleinen Linien meinte ich mit mit den Fehlern. Und dafür war auch der Code. Warum der allerdings woanders so komisch wirkt ist mir ein Rätsel. Zur Not spiel mal mit mit den Parametern rum. Mach mal einen echten Schatten testweise. Teste auch mal eine andere Schrift und evtl. eine andere größe.

[edit] Und nö. So recht seh ich das nicht. Das sind doch alles englische Buchstaben. ;)

[EWeiss]

Zitat:

Blockmodus: Ganz klar. Du hast in deinem Editor eine Monospace Schrift. Dort haben alle Zeichen die gleiche Breite. Mit der TextSuite aber nicht. Entsprechend ist das Leerzeichen schmaler als andere Zeichen.

Ja den benutze ich ja ;)
Nur wie kann ich erreichen das der Formatierte Block auch so angezeigt wird.

EDIT:
Denke mal das kann man nicht fixen daher verwende ich für die Hilfe lieber wieder BitmapFonts
und verwerfe das mit dem TextBlock.

Zitat:

[edit] Und nö. So recht seh ich das nicht. Das sind doch alles englische Buchstaben.

Ich meinte das Info Window nicht die Schrift(TextSuite)

gruss Emil

[EWeiss]

Also hier bei mir läuft nun alles
Habe aber gesehen das es auf einen koreanischen System nicht geht.

Woran könnte das liegen und kann ich das überhaupt fixen ?

gruss Emil

[Lossy eX]

Zitat:

Zitat von EWeiss

Zitat:

Blockmodus: Ganz klar. Du hast in deinem Editor eine Monospace Schrift. Dort haben alle Zeichen die gleiche Breite. Mit der TextSuite aber nicht. Entsprechend ist das Leerzeichen schmaler als andere Zeichen.

Ja den benutze ich ja ;)
Nur wie kann ich erreichen das der Formatierte Block auch so angezeigt wird.

Du musst in deinem Programm auch eine Monospace (oder Fixed Width/Pitch) Schriftart benutzen. Bei der haben alle Zeichen die gleiche Breite! Sieht man bei dir schön am Wort "Title" dass es nicht so ist, denn der Buchstabe "T" ist genau so breit wie "it". Wenn du in der IDE eine andere Schrift benutzen würdest wäre es auch nicht richtig. Du brauchst dann halt noch ein Font wie zum Beispiel "Courier New". Das musst du dann zum Darstellen deines Hilfeblockes benutzen. Das Mischen von 2 Fontbibliotheken halte ich eher für keine gute Idee. Denn bei meiner Bibliothek ist so etwas auch problemlos möglich und die Zeichen aller Fonts wandern in die gleiche Textur. Oder auch mehrere Texturen falls nötig. Abgesehen davon hast du dann keine 2 unterschiedlichen Codes. Aber ich bin da evtl. auch nicht ganz unparteiisch. ;)

Ich habe für später auch noch geplannt Tabulatoren zu unterstützen, damit so etwas auch bei allen anderen Schriften möglich ist. Aber da habe ich vorher noch genügend andere Dinge zu erledigen. Weswegen du darauf vermutlich nicht warten solltest.

Zitat:

Woran könnte das liegen und kann ich das überhaupt fixen?

Man kann alles beheben. Man muss nur erst mal herrausfinden wo das eigentliche Problem liegt. Und da du die Ansi Variante von tsTextOut benutzt habe ich da so eine Theorie.

Ansi hat nur 1 Byte pro Zeichen und kann somit nur 256 Werte annehmen. Deswegen wurden Codepages eingeführt. Diese bieten für unterschiedliche Gebietsschemen unterschiedliche Belegungen der 256 Werte. Per Default ist in der TextSuite Latin-1 (Westeuropäisch) eingestellt. Um wirklichen Unicode support zu bekommen solltest du aber keine Codepages benutzen sondern du solltest entweder mit WideStrings oder UTF-8 arbeiten. Dann hat jedes Zeichen einen eigenen Wert. Und du kannst auch koreanisch, japanisch, russisch und tai direkt mischen. UTF-8 ist da eine spezielle Codierung. Die läuft in der TextSuite über eine pseudo Codepage und die Ansi Funktionen. Ist aber trotzdem in der Lage Zeichen mit bis zu 24 Bit zu speichern. Was mehr als ausreichend ist.

Es gibt auch eine Variante von tsTextOut die direkt mit WideStrings (2 Byte pro Zeichen) klar kommt. Die Windowsapi arbeitet direkt mit Widestrings. Dann musst du aber darauf achten, dass du überall auch mit WideStrings arbeitest. Sonst gehen dir die Zeichen vorher schon verlohren. Und meine Bibliothek kann ja nur das darstellen was da auch ankommt. Im Web bzw. bei Dateien kommt aber eher UTF-8 zum Einsatz. Musst du entscheiden was du da lieber benutzen willst. Im Zweifel kann man es immer irgendwie konvertieren.

[EWeiss]

Zitat:

Es gibt auch eine Variante von tsTextOut die direkt mit WideStrings

Du meinst also wenn ich das richtig verstehe
anstatt SongName: string; diesen als Widestring zu deklarieren ?
Das sollte dann reichen ?

Meine vermutung ist eine etwas andere
das es nicht am Fontset sondern am Charset liegt oder ist es das was du mit
Widestring korrigieren willst ? 2 byte.

Was ich meine ....
Anstelle von {ANSI_CHARSET} OEM_CHARSET zu verwenden hätte dann aber nichts mit Widestring zu tun
oder geht das nur wenn beides zusammen arbeitet ?

Kann es ja nicht testen hab kein koreanisches System

Kannst du mir ein Beispiel zeigen wie ich den richtigen Charset verwenden soll mit TextSuite ?
Am besten das nach deiner meinung sinnvollste.

Zitat:

Das Mischen von 2 Fontbibliotheken halte ich eher für keine gute Idee. Denn bei meiner Bibliothek ist so etwas auch problemlos möglich und die Zeichen aller Fonts wandern in die gleiche Textur. Oder auch mehrere Texturen falls nötig. Abgesehen davon hast du dann keine 2 unterschiedlichen Codes. Aber ich bin da evtl. auch nicht ganz unparteiisch.

Ja man sollte möglichst bei einer sache bleiben.
Bin halt auf das zeichnen über BitmapFonts zurückgegangen da ich kein lösung für mein minor problem gefunden habe.
Denke aber doch das es besser aussieht wenn der Block richtig formatiert angezeigt wird.

EDIT:
das mit dem Block geht nun mit der Courier New
Nur eine frage kann man den Block nach vorne setzen ?
Wird im moment überzeichnet
Siehe Bild

gruss Emil

[Lossy eX]

Font: Das sind ganz normale Quads. Wenn du beim Zeichnen den Tiefentest deaktivierst werden sie über alles andere gezeichnet. Der Tiefentest könnte im übrigen auch dafür sorgen, dass einige Zeichen (wie in "COMMAND" zu sehen) links abgeschnitten werden. Falls dir Courier nicht gefällt musste mal im System schauen. Ich glaube "Lucida Console" sieht freundlicher aus.

Du kannst mit der Bibliothek auch abfragen ob du ein Monospace Font hast oder nicht. Wenn du es erstellt hast rufst du tsGetParateri(TS_FONT_FIXED_WIDTH) auf. Kommt TS_TRUE zurück ist es eines. Bei TS_FALSE nicht.

Zitat:

Zitat von EWeiss

Zitat:

Es gibt auch eine Variante von tsTextOut die direkt mit WideStrings

Du meinst also wenn ich das richtig verstehe
anstatt SongName: string; diesen als Widestring zu deklarieren ?
Das sollte dann reichen ?

Meine vermutung ist eine etwas andere
das es nicht am Fontset sondern am Charset liegt oder ist es das was du mit
Widestring korrigieren willst ? 2 byte.

Was ich meine ....
Anstelle von {ANSI_CHARSET} OEM_CHARSET zu verwenden hätte dann aber nichts mit Widestring zu tun
oder geht das nur wenn beides zusammen arbeitet ?

Kann es ja nicht testen hab kein koreanisches System

Kannst du mir ein Beispiel zeigen wie ich den richtigen Charset verwenden soll mit TextSuite ?
Am besten das nach deiner meinung sinnvollste.

Also ich meine Charset und Codepage ist da ziemlich das Gleiche. Das arbeitet auch nach dem Prinzip, dass das Zeichen XYZ im Kyrillischen, im europäischen und sonst wo jeweils eine eigene Bedeutung hat. Wenn du jetzt im Europäischen bist und einen kyrillischen Text hast dann steht da nur murks drinne. Du kannst den zwar glaube ich als kyrillisch betrachten (wobei das über charsets ein absoluter Krampf sein muss) aber dann dürfen da keine speziellen europäischen Zeichen enthalten sein. Die würden wieder zu kyrillischen Zeichen werden und wären damit falsch. Du kannst von dem System her auch keine 2 Codepages mischen. Also ein Text der 2x CharCode 224 enthält ein mal im Kyrillischen und ein Mal als europäischen ist nicht möglich.

Eine Codepage setzten kannst du mit tsSetParameteri(TS_CODEPAGE, TS_CODEPAGE_8859_8);. Allerdings wird das für dich nicht viel bringen, da Koreanisch Codepages hat die ich noch gar nicht unterstütze (andere typ codepages). Und wegen dem Abschnitt weiter oben.

Ich würde dir von daher empfehlen es lieber gleich richtig zu machen. Also Widestrings. Denn in denen hat jedes Zeichen einen eigenen Wert und du keine Einschränkung in gebietsschemen. ABER. Du MUSST auch komplett mit WideStrings arbeiten. Also vom Anfang bis zum Ende. Ich weiß jetzt nicht wo du die Texte herbekommst aber wenn das Dateinamen aus Delphi sind, dann funktioniert es nicht einen String zu einem WideString zuzuweisen, da bereits in dem String schon fehlerhafte Texte enthalten sein dürften. Das ist etwas wessen du dir bewusst sein musst.

Die TextSuite kann die dann nur darstellen, wenn sie lückenlos weitergereicht werden. Selbes würde im übrigen auch für die Windows GDI gelten, wenn du damit Unicode Texte ausgeben würdest.

[EWeiss]

Erst mal ein großes Danke schön für deine guten erklärungen ;) schleim .. muss aber mal gesagt werden

Zitat:

Font: Das sind ganz normale Quads. Wenn du beim Zeichnen den Tiefentest deaktivierst werden sie über alles andere gezeichnet. Der Tiefentest könnte im übrigen auch dafür sorgen, dass einige Zeichen (wie in "COMMAND" zu sehen) links abgeschnitten werden. Falls dir Courier nicht gefällt musste mal im System schauen. Ich glaube "Lucida Console" sieht
freundlicher aus.

jo sieht was besser aus und das deaktivieren des Tiefentest geht auch.

Zitat:

Eine Codepage setzten kannst du mit tsSetParameteri(TS_CODEPAGE, TS_CODEPAGE_8859_8);.

Ja habe in die Hilfe geschaut war mir nur nicht klar mit welchen parameter
der Codepage zugewiesen werden kann.

Der ablauf ist wie folgt
Die Anwendung sendet einen PChar für den SongTitle an BassVis

Delphi-Quellcode:

mMediaInfo.Songfile    := PChar(StreamFile);

Die Vis.. vis_BassVis holt sich den SongTitel über

Delphi-Quellcode:

SongName    := Pointer(SendMessage(This_Mod^.hWNDParent, WM_WA_IPC, PlaylistPos, IPC_GETPLAYLISTTITLE));

von BassVis

Delphi-Quellcode:

if StreamInfo.PlaylistTitle <> nil then
  ReturnStr := StreamInfo.PlaylistTitle + chr(0);

p := @ReturnStr;
Inc(p, 1);
Result := longint(p);

Denke kann anstelle von Widestring auch PWideString verwenden.
Und es ist wirklich nötig das in der anwendung schon PWidestring verwendet wird ?
Das ist schwirig da es in VB kein Widestring gibt
String 10 Bytes
Bedeutet dann wohl in VB würde es nicht funktionieren mit Unicode

Den CodePage kann ich dann ignorieren?
EDIT:
Habe nun das problem das TextSuite nicht zu WideString kompatibel ist

Delphi-Quellcode:

tsTextOutA(PChar(text));

text: WideString
tsTextOutA erwartet PChar..

hmm scheint nicht so einfach zu sein in der Suite rumwurschteln bringt nix. ;)

gruss Emil

[Lossy eX]

Zitat:

Erst mal ein großes Danke schön für deine guten erklärungen :wink: schleim .. muss aber mal gesagt werden

Man tut was man kann. ;)

tsTextOutA ist die ANSI Variante von tsTextOut.
tsTextOutW ist die Wide Variante von tsTextOut.

tsTextOutA macht intern nichts anderes als den Text mit der aktuellen CodePage in einen WideString zu verwandeln und damit dann tsTextOutW aufzurufen. tsTextOutW erwartet einen pWideChar. tsTextOutW ist die Funktion die du benötigst um WideStrings ausgeben zu können.


Wenn du mit Widestrings arbeitest, dann kannst du die Codepage ignorieren. Allerdings habe ich keine Ahnung ob der Text richtig übergeben, da ich nicht verstehen was du da machst. VB habe ich bisher immer gemieden weswegen ich dir dazu auch nichts sagen kann. Auch kann ich nicht erkennen wo der Text genau herkommt. Und ob das bereits Widestrings sind. Aber wichtig ist, dass diese Kette nicht unterbrochen wird. Man kann WideStrings leider direkt zu einem String zuweisen. Und sei es nur als Paramater einer Funktion. Sobald das gemacht wurde ist der Text kaputt bzw. unmapbare Zeichen erscheinen als Fragezeichen.

pWideString: Also pWideString benutze ich persönlich nicht. Kann also dazu nur bedingt was sagen. Denn das ist ein Pointer auf einen WideString wärend pWideChar ein Pointer auf das erste Zeichen ist. Das Ende des Strings ist dann durch ein #$0000 gekennzeichnet. Warum ich das Unterscheide liegt im Wesen der Delphi Strings. Diese haben eine Längenangabe und Referenzzählung vor dem Pointer! Denn du jetzt einen pWideChar als pWideString benutzen würdest, dann würde Dephi versuchen auf diese Informationen zuzugreifen. Die würde aber vermutlich nicht existieren. Entsprechend würde es Fehler geben. Da ich mit der TextSuite aber auch andere Sprachen unterstützen will kann ich so etwas natürlich nicht benutzen.

Zitat:

von BassVis

Delphi-Quellcode:

if StreamInfo.PlaylistTitle <> nil then
  ReturnStr := StreamInfo.PlaylistTitle + chr(0);

p := @ReturnStr;
Inc(p, 1);
Result := longint(p);

Das halte ich für sehr gefährlich!!! Denn wenn du den Pointer p als Rückgabewert der Methode hast, dann existiert der String ReturnStr bereits nicht mehr. Kurze Erklärung warum. "StreamInfo.PlaylistTitle + chr(0);" Erstellt einen neuen String (Wide oder Long ist dabei egal). Die Referenzzählung von Delphi hält den String am Leben. Du lässt dir den Pointer auf den String geben. Setzt den Pointer auf das erste Zeichen und gibst die Adresse zurück. Beim Verlassen der Methode merkt Delphi aber, dass der STRING nicht mehr benutzt wird und gibt ihn frei. Der Pointer zeigt aber immer noch auf den Speicherbereich. Wenn jetzt irgendwas neuen Speicher haben will, dann kann es passieren, dass die Daten des Strings überschrieben werden. Inklusive des terminierende #0 Zeichens. Was nicht so gut sein dürfte, wenn man auf korrekten Inhalt angewiesen ist.

Zum Erfragen eines pChar oder pWideChar anhand eines String oder WideString genügt pChar(String) oder pWideChar(WideString) zu machen. Dabei achtet Delphi selber darauf, dass ein abschließendes #0 vorhanden ist und positioniert den Pointer selbsttätig auf das erste Zeichen. Aber auch da musst du darauf achten, dass der String, wärend der Lebensdauer des Pointers über, vohanden ist. Unter anderem ist das ein Grund warum ich innerhalb der TextSuite die Textbehandlung selber in die Hand genommen habe. Wenn ich die Strings nicht selber freigebe bleibt ein Speicherloch aber so werden sie mir nicht unter dem Allerwertesten weggeschossen.

[EWeiss]

Zitat:

tsTextOutW ist die Wide Variante von tsTextOut.

Das ist gut ;)
Macht keinen sinn dann WideString wider auf PChar zu casten dann war alles umsonst.

Zitat:

Das halte ich für sehr gefährlich!!!

Wie würdest du es denn machen ?
Returnstring ist nun mal ein string aber die Rückgabe muss Longint bzw.. der pointer auf den string sein.
Mir ist da nix anderes eingefallen.

Zitat:

Allerdings habe ich keine Ahnung ob der Text richtig übergeben, da ich nicht verstehen was du da machst.

Der Songtitel ist der name der ausgeführten Datei (mp3 oder was immer)
übergebe dann meinen Record @mMediaInfo an BassVis(DLL)
die konstanze mMediaInfo.Songfile := PChar(StreamFile);
zeigt dann auf den String 'StreamFile'

jetzt ist nur die frage ob der Record Typensicher ist und der übergebene WideString auch erhalten bleibt.
Wie es dann weitergeht habe ich ja schon beschrieben .. weiter oben.

EDIT:
Du hast da im OpenGl Forum im Thread von TextSuite den Eintrag!

Delphi-Quellcode:

Font1 := TtsFontCreator.Create('C:\WINDOWS\Fonts\verdana.ttf', 14, [], ffBGRA); 
Font2 := TtsFontCreator.Create('C:\WINDOWS\Fonts\bonzai.ttf', 36, [], ffBGRA);
Font2.AddPostProcessStep(TtsPostPattern.Create(Pattern, 0, 0));
Font2.AddPostProcessStep(TtsPostBorder.Create(1, tsColor($FF, $FF, $FF, $FF)));
Font2.AddPostProcessStep(TtsPostShadow.Create(10, 3, 4, 3, $A0)); 

Font3 := TtsFontCreator.Create('C:\WINDOWS\Fonts\Cyberbit.ttf', 34, [], ffBGRA);
Font3.AddPostProcessStep(TtsPostPattern.Create(Pattern, 0, 0));
Font3.AddPostProcessStep(TtsPostBorder.Create(1, tsColor($00, $00, $00, $FF)));
Font3.AddPostProcessStep(TtsPostBorder.Create(1, tsColor($FF, $FF, $FF, $FF)));
Font3.AddPostProcessStep(TtsPostShadow.Create(4, 3, 4, 3, $A0)); 

Font4 := TtsFontCreator.Create('C:\WINDOWS\Fonts\Cyberbit.ttf', 34, [], ffBGRA);
Font4.AddPostProcessStep(TtsPostBorder.Create(1, tsColor($00, $00, $00, $FF)));
Font4.AddPostProcessStep(TtsPostShadow.Create(3, 0, 2, 2, $80));

und erstellst damit Chinesiche schriftzeichen
gibt es ein Sample ohne SDL das ich mir mal anschauen kann
dann weiss ich wenn alles richtig läuft das es mit widestring bei mir auch funktioniert.

gruss Emil

[Lossy eX]

pWideChar auf pChar casten. Muss gestehen. Keine Ahnung ob Delphi da so schlau ist, weil eigentlich beides nur Pointer sind.


Also das Beispielcode was du da hast ist uralt. ;) Also das sind keine öffentlichen Klassen mehr und von den Funktionen her auch anders. Ein direktes Beispiel habe ich nicht, da ich damit andere Dinge zeigen will. Aber der nachfolgende Code sollte hoffentlich genügen. Du kannst den in das SingleLine rein packen. Das einzig Interessante daran ist cAsia. Das sind aneinander gereihte 16 Bit Hexwerte.

Delphi-Quellcode:

const
  cAsia = #$9019#$662F#$6A23#$54C1#$4E2D#$570B#$6587#$672C#$70BA#$6E2C#$8A66#$5716#$66F8#$9928#$3002;

procedure TMainForm.Init_TextSuite;
begin
  tsInit(...)

  tsSetParameteri(TS_RENDERER, TS_RENDERER_OPENGL);
  tsSetParameteri(TS_RENDERER_OPENGL_TEXTURE_SIZE, TS_RENDERER_OPENGL_TEXTURE_SIZE_512);

  tsSetParameteri(TS_CREATOR, TS_CREATOR_GDI_FACENAME);

  tsFontCreateCreator('Arial Unicode MS', 52, TS_STYLE_NORMAL, TS_DEFAULT, TS_DEFAULT, @fFont1ID);
  tsPostAddFillColor3ub(233, 118, 33, TS_CHANNELS_RGB);
  tsPostAddBorder3f(2.4, 1, 1, 1, 1);
  tsPostAddShadow4f(0, 3, 3, 0, 0, 0, 0.5);

  tsFontCreateCreator('Bitstream Cyberbit', 52, TS_STYLE_NORMAL, TS_DEFAULT, TS_DEFAULT, @fFont2ID);
  tsPostAddFillColor3ub(233, 118, 33, TS_CHANNELS_RGB);
  tsPostAddShadow4f(0, -1, -1, 1, 1, 1, 1);
  tsPostAddShadow4f(0,  1,  1, 0, 0, 0, 1);
  tsPostAddBorder4f(1.8, 1, 0, 0, 0, 0.4);
begin


procedure TMainForm.FormPaint(Sender: TObject);
begin
  // clear screen and depth buffer
  glClear(GL_COLOR_BUFFER_BIT);

  glMatrixMode(GL_MODELVIEW);
  glLoadIdentity;

  glTranslatef(0, 0, -10);

  // set align to center
  tsSetParameteri(TS_ALIGN, TS_ALIGN_CENTER);

  glPushMatrix;
    glTranslatef(ClientWidth div 2, 90, 0);
    tsFontBind(fFont1ID);
    tsTextOutW(cAsia);
  glPopMatrix;

  glPushMatrix;
    glTranslatef(ClientWidth div 2, 180, 0);
    tsFontBind(fFont2ID);
    tsTextOutW(cAsia);
  glPopMatrix;

  // Check for Errors
  CheckError;

  SwapBuffers(fDC);
end;

Das Arial Unicode MS ist unter XP Standard nicht mehr enthalten. Entsprechend solltest du ein anderes Font benutzen. Das kann dann natürlich vom Bild her dann abweichen. Aber es sollte in etwas wie das Asia.png aussehen.


Zu dem Dateinamen:

Delphi-Quellcode:

mMediaInfo.Songfile := PChar(StreamFile);

Ich denke genau da könnte schon das Problem sein. Denn StreamFile ist vermutlich ein String, oder? Und damit sind bereits da die Unicode Zeichen weg. Die gesammten Dateioperationen von Delphi. FindFirst/FindNext, TFileStream basieren leider alle auf Ansi und sind nicht Unicode kompatibel.

Der gefährliche Pointer. Weiß nicht wie die Struktur ist. Wenn möglich gar keinen neuen String erzeugen sondern den Weiterreichen den du bekommst. Weil der ist ja schon gültig und kann erst nach dem Funktionsaufruf gelöscht werden. Wenn man den länger benötigt, dann MUSS davon eine Kopie erstellt werden und diese auch so lange gespeichert werden. Strings in Records sind da okay. Selbst wenn die Records dynamisch via New erstellt wurden und mit Dispose wieder gelöscht werden. Beim Löschen aber entweder die Strings leer setzen oder einen typisierten Pointer disposen, da sonst die Referenzzählung der Stings nicht greift.

[EWeiss]

Es sieht jetzt folgendermaßen aus
Asiatischer Text wird angezeigt.

Habe nur innerhalb vis_bassVis string nach PWideChar geändert.
in wie weit der Text nun stimmt keine ahnung.

Was aber seltsam ist jetzt gehen alle Fonts nicht mehr nur noch asiatische.
Ist das ein bug in TextSuite ?

gruss Emil

[Lossy eX]

Ich denke nicht, dass es ein Fehler in der Bibliothek ist. ;)

String nach pWideChar ist scheinbar nicht richtig. Denn dann nimmt Delphi anscheinend den Pointer des Strings und castet diesen Stumpf nach pWideChar. Das hat dann zur Folge, dass die Zeichen verschmelzen. Es verschmilzt im übrigen auch das letzte Nullzeichen. Wenn das rein zufällig mit einem nicht Null Zeichen verschmilzt wird das Ende des String vernichtet. Das kann riesige Texte aber auch AccessViolations zur Folge haben.

Du musst also zu erst den String auf einen WideString zuweisen und den dann als pWideChar casten. Dann würden zu mindest der aktuellen Ansi Text in richtiges Wide verwandelt. Allerdings denke ich nicht, dass du dann sinnvoll asiatische (bzw alles nicht latin-1) texte sehen würdest, da es zu begin ja schließlich ein Ansi string war. Und weg ist in diesem Fall weg. Da kann dir so keiner helfen. Das würde aktuell dann dem oem_charset entsprechen. Also das was im Windows eingestellt wurde.

[EWeiss]

Zitat:

Zitat von Lossy eX

Ich denke nicht, dass es ein Fehler in der Bibliothek ist. ;)

String nach pWideChar ist scheinbar nicht richtig. Denn dann nimmt Delphi anscheinend den Pointer des Strings und castet diesen Stumpf nach pWideChar. Das hat dann zur Folge, dass die Zeichen verschmelzen. Es verschmilzt im übrigen auch das letzte Nullzeichen. Wenn das rein zufällig mit einem nicht Null Zeichen verschmilzt wird das Ende des String vernichtet. Das kann riesige Texte aber auch AccessViolations zur Folge haben.

Du musst also zu erst den String auf einen WideString zuweisen und den dann als pWideChar casten. Dann würden zu mindest der aktuellen Ansi Text in richtiges Wide verwandelt. Allerdings denke ich nicht, dass du dann sinnvoll asiatische (bzw alles nicht latin-1) texte sehen würdest, da es zu begin ja schließlich ein Ansi string war. Und weg ist in diesem Fall weg. Da kann dir so keiner helfen. Das würde aktuell dann dem oem_charset entsprechen. Also das was im Windows eingestellt wurde.

Dann bleibt mir nur eins übrig .. warten bis die nächste Delphi version mit Unicode Support auf den Markt kommt.
Bei denen wo es mit dem Font nicht funktioniert muss ich halt die alternative zum BitmapFont anbieten
so kann man umschalten zwischen realen Fonts oder BitmapFonts (Da fehlen dann halt ein paar zeichen)

Habe leider noch keinen vollständigen BitmapFont für OpenGl gefunden
Der den ich benutze ist von NEHE 256x256

gruss Emil

[Lossy eX]

Ein vollständiges Bitmapfont wird es nicht geben. Denn Unicode hat Platz für $10FFFF (1.114.112) Zeichen. Es sind aber nicht alle belegt. Das mit Abstand umfangreichste Font was ich kenne ist "Arial Unicode MS" mit 50.377 Zeichen. Was aber noch nicht alle definierten Zeichen abdeckt. Aber da mal eine kleine Rechnung. Textur ist 256x256. Ich denke da sind 16x16 Zeichen enthalten. Machen also 256 Zeichen pro Textur. 50.377 / 256 = 196,8 entspricht 197 Texturen. Bei reinen Alphatexturen wären das fast 13 MB. Wenn das RGBA Textuern sind dann das 4fache.

Delphi unterstützt Unicode. Allerdings basiert die VCL, und alle eigenen Bibliotheken leider auf Ansistrings. Aber bei so etwas wie FindFirst/FindNext kannst du auch direkt zur Windows API greifen. Für FileStreams hat jemand im Delphi-forum eine Unicode kompatible Variante geschrieben. Bzw bietet Delphi einen THandleStream und das passende Handle bekommt man durch CreateFileW. TFileStream arbeitet auch so aber benutzt CreateFileA. Für die VCL gibt es TNT Controls die vollständig Unicode kompatibel sind. Wobei die aber mittlerweile nicht mehr frei sind. Aber ich meine ältere freie Versionen wird man sicher noch finden können. Und damit solltest du problemlos in der Lage sein komplexe unicodekompatible Anwendungen erstellen zu können.
Obendrein nicht zu vergessen, dass für den Titel/Album/Interpret ja normal die ID3 Tags da sind und in denen können meines Wissens nach Unicode Texte stecken.

Denn auch wenn dir diese Aussage jetzt nicht gefällt und da gehe ich mal stark von aus. Aber ich denke nicht, dass ein neues Delphi an deiner derzeitigen Situation etwas ändern würde. Denn Delphi könnte nicht einfach so String durch WideString ersetzen. Das würde bedeuten, dass der Compiler sein Verhalten (bzw das des Codes) ändert und das geht normal gar nicht. Deswegen musst du selber darauf achten wirklich durchgängig mit WideStrings zu arbeiten. Und ein Bitmapfont mit den passenden Buchstaben wird dir da auch nicht viel nützen, denn wenn du die Informationen nicht hast um welche Unicode Zeichen es sind handelt kannst du nicht darauf zugreifen. Und die TextSuite ist dort nichts anderes als ein dynamischen Bitmapfont + reichlich Möglichkeiten es zu manipulieren bzw. Informationen zu erfragen.

Allerdings ist das nur meine Meinung und die Entscheidung liegt letzten Endes natürlich bei dir.

[EWeiss]

Zitat:

Obendrein nicht zu vergessen, dass für den Titel/Album/Interpret ja normal die ID3 Tags da sind und in denen können meines Wissens nach Unicode Texte stecken.

Keines falls ;)
Du weißt doch gar nicht ob in den Dateien ein ID3 Tag enthalten ist
außerdem visualisiert BassVis auch direkt von der Soundkarte so dass wenn man einen Titel
von einem Video übergibt auch dieser angezeigt wird.
Das selbe mit meinen Fernseh-programm wenn ich hier visualisiere(mit Plugin ... vis_BassVis)
dann will ich sehen welcher Kanal. Programm usw. gerade läuft.

Zitat:

Und ein Bitmapfont mit den passenden Buchstaben wird dir da auch nicht viel nützen, denn wenn du die Informationen nicht hast um welche Unicode Zeichen es sind handelt kannst du nicht darauf zugreifen

Hierbei geht es mir nicht darum Unicode anzuzeigen sondern generell auf allen die Bitmaps anzuzeigen wo der Font so nicht funktioniert.
Wenn es ein reines Asiatisches oder Koreanisches System ist und die ihre Songs oder was auch immer in Koreanisch abgelegt haben
dann haben sie halt pech gehabt.
Mit den FoontBitmap wird in Deutsch auch kein äöü usw.. angezeigt. Muss halt damit leben wenn ich diese dem Systemfont vorziehe.

Hab mich noch was schlau gemacht.

Delphi-Quellcode:

function EncodeUTF8(const Source: WideString): string;
var
  Index, SourceLength, CChar: Cardinal;
begin
  { Convert unicode to UTF-8 }
  Result := '';
  Index := 0;
  SourceLength := Length(Source);
  while Index < SourceLength do
  begin
    Inc(Index);
    CChar := Cardinal(Source[Index]);
    if CChar <= $7F then
      Result := Result + Source[Index]
    else if CChar > $7FF then
    begin
      Result := Result + Char($E0 or (CChar shr 12));
      Result := Result + Char($80 or ((CChar shr 6) and $3F));
      Result := Result + Char($80 or (CChar and $3F));
    end
    else
    begin
      Result := Result + Char($C0 or (CChar shr 6));
      Result := Result + Char($80 or (CChar and $3F));
    end;
  end;
end;

Delphi-Quellcode:

function ToUnicodeString(s: pchar): WideString;
var
   pw1 : array[0..1024] of WideChar;
   nLen1, nLen2, nLen3 : integer;
begin
   nLen1 := Length(s);
   nLen2 := length(pw1);
   nLen3 := MultiByteToWideChar(CP_OEMCP, MB_PRECOMPOSED, s, nLen1, @pw1[0], nLen2);
   if nLen3 > 0 then
   begin
      pw1[nLen3] := chr(0);  
      Result := WideString(pw1);
   end else
      Result := '';
end;

Delphi-Quellcode:

function StrToUTF8(s: pchar): string;
var
   w_str : WideString;
begin
   w_str := ToUnicodeString(s);
   if w_str <> '' then
      result := EncodeUTF8(w_str)
   else
      result := '';
end;

Das funktioniert denke es liegt mit daran das du kein Koreanisch unterstützt.

Delphi-Quellcode:

// Display Song Name
if ShowSong and not pPolygone then
begin
  if PlaylistPos_ <> 0 then
    PlaylistPos := PlaylistPos_
  else
    PlaylistPos := SendMessage(This_Mod^.hWNDParent, WM_USER, 0, IPC_GETLISTPOS);
    SongName_    := Pointer(SendMessage(This_Mod^.hWNDParent,
                           WM_WA_IPC, PlaylistPos, IPC_GETPLAYLISTTITLE));

  if Strlen(SongName_) > cardinal(fMaxSongLen) then 
    SongName_ := PChar(Ansimidstr(SongName ,1, fMaxSongLen-5) + '..');

    SongName := PChar(StrToUTF8(SongName_));

    glEnable(GL_TEXTURE_2D);
    glEnable(GL_BLEND);

    // Zeige Playstatus status
    case PlayState of
      0:
        glPrintXY(fSongLeft, PlaystateYPos, PChar('Stopped'), fLargeFontID, TS_ALIGN_LEFT);
      1:
        glPrintXY(fSongLeft, PlaystateYPos, SongName, fLargeFontID, TS_ALIGN_LEFT);
      3:
        glPrintXY(fSongLeft, PlaystateYPos, PChar('Paused'), fLargeFontID, TS_ALIGN_LEFT);
    end;

    if songpos_ <> 0 then
      songpos := songpos_
    else
      songpos := SendMessage(Module1.hWNDParent, WM_WA_IPC, 0, IPC_GETOUTPUTTIME);
    strSongpos     := GetSongPosStr(songpos);

    SongLength  := SendMessage(This_Mod^.hWNDParent, WM_USER, 1, IPC_GETOUTPUTTIME);
    strSongLength := GetSongPosStr(1000* SongLength);

    if PlayState = 0 then
      glPrintXY(fTimeLeft, PlaystateYPos, PChar('00:00:00 \ 00:00:00'), fLargeFontID, TS_ALIGN_LEFT)
    else
      glPrintXY(fTimeLeft, PlaystateYPos, PChar(strSongpos + ' \ ' + strSongLength), fLargeFontID, TS_ALIGN_LEFT)
end;

EDIT:
Das ist garantiert ein Bug in TextSuite ;)
Mein Plugin stürzt ab wenn dieser Font gewählt wird... "Segoe Print"
EDIT2:
Hmmm irgendwas scheint bei der function EncodeUTF8 auch nicht zu stimmen
jetzt werden mit die umlaute "äöü" nicht mehr angezeigt.. na ja muss mal schaun. ;)

gruss Emil

[Lossy eX]

Die Bibliothek unterstützt UCS-2. Das heißt alle Zeichen die einen Wert zwischen $0000 und $FFFF haben. $FFFF natürlich auch. $0000 kennzeichnet ein Stringende. Und dann natürlich nur die Zeichen die in dem Font enthalten sind. Woher soll ich die sonst auch herbekommen. CJK (Chinesich/Japanisch/Koreanisch) belegen einen ziemlich großen Bereich. Aber der ist trotzdem noch locker unter $FFFF. Und wie du an meinem Bild aus einem der letzen Posts sehen kann unterstüzte ich diesen Bereich.

Ja die hochgeladenen Version enthält mit Sicherheit noch Fehler. Ich habe auch nie gesagt, dass sie fehlerfrei ist. Das wäre nicht nur naiv sondern auch vermessen wenn nicht sogar dumm. Nichts ist absolut fehlerfrei! Ich habe nur gesagt, dass die Fehler die du da hast nicht an der Bibliothek liegen sondern an den Daten die ich bekomme. Die Version der Bibliothek ist im übrigen auch noch keine richtig freigegebene Version. Allerdings kommt sie dem sehr sehr nahe. Ich will nur im Zuge der Hilfe auch noch durch den Code gehen und schauen ob alle Fehlercode richtig sind. Und da ist mir schon so das ein oder andere aufgefallen was problematisch werden könnte.

UTF-8 und Umlaute: ÄÖÜ liegen überhalb des Zeichenwertes 127 und entsprechend werden sie von UTF-8 in 2 Byte zerlegt. Wenn du deinen UFT-8 String nun als normalen String betrachtest wird da logischerweise kein ÄÖÜ enthalten sein. Ob das richtig ist was du da hast weiß ich nicht. Habe ich nicht getestet.

Um dir auch mal zu demonstrieren, dass es unter Umständen vielleicht doch ein bisschen funktionieren könnte und nicht alles verbugt ist... habe ich extra für dich eine Anwendung gemacht. Inklusive Fontauswahl und einstellbarer Größe. Sie ließt eine UFT-8 Datei ein und gibt sie aus. CJK befindet sich weiter unten in der Datei. Dafür kann man ja scrollen. Probleme: Ich habe die Fonts nicht gefiltert. .fon können nicht dargestellt werden und deswegen sind einige Fonts einfach leer. Bei den Fonts mit dem @ liegen CJK Zeichen auf der Seite. Bei der Version ohne @ ist dies aber nicht so. Das ist scheinbar eine Eigenart von Windows. Keine Ahnung wieso. Und Teilweise ist das Defaultchar etwas komisch. Nicht sichtbar oder viel zu breit.

Segeo Print: Ich habe von diesem Font eine Version im Internet gefunden. Das Font ist ca 170kb groß. Ist das richtig? Ich habe die Anwendung auch mal bewusst mit dem Quellen von meinem Server übersetzt und nicht mit den aktuellen Entwicklungsversionen. Falls du damit trotzdem noch Probleme haben solltest, dann schick mir das Font bitte mal, dann schaue ich es mir im Debugger mal an.

[EWeiss]

Zitat:

Ja die hochgeladenen Version enthält mit Sicherheit noch Fehler. Ich habe auch nie gesagt, dass sie fehlerfrei ist. Das wäre nicht nur naiv sondern auch vermessen wenn nicht sogar dumm. Nichts ist absolut fehlerfrei! Ich habe nur gesagt, dass die Fehler die du da hast nicht an der Bibliothek liegen sondern an den Daten die ich bekomme. Die Version der Bibliothek ist im übrigen auch noch keine richtig freigegebene Version. Allerdings kommt sie dem sehr sehr nahe. Ich will nur im Zuge der Hilfe auch noch durch den Code gehen und schauen ob alle Fehlercode richtig sind. Und da ist mir schon so das ein oder andere aufgefallen was problematisch werden könnte.

Sei wegen meinen äußerungen bitte nicht sauer.
Letztendlich hilft es dir auch wenn ich da so penibel bin.. sprich eventuelle gefundene Fehler zu korrigieren.
Ich bin ja froh das sich jemand eine solche Arbeit macht und ich es frei nutzen darf.
Dafür meine Hochachtung und Daumen hoch ;)

Bei den Font der meine Anwendung zum absturz bring wird ein DLL Fehler gemeldet
die anscheinend von dem Fontsatz verwendet wird ..

accesssviolation in USP10.dll..

Danke für das Sample werde es mal testen.. Und habe nie gesagt das deine TextSuite nur verbugt ist. :)

EDIT:
Das Sample funktioniert
Darf nur nicht die Textdatei mit Uedit öffnen der zerstört da irgendwas wenn
ich sie wieder schließen tu.

Im Anhang ein Bild von dem Fehler mit der Schriftart..
Kommt auch bei deinen Sample.
Schicke dir die über PN!

Gruss Emil

[Lossy eX]

Danke für die Blumen. Ich habe ja jetzt per Zufall auch ein Speicherloch gefunden, als ich was nachgeschaut hatte. :) Und Fonts für OpenGL sind leider ein absoluter Missstand.

Die von dir geschickten Dateien funktionieren bei mir Problemlos. Die Datei usp10.dll ist bei mir vorhanden. "Uniscribe Unicode script processor" als Version "1.0420.2600.2180 (xpsp_sp2_rtm.040803-2158)" scheint also Bestandteil von SP2 zu sein. Funktioniert das Font denn sonst? Also Word/Doppelclick etc.

Datei: Ich prüfe explizit ab ob ein BOM existiert. Die 2-3 Byte am Anfang der Dateien. In ReadUTF8 kannst das anpassen. Ich wollte nur sicher gehen, dass ich auch wirklich UFT-8 bekomme.

[EWeiss]

Zitat:

Zitat von Lossy eX

Danke für die Blumen. Ich habe ja jetzt per Zufall auch ein Speicherloch gefunden, als ich was nachgeschaut hatte. :) Und Fonts für OpenGL sind leider ein absoluter Missstand.

Die von dir geschickten Dateien funktionieren bei mir Problemlos. Die Datei usp10.dll ist bei mir vorhanden. "Uniscribe Unicode script processor" als Version "1.0420.2600.2180 (xpsp_sp2_rtm.040803-2158)" scheint also Bestandteil von SP2 zu sein. Funktioniert das Font denn sonst? Also Word/Doppelclick etc.

Datei: Ich prüfe explizit ab ob ein BOM existiert. Die 2-3 Byte am Anfang der Dateien. In ReadUTF8 kannst das anpassen. Ich wollte nur sicher gehen, dass ich auch wirklich UFT-8 bekomme.

Hmm sehr seltsam habe auch die Version
1.0420.2600.2180 (xpsp_sp2_rtm.040803-2158)

sobald ich den Font auswähle mit deinem SystemEnum oder vis_BassVis
dann kracht es hier gewaltig.

Habe XP Professional Serv2
Denke die anderen dinge sind dafür unerheblich.

EDIT:
In Word kann ich ihn wählen und auch mit arbeiten.
EDIT2:
Der Fehler tritt in

Delphi-Quellcode:

procedure TtsRenderer.TextOut(pText: pWideChar);

auf in folgender zeile..

Delphi-Quellcode:

pItemList := SplitText(pText);

gruss Emil

[Lossy eX]

Ich habe das auch mal auf Windows 2000 ausprobiert und funktionierte ohne Probleme. Wobei ich da auch explizit mal via ProcessExplorer geschaut hatte. Meine Anwendung verwendet die usp10.dll nicht. Also nicht mal indirekt durch andere DLLs. Ich werde das heute Abend noch mal auf anderen System ausprobieren. XP ohne SPs und XP 64bit (wobei die Anwendung trotzdem 32 Bit bleibt). Allerdings denke ich nicht, dass ich auf ein anderes Ergebniss kommen werden. Denn auf diesen Systemen hatte ich das schon reichlich getestet gehabt.

Das das Font innerhalb der Struktur falsche Werte enthält und scheinbar kaputt ist ist absolut richtig. Das dort benutze Record packt einige Felder übereinander. Je nachdem was der ItemTyp für einen Wert hat. Der Typ 3 ist ein Text. Entsprechend ist der Pointer von Font kein TtsFont sondern ein pWideChar. Dafür gibt es aber auch das Feld Word was vom Typ pWideChar ist.

Was mich daran aber mehr wundert. SplitText ist absolut simpel und geht nur Zeichen für Zeichen durch den Text und trennt den Text ins seine Bestandteile. Also Leerzeichen, Tabs, Zeilenumbrüchen etc. Aber diese Methode greift aussließlich auf den Text zu. Bzw. erstellt Kopien der einzelnen Teilstücke. Da wird mit dem Font nichts gemacht. Beim Erstellen des Fonts lese ich ein paar Eigenschaften aus und erst wenn der komplette Text durchgeparst wurde erstelle ich die benötigten Zeichen. In der Zwischenzeit geschiet nichts mit dem Font.

Ein Fehler dort deutet eher darauf hin, dass der Text irgendwie kaputt ist. Was aber dann eigentlich schon bei der Konvertierung von UTF-8 zu Wide hätte auffallen müssen. Du kannst ja auch mal in der TextSuite.inc das Define TS_PURE_PASCAL aktivieren. Damit wird der Assemblercode deaktiviert. Vermute aber das es eher nichts ändern wird. Hattest du da etwas an dem Text verändert? Im Zweifel kannst du auch mal einen konstanten Text ausgeben. Also tsTextOutA('a'); Ansonsten mal bitte das Font löschen und neu installieren. Oder wenn du es auf anderen System testen dann dies bitte auch mal tun.

Aktuell scheint dieses Problem nämlich nur auf deinem System aufzutreten und da sind mir ehrlich gesagt ein bisschen die Hände gebunden.

[EWeiss]

Zitat:

Aktuell scheint dieses Problem nämlich nur auf deinem System aufzutreten und da sind mir ehrlich gesagt ein bisschen die Hände gebunden.

So tragisch is es eigentlich nicht da ich ja weiss der Font hier nicht geht
dann wähle ich ihn einfach nicht aus.
Wenn ich ihn doppelklicke oder anderweitig damit arbeite funktioniert er ja.

gruss Emil

[EWeiss]

Ist es möglich den CodePage im clickevent direkt zu ändern ohne
die Datei neustarten zu müssen ?

Delphi-Quellcode:

If UseUTF8 then
  TsSetParameteri (TS_CODEPAGE, TS_CODEPAGE_UTF8)
Else 
  TsSetParameteri (TS_CODEPAGE, TS_CODEPAGE_8859_1);

Ich möchte quasi den Codepage während der aktuellen sitzung verändern.

gruss Emil

[Lossy eX]

Ich verstehe nicht ganz was du meinst! Aber du kannst die Codepage jederzeit setzen. Wenn ich sage jederzeit meine ich auch jederzeit. Du kannst vor jedem tsTextOutA eine andere Codepage setzen. Das geht auch innerhalb des Block Moduses. Denn ich konvertiere den Text sowieso in einen WideString. Und intern verarbeite ich außschließlich nur WideStrings. Weswegen die CodePage nur ein zusätzlicher Schritt vorher ist.

Ich hatte das gestern noch mal auf XP sp1 und XP 64 Bit getestet und lief. Nur der Vollständigkeit halber.

[EWeiss]

Zitat:

Zitat von Lossy eX

Ich verstehe nicht ganz was du meinst! Aber du kannst die Codepage jederzeit setzen. Wenn ich sage jederzeit meine ich auch jederzeit. Du kannst vor jedem tsTextOutA eine andere Codepage setzen. Das geht auch innerhalb des Block Moduses. Denn ich konvertiere den Text sowieso in einen WideString. Und intern verarbeite ich außschließlich nur WideStrings. Weswegen die CodePage nur ein zusätzlicher Schritt vorher ist.

Ich hatte das gestern noch mal auf XP sp1 und XP 64 Bit getestet und lief. Nur der Vollständigkeit halber.

Ahh super das meinte ich ;)
Habe nämlich einige error als Meldung bekommen.
Liegt aber an OpenGl nicht an TextSuite.

Da ich aber probleme mit der übergabe des String habe funktioniert es nur
mit meiner hier ausgestellten konvertierung nach Widestring.
Da geht auch nichts verloren ;)

gruss Emil