[C++/win32] RGB kleur donkerder maken

[Verwijderd]

Ik heb een Owner Drawn Button gemaakt in de WIN32 API.
Dit heb ik gedaan, omdat ik de button van kleur wil laten veranderen.

Als de button nu bijvoorbeeld blauw gekleurd is en je klikt erop, dan wil ik
dat de kleur donkerder wordt.

De vraag is dus als volgt: Als ik een kleur heb van het type RGB,
is er dan een standaard C functie om daar de iets donkere COLORREF
van te verkrijgen ? Of is hier een standaard algoritme voor ?

[.oisyn]

je kunt toch gewoon de r, g en b compnenten kleiner maken

[curry684]

De makkelijkste:

C++:

COLORREF     l_HalfBright = (l_OriginalColor >> 1) & 0x7f7f7f;
COLORREF     l_MegaDark   = (l_OriginalColor >> 2) & 0x3f3f3f;

[ Voor 12% gewijzigd door curry684 op 11-12-2002 11:52 . Reden: React sucks ]

[Verwijderd]

Ok bedankt het werkt.
Even analyseren [correct me if I 'am wrong] in het geval can HalfBright:
je deelt de kleuren door 2
vervolgens alleen the LS-BYTE van de kleur overnemen.
Echter is mij dat niet helemaal duidelijk waarom dat precies is.

[KnoppenSpook]

ook een idee, omzetten naar HLS de L minder maken en omzetten naar RGB (zijn dacht ik standaar API's voor)

[Verwijderd]

Verwijderd schreef op 11 December 2002 @ 12:09:
Ok bedankt het werkt.
Even analyseren [correct me if I 'am wrong] in het geval can HalfBright:
je deelt de kleuren door 2
vervolgens alleen the LS-BYTE van de kleur overnemen.
Echter is mij dat niet helemaal duidelijk waarom dat precies is.

Hij deelt ze niet door 2, hij schuift het geheel 1 bit naar rechts zodat de lsb van het rood component de msb van het groen component word in geschoven, dat is toch niet helemaal de bedoeling dus die and ie er uit..

[Verwijderd]

Hij deelt ze niet door 2, hij schuift het geheel 1 bit naar rechts

What's the difference ?
Bitshift naar rechts is bij mijn weten delen door 2.
Code analyseren kan ik ook maar wilde gewoon een uitleg waarom het zo werkt.

[Krooswijk.com]

niet helemaal gedeeld door 2, maar "div 2" om precies te zijn...

[curry684]

Verwijderd schreef op 11 december 2002 @ 12:09:
Ok bedankt het werkt.
Even analyseren [correct me if I 'am wrong] in het geval can HalfBright:
je deelt de kleuren door 2
vervolgens alleen the LS-BYTE van de kleur overnemen.
Echter is mij dat niet helemaal duidelijk waarom dat precies is.

Ik deel wel door 2, ik schrijf het alleen expres anders: ik wil namelijk helemaal niet delen door 2 maar een bitwise shift naar rechts. En als het je om de bitwise shift gaat is het netter/duidelijker om die te noteren, de compiler maakt er achter de schermen toch wel hetzelfde van.

De veel langzamere edoch preciezere variant:

C++:

COLORREF ModifyBrightness(COLORREF p_Color, int p_Percentage)
{
return MakeRGB(max((GetRValue(p_Color) * p_Percentage) / 100, 255),
                max((GetGValue(p_Color) * p_Percentage) / 100, 255);
                max((GetBValue(p_Color) * p_Percentage) / 100, 255));
}

[curry684]

Da Snake schreef op 11 december 2002 @ 15:47:
niet helemaal gedeeld door 2, maar "div 2" om precies te zijn...

Kweetnie wat je zwetst, maar een bitwise shift naar rechts van 1 op een integer is echt wel een 'echte helemaal gedeeld door 2' hoor

[Krooswijk.com]

101 = 5
10 = 2
mis ik iets? of doet die compiler de mod 1 derbij ofzo?

[Soultaker]

Wat dacht je dat (5/2) was dan

[.oisyn]

Da Snake: 5 / 2 is toch gewoon 2
ik zie het probleem niet helemaal

of bedoel je dat er geen floating point waarde uitkomt? Maar dat hier ook niet het geval:

C:

float f = 5 / 2;

f zal nu gewoon 2 zijn

[Soultaker]

De topic title is trouwens nogal ongelukkig gekozen.
.oisyn is vervelend.

[ Voor 27% gewijzigd door Soultaker op 11-12-2002 21:22 ]

[.oisyn]

vind je?

[curry684]

Da Snake schreef op 11 December 2002 @ 20:17:
101 = 5
10 = 2
mis ik iets? of doet die compiler de mod 1 derbij ofzo?

Ik zal het belangrijkste woord in de zin nog een keer aanstippen:

curry684 schreef op 11 December 2002 @ 18:38:
Kweetnie wat je zwetst, maar een bitwise shift naar rechts van 1 op een integer is echt wel een 'echte helemaal gedeeld door 2' hoor

Het resultaat is ook een integer, dus getrunced naar 2

[Soultaker]

offtopic:
Wat is er trouwens met het gewijzigde-topic-titel-krijgt-sterretje-beleid gebeurd?

[Creepy]

curry684 schreef op 11 December 2002 @ 18:38:
[...]

Kweetnie wat je zwetst, maar een bitwise shift naar rechts van 1 op een integer is echt wel een 'echte helemaal gedeeld door 2' hoor

Op een integer wel ja. Maar de kleurwaarde bestaat uit 3 (eigenlijk 4) componenten. 8 bits R, 8 bits G en 8 bits B.
Er zullen dus van 2 kleuren een bit verschuiven naar een ANDERE kleur.

edit:
Pff.. en als ik ff opgelet had, dan had ik gezien dat die bits die van de ene kleur naar de andere verschuiven door de bitwise and netjes op 0 worden gezet
edit2:
En als ik echt wakker was geweest had ik gezien dat dit precies is wat Yarv ook al had vertelt

[ Voor 28% gewijzigd door Creepy op 12-12-2002 08:41 ]

[Olaf van der Spek]

curry684 schreef op 11 December 2002 @ 18:38:
Kweetnie wat je zwetst, maar een bitwise shift naar rechts van 1 op een integer is echt wel een 'echte helemaal gedeeld door 2' hoor

Alleen als de integer unsigned is, anders is het niet precies gedefinieerd.

[curry684]

OlafvdSpek schreef op 12 December 2002 @ 15:48:
Alleen als de integer unsigned is, anders is het niet precies gedefinieerd.

Grrrr 2e keer in een week dat ik terecht op m'n vingers wordt getikt

[.oisyn]

OlafvdSpek schreef op 12 december 2002 @ 15:48:
[...]

Alleen als de integer unsigned is, anders is het niet precies gedefinieerd.

in dit geval toch wel, aangezien je de msb eruit and. Dus dan maakt het niet uit of het een arithmatic of logical shift right betreft, aangezien een eventueel sign extende bit toch op 0 gezet wordt

[Olaf van der Spek]

.oisyn schreef op 12 December 2002 @ 16:38:

[...]


in dit geval toch wel, aangezien je de msb eruit and. Dus dan maakt het niet uit of het een arithmatic of logical shift right betreft, aangezien een eventueel sign extende bit toch op 0 gezet wordt

Fout ;->
Het gaat niet om het sign-bit, maar om de afronding. Die kan als het resultaat negatief is zowel naar boven als naar beneden plaats vinden (bij /, niet bij >>), afhankelijk van de processor architectuur.

[ Voor 3% gewijzigd door Olaf van der Spek op 12-12-2002 16:47 ]