Hola
¿Sabeis si con Direct Draw se pueden hacer semitransparencias? Es decir que se vea una imagen y otra debajo, por ejemplo una pared q deje ver lo que hay detras.
¿Se puede modificar el color de una imagen para hacer que sea un poco mas negra o un poco mas azul? Esto seria para simular que anochece, dibujando el mapa pero un poco mas oscuro y azulado.
Hola,
Para lo del oscurecimiento lo que puedes hacer es modificar las paletas de las imagenes y para el alfa, con d3d se hace facilmente (pero para polis), si es con directdraw te lo tienes que currar tu a pelo.
Saludos,
Dame alguna pistilla de como hacer lo del Alpha a pelo porfa
¿Para utilizar paletas hay q trabajar con 8 bits? ¿Si utilizo imagenes q tenga 16, 24 o 32 bits para los colores puedo utilizar paletas?
Sólo puedes usar paletas con 8 bits, a partir de los 15 bits la info de los pixels en pantalla se codifica directamente con las componentes del color (por ejemplo, a 15 bits mismo, cada píxel se describe con 16 bits organizados más o menos así: 0BBBBBGGGGGRRRRR, es decir 1 bit sin usar, 5 bits para el azul, 5 para el verde, 5 para el rojo) con lo cuál para oscurecer la imagen tienes que cambiar todos los píxels.
Para lo del alfa sí te interesa más tener este tipo de formato pq puedes acceder directamente a las componentes de color de cada pixel. Entonces, básicamente lo que haces es:
Rojo_resultante = ( Rojo_1ª_imagen * alfa + Rojo_2ª_imagen * (MAX_ALFA - alfa ) ) / MAX_ALFA
Verde_resultante = ( Verde_1ª_imagen * alfa + Verde_2ª_imagen * (MAX_ALFA - alfa ) ) / MAX_ALFA
Azul_resultante = ( Azul_1ª_imagen * alfa + Azul_2ª_imagen * (MAX_ALFA - alfa ) ) / MAX_ALFA
con cada pixel (suponiendo que alfa está entre 0 y MAX_ALFA) Ten en cuenta alguna posibilidad de optimización (por ejemplo, si tu MAX_ALFA es múltiplo de 2, en vez de una división que usa bastantes ciclos de procesador puedes usar un desplazamiento a la derecha que es mucho más eficiente ;)
Ale, no te canses
Sync
Muchas gracias a ambos.
Entonces para oscurecer un mapa deberia leer el color de cada pixel de la superficie, modificar el color y volver a escribirlo. ¿no sera muy costoso?
Y para dibujar una superficie con transparencias lo mismo
Mmmm.... yo en un 486 lo hacía en 640x480 a 24 bits (por aquellos tiempos cuando aun no me había especializado en cosas de sonido, hace años XDDD) y conseguía un scroll parallax más o menos fluido con los bordes antialterados (todo hay que decir que en 24 bits puedes ir más rápido pq no necesitas separar las componentes ;)) o sea que ahora en un PIII a x MHz no creo que necesites ni siquiera optimizar el código :D
Te recomiendo en cualquier caso que, de usar este método, lo hagas en ensamblador. Te acelerará mucho el tema. Lo que sí me temo es que no tendrás una aceleración hardware que te ayude, si tiras por hacerlo de esta forma... :I
Pero bueno, ya sabes que tienes otras opciones... D3D, OpenGL... :)
Sync
PD: Sobre el tema del coste... una división es más costosa que una suma, pero si tienes que dividir tienes que dividir, es lo que hay ^_^'
PPD: Ale, un apunte curioso sobre la GameBoy Advance que me ha venido a la cabeza: el procesador que utiliza, el ARM7TDMI no tiene ninguna operación de división, u sea que hay que currarse el algoritmo (no es que lo haya descubierto ahora precisamente... aunque muchos de vosotros seguro que sí XDDD)
:o ostras no sabe dividir ? pero si eso lo enseñan en la EGB!!!! xDDD
bln para lo de oscurecer y aparentar que es de noche y tal... yo usaria otros dibujos... asi seguro que va mas rapido y no te tienes que currar lo de oscurecer/tintar los colores y posiblemente de mejores resultados :) Aunque claro, esta opcion solo vale si no quieres que la iluminacion vaya cambiando poco a poco.
Si, querria que fuera algo paulatino, q no se hiciera de noche ni amaneciera de golpe.
Ademas tambien haria fundidos a negro
Pos nada, te recomiendo que hagas las cosas a 24 bits (mucho más fácil de separar las componentes de color porque... ya están separadas y no hay que hacer nada XDDD) y sobre los efectos, no sé qué más decirte, creo que ya te lo he dicho todo ^_^'
Sync
En vez de dividir, conviertelo en multiplicación.
:?:
Será más rápido (aunque sea una nanosegundo xD) hacer 2 * 0,5 que 2 / 2.
Ok. Muchas gracias a todos. :D
He estado mirando la documentacion de las DirectX 7.0 para ver como se hace lo de leer un pixel de una posicion y lo de escribir un pixel. Lo hago bloqueando la superficie secundaria (en la que escribo antes de hacer el Flip) con la instruccion
Call supSec.Lock(rectDest, ddsdTemp, DDLOCK_WAIT, 0)
y leo y escribo con
color = supSec.GetLockedPixel(x,y)
Call supSec.SetLockedPixel(x, y, color)
y luego desbloqueo la superficie.
¿Es correcto o hay alguna otra forma mejor de hacerlo?
Los fps que consigo son 85, usando Direct Graphics un compañero del foro me comento que se debia a que estaba sincronizado con el refrescon del monitor y q cambiara el D3DPRESENT_INTERVAL_ONE que usaba por D3DPRESENT_INTERVAL_IMMEDIAT .
¿Hay en DirectDraw alguna instruccion similar para no estar sincronizado con el monitor y asi aumentar los fps?
NeLo, estamos offtopic ^_^
¿0.5? Obviaba este detalle, pero el copro de la AGB no tiene operaciones en punto flotante, también habría q implementarlo ;) (es q soy de la época anterior a los copros ^_^')
Sync
Hello :D
No sé mucho de DirectDraw, yo las semitrasparencias las hacía con 32 bpp a pelo.
Para lo de oscurecer los gráficos paulatinamente podría ser una solución hacer varias copias (oscurecidas en distintos grados) en memoria de los gráficos (claro está, si no hay gran cantidad de gráficos), u otra solución: se hace una sola copia y se van oscureciendo paulativamente. Además puedes sacarte algún algoritmo que no tenga que separar en componentes. Se me ocurre por ejemplo que si tienes el color en 32 bits, lo dividas entre dos haciendo un shr y le hagas un and 00EFEFEFh o algo así.
Son ideas...
¿Y por qué no el viejo truco de poner un quad negro semitransparente que ocupe toda la pantalla e ir opacando o transparentando (Nota del Autor: si no existen estos verbos, bienvenidos sean a mi Universo Particular) según las necesidades?
¿Y por qué no usar una "paleta"?
O sea, tener los sprites con su paleta (la clásica de toda la vida).
Crear una tabla con los valores de cada color de la paleta para el modo de video que se use y pintar mirando en esa tabla. Una "lookup table" de toda la vida.
Para cualquier efecto, se hace sobre la palete original y se vuelve la crear la susodicha tabla.
Normalmente, con 256 colores o menos se tiene bastante, y nada quita tener más. Lo que supone sólo calcular estos colores y no hacerlo para cada pixel.
Claro, esto no sirve para todo, pero par la mayoría de las cosas es perfecto. Así lo hago yo y me va de miedo.