4. Schon wieder Farben in DIRECTX

Schon wieder Farben in DIRECTX

  • N

    Ich verstehe die Welt nicht mehr. Mit DirectDraw hatte ich keine Probleme. Ich habe das Farbformat rausgefunden und mit einer Funktion (ähnlich aus dem XGameSDK) die Farben berchnet. Das lief auch mit 565 und 555 Formaten.

    Jetzt bin ich dabei mit Direct3D7 zu programmieren und habe Probleme bei der Farbberechnung. Die Farbe sind Falsch. Ob im 16Bit oder 32Bit.

    Wie macht ihr das. Benutzt ihr auch eine Funktion oder macht ihr das mit die Makros aus dem DirectX SDK?

    Ist die Berechnung unter D3D anders als unter DirectDraw?

    [ Dieser Beitrag wurde am 13.04.2003 um 23:05 Uhr von Netzwerk-Latenz editiert. ]

    0
  • T

    In Direct3D arbeitet man grundsätzlich mit 32-Bit-Farbangaben. Die Grafikkarte rechnet die dann entsprechend um. Es gibt da z.B. das Makro D3DCOLOR_XRGB. Das einzige, wo Du wirklich aufpassen musst, ist, wenn Du direkt auf eine Textur/Surface schreibst. Dann müssen die Farbangaben schon dem Format der Textur/Surface entsprechen. Ansonsten verwendet Direct3D ja auch häufig Farben, die aus vier float-Werten zusammengesetzt sind (Materialien, Lichter). Da steht jeder Wert für eine Farbkomponente und kann normalerweise Werte zwischen 0 und 1 annehmen (obwohl bei Lichtern und Materialien auch negative Werte oder Werte über 1 möglich sind).

    0
  • N

    Jetzt wird mir einiges klar. Wenn D3D 32Bit verwendet gibt es keinen Grund es selber umzurechnen. Warum sagt mir das keiner 😃

    Dann könnte ich ja gleich sowas machen 🙄 😃

    return long)((16711680 * r )) &16711680)+
            ((long)((65280 * g )) &65280)+
            ((long)((255 * b )) &255);

    Und es währe egal ob es jetz 16Bit ist oder 32Bit.

    0
  • T

    Ja, ist ganz egal.

    0
  • F

    Nimm aber lieber Bitshifts oder die Makros des DXSDK 🙄

    0
  • N

    @flenders

    war nicht ernst gemeint. 🙂

    EDIT: Meine Funktion arbeitet auch mit Bitoperation. 🕶

    [ Dieser Beitrag wurde am 14.04.2003 um 10:25 Uhr von Netzwerk-Latenz editiert. ]

    0
  • R
    Mod

    Original erstellt von Netzwerk-Latenz:
    **Jetzt wird mir einiges klar. Wenn D3D 32Bit verwendet gibt es keinen Grund es selber umzurechnen. Warum sagt mir das keiner 😃

    Dann könnte ich ja gleich sowas machen 🙄 😃

    return long)((16711680 * r )) &16711680)+
            ((long)((65280 * g )) &65280)+
            ((long)((255 * b )) &255);

    Und es währe egal ob es jetz 16Bit ist oder 32Bit.**

    wie kommst du nur auf diese __krassen__ werte? 😃

    und wenn du b*255 rechnest und dann &255 verknüpfst, ist das nicht leicht sinnlos? 😉

    einfacher (r<<16)|(g<<8)|b ... je nach farbformat anzupassen natürlich

    (wie schon von flenders erwähnt)

    rapso->greetS();

    0
  • F

    Zum Glück bin ich nicht der einzige, der auf seinen Scherz reingefallen ist 😉
    Btw sind doch Faktoren etwas sehr eigenartig 😃

    0
  • N

    @rapso

    nein es ist nicht sinnlos.

    16711680 ist die Farbe Rot. Die Funktion soll mit Weten zwischen 0..1 Arbeiten.

    r=0.4
    16711680r=40%von Rot
    (16711680    r)&1671160 (Farbmaske für Rot)

    ist der Wert in unsigned long für Rot.

    PS: Wie gesagt war es nicht ernst gemeint. Obwohl es funktionieren würde.

    Für den Computer ist es egal ob 16711680 oder 0xFF0000 oder 111111110000000000000000

    [ Dieser Beitrag wurde am 14.04.2003 um 10:32 Uhr von Netzwerk-Latenz editiert. ]

    0
  • R
    Mod

    du hättest zwischen 0 und 255 haben müssen und dann *65536 rechnen.

    so wie du das machtst.. naja, alleine schon durch das konvertieren deiner konstanten in floats verlierst du schon einiges, jetzt weiß ich wenigstens weshalb du da soviel umrechnungen machen mußt....

    😃

    rapso->greets();

    ps. ja verars*ht hat er uns :D:D:D

    0
  • N

    Ich habe es jetzt ausprobiert. Es funktioniert sogar. Im 16Bit und im 32Bit Modus 🕶

    0
Anmelden zum Antworten