Scripttexture inklusive Farbe anzeigen lassen

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Hallo,

    ich habe mich daran gesetzt, eine Innenanzeige über Skripttexturen umzusetzen, anstatt Texttexturen zu nutzen. Jetzt habe ich auch alles soweit geschafft, aber ich habe ein Problem. Ich habe jetzt einen Font eingesetzt für Umstiegsmöglichkeiten, der mehrfarbig ist. Also gibt es Symbole, die auch immer in verschiedener Reihenfolge mehrfarbig angezeigt werden sollen. Leider benutzt man ja aber eine Textur, bei der nur die Alpha geändert wird, aber nicht die Farbe. Also wird alles schwarz, nicht nur die Schrift, sondern auch die Symbole. Man kann zwar diese Textur ändern, aber das bringt mir in meinem Fall nichts, da die Symbole häufig in sehr unterschiedlicher Reihenfolge zu sehen sind und somit die Farben auf der Textur nicht zum geschriebenen passen.
    Gibt es eine Möglichkeit, die Skripttextur mit Alpha und Farbe als Textur anzeigen zu lassen? Ich hab schon einiges ausprobiert, aber habe es noch nicht hinbekommen...

    LG
    Julius

  • Zum Hilfreichsten Beitrag springen

  • Anzeige

    Das kannst du eigentlich nur über mehrere Scripttexturen lösen, halt in unterschiedlichen Farben. Das funktioniert allerdings auch nur, wenn die Logos nur eine Farbe haben, also z.B. blau-weiß oder rot-weiß. Sonst bist du mit Scripttexturen aufgeschmissen. Das Prinzip ist hier das gleiche wie bei der Polychrome-K++.

    • Hilfreichster Beitrag

    Zweieinhalb Jahre später muss ich mich doch korrigieren. Es sollte mit Scripttexturen möglich sein. Dafür musst du anstelle von [matl_transmap] den Befehl [useScripTexture] verwenden. Der Befehl macht das gleiche wie [useTextTexture], allerdings mit Scripttexturen. Die Handhabe ist ebenfalls identisch:


    Damit wird die Textur des Materials durch die Scripttextur ersetzt, statt als Alpha-Maske verwendet zu werden. Die auf der Scripttextur verwendeten Farben werden somit auch angezeigt. Wie das mit Piktogrammen aussieht, habe ich nicht getestet. STTextOut hat jedenfalls die Möglichkeit, zwischen Font-Farbe und Vollfarbe zu unterscheiden und das funktioniert auch.


    ABER:

    Diese Konstellation ist nur bei dunkler Schrift auf hellem Hintergrund sinnvoll verwendbar. Es scheint hierbei Probleme bei der Darstellung zu kommen, wodurch helle Schrift auf dunklem Hintergrund nur sehr schwer erkennbar ist:


    Links ist mit [useScriptTexture], rechts mit [matl_transmap]


    Bei dunkler Schrift auf hellem Hintergrund ist der Unterschied zwar auch vorhanden, aber wesentlich weniger extrem:

    Wie hast du dieses Keyword denn herausgefunden? In der omsi.exe etwas gewühlt oder einfach rumprobiert? War ja bisher wohl nicht bekannt, dass das überhaupt existiert. :covereyes: Das sollte der Wiki definitiv hinzufügt werden.


    Aber mal sehen, ich werde es definitiv in nächster Zeit, evtl. heute, ausprobieren und dann sehen, wie es aussieht. Leider gibt es seit diesem Jahr nur noch die Innenanzeige mit Darkmode hier, also dunkler Hintergrund und helle Schrift. Aber vielleicht gibt es dort ja noch einen Wert, der die Darstellung verbessert.


    Danke auf jeden Fall für deine Erforschungen und das Teilen dieser! 8)

    Zitat von Entdecker666

    Wie hast du dieses Keyword denn herausgefunden? In der omsi.exe etwas gewühlt oder einfach rumprobiert?

    Ich selber nicht, aber dafür ein paar Leute am Discord vom Sobol. Ich habe das nur nebenbei aufgeschnappt und ausprobiert.

    Die Tatsache, dass man bei Scripttexturen alle 4 Kanäle beschreiben (R,G,B,A) und bitmaps laden kann, zeigt doch im Umkehrschluss schon, dass man diese Funktion nicht nur für den Alphakanal einer Matrix nutzen kann. ist zumindest mir schon seit Jahren bekannt, wenngleich das - zumindest bisher - kaum verwendung gefunden hat.
    Die Probleme der schlechten Sichtbarkeit kommen vom Mipmapping der Texturen. Wenn du näher ranzoomst, sollte die Sichtbarkeit besser werden.
    Damit das ordentlich funktioniert, musst du die scripttextur locken, dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren und dann locken, um sie zum rendern freizugeben. Je nach Verwendungsfall gegebenenfalls mit M.V.STFilter arbeiten.
    Also nicht mit Halbtransparenzen die Texte auf den Background bringen, sondern den Background selbst ebenfalls als Scripttextur umsetzen.

    Das gesamte Display mit ein- und ausgeschalteten Pixeln auf die Scripttextur zu holen habe ich tatsächlich noch nicht probiert, das schaue ich mir mal an.

    Mir erschließt sich trotzdem nicht ganz, wieso die Scripttextur selber als Textur verwenden ein anderes Ergebnis liefert als selbige Scripttextur für eine gleichfarbige "normale" Textur zu verwenden. Gefiltert ist alles.

    Zitat von Chrizzly92

    dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren

    Funktioniert das überhaupt? Das habe ich vor einigen Jahren schon mal probiert, aber mit keinen sinnvollen Ergebnissen.

    Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

    Zitat von DerGrafikfehler

    Das gesamte Display mit ein- und ausgeschalteten Pixeln auf die Scripttextur zu holen habe ich tatsächlich noch nicht probiert, das schaue ich mir mal an.

    Mir erschließt sich trotzdem nicht ganz, wieso die Scripttextur selber als Textur verwenden ein anderes Ergebnis liefert als selbige Scripttextur für eine gleichfarbige "normale" Textur zu verwenden. Gefiltert ist alles.

    Zitat von Chrizzly92

    dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren

    Funktioniert das überhaupt? Das habe ich vor einigen Jahren schon mal probiert, aber mit keinen sinnvollen Ergebnissen.

    mach mal STNewTex, STLock, STLoadTex und dann STUnlock. dann kurz fahren oder nen speichern erzwingen und die entsprechende scripttextur im mapordner prüfen. wenn sie dort korrekt dargestellt wird, sollte es rein technisch funktionieren. probiert habe ich das selbst allerdings in der form noch nicht. die einzelnen RGB Kanäle kann man aber per script aufjedenfall beschreiben, wüsste also nicht warum man keine textur laden können sollte.
    Eventuell ist auch wichtig, dass die Textur im Bitmap oder DDS format vorliegt.


    Das Problem beim Mipmapping ist, Dass zwei nebeneinander liegende Pixel für die nächst kleinere Texturstufe zusammengerechnet werden.
    Stell dir vor, Weiß ist deine Schrift, Schwarz ist der Alphakanal. halbierst du die Texturmaße, werden 2 nebeneinanderliegende Pixel zusammengerechnet. Aus Weiß (255) und Schwarz (0) ergibt sich 127 (grau). Die entstande Mipmap hat nun also eine "weichgezeichnete" kante mit einer halbtransparenz.
    in der nächsten stufe wird nun diese graue pixelkante wieder mit dem schwarzen pixel daneben multipliziert. Dies ergibt also eine Transparenz von 64. nächste stufe 32.
    umso weiter du also weggehst, desto mehr "blutet" der Alpha-kanal in die Pixel der sichtbaren Buchstaben.


    Zitat von Entdecker666

    Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

    das ist tatsächlich eine Einschränkung, die sich so einfach nicht beheben lässt - zumindest ist mir da kein Weg bekannt, der sich performancetechnisch relativieren lässt. schreibst du mit einer alpha auf die vorhandene textur, wird diese ja auch entsprechend übernommen. im script könntest du aber beispielsweise einen großen Rahmen in Weiß auf den Alphakanal der Scripttextur zeichnen, um die transparenzen zu entfernen - dann hast du allerdings einen Rahmen um die einzelnen Buchstaben. Hier hilft nur, den Background des Fonts an den Hintergrund des Displays anzupassen und gegebenenfalls durch verschiedene Fonts durchzuschalten, je nach Hintergrundfarbe.


    Rein technisch gäbe es auch dafür eine Lösung: Zwei Scripttexturen. Dazu erstellt man zwei Scripttexturen gleicher Größe und nutzt wie bei den VMatrizen einen "Pixelcursor", um Pixel für Pixel von der einen Textur in die andere zu übertragen.
    Ist die Ausgabe von STReadPixel an Position X/Y in den RGB Werten kleiner als 50, wird der Pixel ignoriert, ist er größer als 50 (oder ein beliebiger selbst definierter Schwellenwert) wird der Pixel von der einen auf die andere Scripttextur übertragen.
    Bei einem Display von 1920x1080 pixeln würde das aber bedeuten, dass man 2,1 millionen Frames benötigt, um das Display zu übertragen, wenn man pro Frame einen Pixel überträgt.
    hat man eine überschaubare Anzahl an Textfeldern, kann man das natürlich optimieren, braucht aber bisschen mehr Script, um die Positionen von Start und Zieltextur zu bestimmen.
    Hat der Font 16px höhe und du hast 8 textfelder mit jeweils 256px länge, wären nur 32000 pixel zu übertragen. aber selbst dann braucht man ein riesen Konglomerat an Scriptschnipseln und Macros, um das in einer Sinnvollen Zeit abzuarbeiten.
    Sinnvoll Einsetzbar ist die Nutzung von Fonts als direkte Scripttextur also nur, wenn man den Background der Fonts dem Background des Displays anpasst.

    Mit eingebautem Hintergrund kann man den Text auch mit [useScriptTexture] gut lesen: (verschobene Liniennummer und Ziel bitte ignorieren)




    Zitat von Chrizzly92

    mach mal STNewTex, STLock, STLoadTex und dann STUnlock. dann kurz fahren oder nen speichern erzwingen und die entsprechende scripttextur im mapordner prüfen. wenn sie dort korrekt dargestellt wird, sollte es rein technisch funktionieren

    Das war meine ursprüngliche Methodik, auf der Scripttextur passt alles. Sowas ähnliches habe ich in einer der allerersten Script-Versionen vor drei Jahren auch beobachtet: Da habe ich die UI auf ein eigenes Plane mit Freetex gelegt, aber auch dort nur die tatsächlich aktiven Pixel drauf gehabt. Hat den gleichen Effekt wie oben gehabt, nur noch schlimmer. Aus der Distanz wie am Screenshot waren die UI-Elemente gar nicht mehr erkennbar.


    Zitat von Chrizzly92
    Zitat von Entdecker666

    Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

    das ist tatsächlich eine Einschränkung, die sich so einfach nicht beheben lässt - zumindest ist mir da kein Weg bekannt, der sich performancetechnisch relativieren lässt. schreibst du mit einer alpha auf die vorhandene textur, wird diese ja auch entsprechend übernommen. im script könntest du aber beispielsweise einen großen Rahmen in Weiß auf den Alphakanal der Scripttextur zeichnen, um die transparenzen zu entfernen - dann hast du allerdings einen Rahmen um die einzelnen Buchstaben. Hier hilft nur, den Background des Fonts an den Hintergrund des Displays anzupassen und gegebenenfalls durch verschiedene Fonts durchzuschalten, je nach Hintergrundfarbe.


    Rein technisch gäbe es auch dafür eine Lösung: Zwei Scripttexturen. Dazu erstellt man zwei Scripttexturen gleicher Größe und nutzt wie bei den VMatrizen einen "Pixelcursor", um Pixel für Pixel von der einen Textur in die andere zu übertragen.
    Ist die Ausgabe von STReadPixel an Position X/Y in den RGB Werten kleiner als 50, wird der Pixel ignoriert, ist er größer als 50 (oder ein beliebiger selbst definierter Schwellenwert) wird der Pixel von der einen auf die andere Scripttextur übertragen.

    Den gleichen Effekt erzielst du, indem du die Font-Bitmap aufmachst, den Kontrast-Regler voll aufdrehst und mit dem Helligkeits-Regler etwas nachjustierst. Erzielt den gleichen Effekt, aber ohne Rechenaufwand und Script-Dschungel auf Omsi-Seite.

    Naja, das frisst ja dann im Prinzip die kompletten Alpha-Werte weg, die Schrift sieht damit unschön aus. Habe es jetzt trotzdem mal in OMSI ausprobiert, aber von nahem sieht man es leider doch gut. Die einzigen Möglichkeiten sind für mich daher nur, wirklich alle Fonts mit Farbbitmap, die die richtige Schrift- und Hintergrundfarbe enthält, zu versehen und dann in OMSI ohne Vollfarbe schreiben zu lassen oder einfach [matl_transmap] beizubehalten.

    Wenn dein Hintergrund komplett schwarz ist, kannst du die weichen Kanten über die Alpha-Bitmap sichtbar machen, indem du die entsprechenden Pixel auf der Alpha-Map auf komplett weiß stellst. (Text-Bitmap mit Kontrast und Helligkeit voll aufgedreht als Alpha-Bitmap, evtl. Nachbesserungen)

    Soviel zum Thema "OMSI stirbt" - freut mich, dass immer noch fähige Leute mit guten Ideen hier rumrennen! :D

    Also das Konzept funktioniert, aber sowohl bei .tga, .png als auch bei .bmp als Texturformat für den Hintergrund kriege ich haufenweise Fehlermeldungen, die dazu führen, dass keine Skripttextur generiert wird und die FPS stark runtergehen. Wenn ich die Zeile auskommentiere, die den Hintergrund auf die Skripttextur malt, dann gibt es keine Fehlermeldungen. Auch der 4GB-Patch hilft da leider nicht. Kommt das evtl. jemandem bekannt vor oder weiß jemand, woran das liegen könnte? Die Textur ist übrigens 2048x1024 groß.

    Code
    257 18:21:08 -  -   Error:           Zugriffsverletzung bei Adresse 005D6BAB in Modul 'Omsi.exe'. Schreiben von Adresse 38BAAC60: CV.Calculate - J3 (vehicles\MB_C2_EN_BVG\MB_C2_E6_Solo_BVG.bus)

    258 18:21:08 -  -   Error:           Systemfehler.  Code: 8.

    Zur Verarbeitung dieses Befehls sind nicht genügend Speicherressourcen verfügbar: CV.Calculate - J3 (vehicles\MB_C2_EN_BVG\MB_C2_E6_Solo_BVG.bus

    Wie schaut der Code dafür genau aus? Einen solchen Fehler mit Speicherproblemen habe ich bisher nur aktiv herbei provozieren können, wenn ich in einer Font die Koordinaten nicht richtig eingetragen habe und die Zeichen "über die Bitmap herausgeragt" haben.


    Hast du vorher mit STNewTex die Scripttextur initialisiert?

    Der erste Teil ist ein Ausschnitt aus dem Frame. Die Funktion TFT_Monitor_Display_change setzt die Variable TFT_Monitor_texture. Falls nötig, kann ich auch das komplette Skript reinstellen.

    versuchst du eventuell, Pixel an einen Ort außerhalb des Texturespaces zu schreiben?

    Ich sehe jetzt nichts auffälliges in dem Schnipsel, bis auf das STSetColor, das vor dem LoadTex kommt. Das habe ich in der Konstellation bisher noch nie gesehen und auch nicht selber verwendet. Schiebe das mal unter den LoadTex-Block.

    Ansonsten probiere mal, die Textur alleine zu zeichnen.

    Das Problem wurde gelöst. Ich hatte die bmp-Texturen als 32-bit abgespeichert, es geht aber nur mit 24-bit, da hatte OMSI etwas Probleme beim Lesen. Aber viel entscheidender waren die ST-Macros.
    Zuvor war es vom Ablauf her:

    (M.V.STNewTex)

    (M.V.STLock)

    (M.V.STLoadTex)

    (M.V.STTextOut)

    (M.V.STUnlock)

    (M.V.STFilter)



    nun ist es:

    (M.V.STLoadTex)

    (M.V.STLock)

    (M.V.STTextOut)

    (M.V.STUnlock)

    (M.V.STFilter)

    (M.V.STLock)

    (M.V.STUnlock)

    (M.V.STFilter)



    Ob es nötig ist, die Textur doppelt zu filtern, weiß ich nicht, aber alles davor ist auf jeden Fall relevant und entscheidend. Es scheint so, also würde man (M.V.STLoadTex) sozusagen genau wie (M.V.STNewTex) benutzen. (M.V.STSetColor) ist übrigens auch nicht nötig gewesen.


    EDIT: Es ist zmd. in meinem Fall nicht nötig, am Ende noch ein zweites Mal rendern zu lassen, es reicht also (M.V.STUnlock) und (M.V.STFilter) nach dem Beschreiben.

    Einmal editiert, zuletzt von Entdecker666 () aus folgendem Grund: Neue Erkenntnis angefügt