4. COLORREF to GLubyte

COLORREF to GLubyte

  • A

    Hallöchen,

    Wie komme ich vom Windowscolor Typ (COLORREF==32Bit)
    zun opengl Rarbe typedef struct{
    GLubyte c1;
    GLubyte c2;
    GLubyte c3;
    GLubyte c4;
    }color;

    Da beide Datentypen 32Bit belegen, habe ich mir eine kleine inline Assembler Funktion gemacht die mir die 32Bit auf die 32Bit der Struktur schiebt.
    Das ganz funzt auch nur habe ich bedenken ob das so rechtens ist weil auch Assembler für mich völlig neu ist.
    Hatte jemand schon ein ähnliches Problem? Wie würdet ihr das machen?

    typedef struct{
GLubyte c1;
GLubyte c2;
GLubyte c3;
GLubyte c4;
}color;  

color RGBtocolor(COLORREF* WFarbe);

Engiene::color Engiene::RGBtocolor(COLORREF* WFarbe)
{
//color RGBFarbe=(*WFarbe);

color RGBFarbe;

_asm
{
mov	eax, DWORD PTR WFarbe
mov	ecx, DWORD PTR [eax]
mov	DWORD PTR RGBFarbe, ecx
}

return RGBFarbe;
}
    0
  • S

    WTF??!?? 😮 😕

    0
  • P

    GetRValue, GetGValue, and GetBValue macros

    0
  • A

    Mal ein Beispiel:

    ich erhalte den Wert COLORREF WFarbe aus einem Farbdialog.
    Wie bekomme ich jetzt mit den Macros das auf elegantem Wege in die Struktur?

    0
  • P

    Also erstmal: COLORREF als Zeiger zu übergeben ist unnötig, beides 32-Bit, Im Gegeneteil bei 64-Bit Adressen ist der Zeiger sogar aufwendiger^^.

    typedef struct{
GLubyte c1;
GLubyte c2;
GLubyte c3;
GLubyte c4;
}color; 

color RGBtocolor(COLORREF WFarbe)
{
    color c;
    c.c1 = GetRValue(WFarbe);
    c.c2 = GetGValue(WFarbe);
    c.c3 = GetBValue(WFarbe);
    c.c4 = 1;
}

    Ich hoffe mal c1 ist jetzt rot, c1 ist ... usw. ^^
    Ist nicht die eleganteste Lösung aber funktioniert und ist übersichtlich.

    Allerdings fällt mir grad ein: COLORREF geht von 0-255, OpenGL arbeitet von 0-1, du musst das also vorher noch umrechnen

    0
  • A

    Ups sorry hab’s schon kapiert. Alle Unklarheiten beseitigt.

    Ich würde mich aber freuen wenn sich noch Jemand zu meiner Assemblerfunk äußern könnte,
    ob der Weg trotzdem praktikabel ist oder ob irgendwas dagegen spricht das so zu machen.

    0
  • P

    siehe Post vorher, die Umrechnung fehlt

    0
  • A

    Hm bist du dir das sicher?
    Mal ein anderes Beispiel:

    Für eine Pickingfunktion rendere ich alle Triangles mit einer fortlaufenden Farbnummer kurzzeitig in den Buffer. Um dann mit der Api-Funktion „COLORREF Getpixel()“ die Farbe am Mauscursor. abzulesen.

    Dabei verwende ich ein Array und den Colorpointer :
    glColorPointer(3,GL_UNSIGNED_BYTE ,sizeof(Triangle),&ARR.DWCOLOR) );

    DWCOLOR ist wie der Name schon sagt ein DWORD das ich über einen long mit einer fortlaufenden Farbnummer füttere (infach Farbnummer++) .

    Wenn OGL jetzt die drei UNSIGNED_BYTE als nur bis 1 interpretieren würde dann müsste mir die Funktion „COLORREF Getpixel()“ ja Schrott zurück liefern das macht sie aber nicht.
    Wenn ich COLORREF als long interpretiere bekomme ich exakt die Farbnummer die ich in DWCOLOR gepackt habe .

    So um es noch mal kurz zu machen ich wollte an diesem Beispiel zeigen das OGL
    dann doch so interpretiert:
    3xGL_UNSIGNED_BYTE als 3x255 und nicht als 3x1.

    Du hast mich jetzt aber gewaltig verunsichert nicht das ich den ganzen Kram noch mal überdecken muss?
    Oder habe ich da irgendwo einen Denkfehler gemacht?

    0
  • P

    also ich arbeite immer mit glColor4f oder glColor4fv, und da gehts von 0-1

    0
  • A

    Ja hat sich schon geklärt ,
    alle „UNSIGNED_BYTE“ Sachen werden mit 255 interpretiert
    alles anderen Datentypen dann bis 1 wie du schon beschrieben hast.
    Man muss allerdings auch bei GetRValue und co. noch umrechnen wenn ich das auf die schnelle richtig getestet habe ,da wird ebenfalls ein Wert von 0-255 geliefert.

    0
Anmelden zum Antworten