kYp escribió:Hermes eso de pasar de un color a otro de forma difuminada estaria bien que lo explicases si no es mucho pedir :D
Bueno, es de esas cosas que deberiais esforzaros en deducir, en vez de buscar rutinas que han hecho otros... :p
La idea es que utilizamos un factor, que llamaremos Alpha que es el que controlará la mezcla.
Digamos que ese valor Alpha, puede variar de 0 (donde se mostraria el primer color a mezclar) a 255 (donde se mostraria el segundo color)
Si te paras a pensarlo un poco, te das cuenta que ese valor Alpha, en realidad está controlando la "fuerza" que tiene el color 2 y que hay otro factor oculto, antagonico a Alpha que es el que controla la fuerza del color 1.
Obviamente, los colores se mezclan separando los componentes R, G y B y mezclandolos por separado, para posteriormente, juntarlos en un color nuevo.
Es decir, que si quisieramos mezclar el componente rojo de ambos, utilizando un factor Alpha que variase de 0 a 255, la formula sería así:
R=(R1*(255-Alpha))/255+(R2*Alpha)/255;
Y asi con el verde, y el azul tambien.
Si te fijas, se multiplica por un factor variable entre 0 y 255 y se divide entre 255, lo que equivaldría a multiplicar por un factor en punto flotante, entre 0.0f y 1.0f.
Un detalle interesante, es que esta formula no necesita comprobacion de limites, pues la 'mezcla' siempre va a estar en el rango de colores correctos
Si ahora me vas a preguntar como se extraen los componentes de color... si hablamos de PSP con el modo de color de 16 bits, la formula, seria la siguiente
unsigned short color=0xffff; // blanco, codificado en 16 bits
R=color & 31; // el rojo va de 0 a 31
G=(color>>5) & 63; // si, el verde va de 0 a 63
B=(color>>11) & 31;// y el azul de 0 a 31
Para empaquetarlo de nuevo, sería:
color=(B<<11) | (G<<5) | R;
Facil ¿no? ;)
Ahora un par de consejillos:
El primero, es que tengais cuidado de aseguraros de que al realizar la operacion de multiplicacion, los numeros "caben" en la variable que estais tratando y si hace falta, añadir un cast tipo (unsigned) (mas vale pecar de añadir algo innecesario, que lamentarse)
El segundo es que dado que una division entre 255, es mas indigesta para la CPU que una division entre 256, utilizando un desplazamiento (>>8) y la perdida de resolucion es de solo 1/256 (una mierda, vamos), sería mas interesante utilizar esta formula, por cuestiones de velocidad:
R=((R1*(255-Alpha))>>8)+((R2*Alpha)>>8);
Ah! Sería interesante que os fijarais, de que este tipo de mezcla, se puede usar para otras cosas, como por ejemplo, hacer una transicion entre dos ondas de audio para que una fuera decreciendo mientras la otra va creciendo (en este caso, se operaria con los samples)
PD: Espero que alguno se haya dado cuenta, de que este metodo sirve igual para hacer un fundido en negro u otro color, o para dibujar un sprite semitransparente en pantalla
Saludos.
