Les couleurs héxadécimal

[Lucifer]

BOnjour,

Je cherche un moyen de générer n'importe quel couleur héxadécimal pour pawno, de ce genre : 0xB4B5B7FF

Merci de votre aide. :)

[robyn59]

il y a avais un site mais il est OFF, domage car il server souvent

[Tux]

Salut :),

Color Picker par UZI-I permet de prendre des Couleurs Héxadécimals :). J'utilise souvent ce petit logiciel, jamais déçu ;).

++
Tux

[Syg]

Il veut le faire par script, pas en allant sur le net.

Voilà qui devrait t'aider Lucifer :

Code: [Sélectionner]

new Col;
Col = (random (0xFFFFFF) << 8) + 0xFF;
Ceci donne une couleur aléatoire avec la composante Alpha toujours à 0xFF.

++
Syg

[Tux]

Erf j'ai dû mal comprendre xP.

[Syg]

Alors j'explique :

random (0xFFFFFF) donne un nombre compris entre 0 et 0xFFFFFE (donc par exemple 0xAE450F).
Ceci correspond aux composantes R, V et B de notre couleur (dans l'exemple, R=0xAE=174, V=0x45=69 et B=0x0F=15)
Mais ce nombre ne peut pas être utilisé directement dans SAMP car il lui manque la composante Alpha (la transparence).
Et il ne faut pas choisir aléatoirement la composante Alpha (sinon, on risque de ne pas voir certaines couleurs).

Cette composante alpha correspond au dernier octet de notre couleur.
Donc pour pouvoir ajouter cette octet à la fin de notre nombre, on va décaler ce nombre d'un octet (8 bits) vers la gauche (<<)
Soit random (0xFFFFFF) << 8
Nous avons maintenant un nombre compris entre 0 et 0xFFFFFE00 (mais qui se termine toujours pas 00).
Si on reprend l'exemple, on obtient 0xAE450F00.

Pour que la couleur ne soit pas totalement transparente, il faut que la composante Alpha soit > 0.
Donc on ajoute cette composante (+0xFF)
Soit (random (0xFFFFFF) << 8) + 0xFF
On obtiendra 0xAE450FFF avec notre exemple.

++
Syg

[S!m]

Salut,

petite question Hors sujet pour Syg:

adns ce cas bien précis,
Quelle méthode est théoriquement plus rapide entre une addition et un test OU inclusif bit à bit?

(en code: faire (random(....) << 8) | 0xFF au lieu de random(...) << 8 + 0xFF)

++Sim++

[Syg]

Théoriquement, je n'en sais rien, ça dépend de beaucoup de facteurs (compilateur, OS, processeur).
Le mieux c'est de tester :

Code: [Sélectionner]

new i;
new T, T1;
new Col, Col2;

T=GetTickCount ();
for (i=0 ; i<10000000 ; i++)
{
Col = (random (0xFFFFFF)<<8)+0xFF;
}
T1=GetTickCount ();
printf ("Temps 1 : %d", T1-T);

T=GetTickCount ();
for (i=0 ; i<10000000 ; i++)
{
Col = (random (0xFFFFFF)<<8)|0xFF;
}
T1=GetTickCount ();
printf ("Temps 2 : %d", T1-T);
Résultat :
[09:53:25] Temps 1 : 662
[09:53:26] Temps 2 : 701

L'addition semble donc plus rapide que le OU inclusif sur ma machine (Windows XP, Core2 Duo). Il n'est pas sûr que ce soit le cas sous Linux (mais l'absence de GetTickCount ne permet pas de faire ce test).
Mais bon, le test porte sur 10 000 000 de calculs pour une différence de l'ordre de 40 ms. On peut donc considérer que c'est négligeable dans les conditions d'utilisation normale de ce calcul (1 fois par connexion d'un joueur).

++
Syg