¿Cómo hacer durezas en 16 bits?

[Rivroner]

Pue seso compaelro dle Fenix, qeu etengo como ejmplo el Dr.Malvado y las durezas en 8 bits ya las tengo controladillas pero el tema está en que mi juego en 8 bits queda muy mal porque tiro de trasnformar y retocar imágenes, no sé dibujar y no hay manera.

Si un FPG lo convierto a 16 bits ya no me detecta las durezas. :D

Siguiendo como ejemplo las durezas del Dr.Malvado en 8 bits, ¿qué he de modificar para meterle durezas en 16 bits con un FPG de 16 bits?

Que paquete soy dios mío. [wei2]

[Segata Sanshiro]

No es que seas un paquete :p es que el tema de durezas en 16 bits se complica bastante. Lo que deberías hacer es tener primero varias variables, por ejemplo:

int colorPared;
int colorSuelo;
int colorTecho;

o las que sean necesarias para tu juego (a lo mejor solo necesitas una en plan colorDureza porque no te hace falta distinguir entre suelo o techo, o lo que sea, no me he leído cómo funciona el Castle of Dr. Malvado).

Luego inicializas esas variables. Con map_get_pixel tienes que leer en un lugar del mapa donde sepas seguro que hay una dureza del tipo que necesitas, y guardas el valor en la variable correspondiente. A partir de entonces, ya en el juego, sigues leyendo con map_get_pixel y comparas con los valores que hay en colorDureza, colorPared, etc. Así ya debería funcionar.

[hardyx]

En el curso de Fénix te viene como manejarlas, en el capitulo de "Hacer un juego RPG". El problema con los 16 bits, es que cada dispositivo codifica los bits de color de manera diferente. Por eso hay que obtener el color de cada zona que uses.

[Hokutoy]

Seguramente no te funciona por lo que te dice Hardyx. Para que te hagas una idea un color ROJO en un mapa de durezas dentro de un fpg de 8 bits te da con un map_get_pixel=255 (por ejemplo).
El mismo mapa, con el mismo color ROJO dentro de un fpg de 16 bits te dará con map_get_pixel=2566955 (por poner otro ejemplo).
Haz la comprobacion/toma de color desde dentro del programa y así nunca tendras problemas a la hora de codificar el color.

[animanegra]

hay dos funciones map_get_pixet y get_rgb con esas dos ya puedes obtener los colores en 16 bits. El tema esta en que ahora en lugar de usar el "colorrojo == 255" usa algo relativo como por ejemplo "> 240". La codificacion por falta de espacio en los 16 bits hace ese tipo de errores.

http://fenixworld.se32.com/fenixwiki/index.php?title=GET_RGB

corto y pego de aqui:

"Sin embargo, debido a la diferencia de precisión entre modos gráficos y tarjetas gráficas, no es posible determinar de antemano cual es el valor exacto que se obtendrá. Por ejemplo, incluso un color blanco puro seguramente obtendrá valores como 242 o 248 en sus componentes, en lugar de 255 como sería de esperar. Hay que tener en cuenta que para almacenar los 256 valores posibles serían necesarios 8 bits de precisión. Sin embargo, en un modo de 15 ó 16 bits sólo habrán 5 ó 6 bits de precisión disponibles por cada componente."

RTFM!! :P es broma

[kennyspirit]

pe***das.com, ala a hacer durezas

perdonad el flood pero he escupido a la pantalla de la risa xD

[Rivroner]

Muchas gracias famigos, me miraré eso.

[Drumpi]

El método más sencillo es que uses los pixels de la esquina superior izquierda para definir los distintos tipos de durezas, es decir:
-en el pixel 0,0 pinta con color de suelo.
-en el pixel 1,0 el de las paredes.
-repetir con todas las durezas.
-haz map_get_pixel y lo guardas en variables.

La diferencia con 8 bits es lo comentado: mientras en 8 bits manejas 256 colores, en 16 manejas 2^16 colores, y encima, el ID de color que te da map_get_pixel devuelve ditintos colores con get_rgb según la tarjeta gráfica.

[swapd0]

¿No se pueden mezclar los fpg de 16 bits para los graficos con uno de 8bits (o menos) para el mapa de durezas?

[Rivroner]

¿Te refieres a hacer un fpg con los gráficos que sean de 16 bits y otro fpg de 8 bits con los de 8 bits? Eso no lo he probado, pero igual se puede, lo que ya no sé es si las colisiones las detectará bien.

Loq eu he intentado ha sido meter en un fpg de 16 bits los gráfico sde 8 bits y lso de 16 y ambos lso dej atal cual, pero una vez cargas el programa no detecta bien durezas y el negro que antes era negro ahora es transparente.En un fpg de 8 bits el negro se ve negro. :D

[Drumpi]

NO se pueden mezclar mapas de 8 y 16 en un mismo FPG, porque el FPG define la profundidad y, si es necesario, la única paleta que pueden usar todos ellos (se puede cargar su paleta con load_pal).
Y si, podeis tener FPGs de distinta profundidad de color en memoria, siempre que el modo de video sea mayor o igual que el de mayor profundidad (podeis tener FPGs y MAPs de 256 colores y 16 bits en modo 16 bits, pero no uno de 16 bits cuando esteis con un set_mode(xxx,xxx,8)).
El modo 16 bits convierte los colores de los mapas de 8 bits automáticamente, pero haciendo un map_get_pixel sólo devolverá un valor entre 0 y 255.

Si meteis un gráfico de 8 bits en un FPG de 16, FPGEdit lo convierte de manera automática en mapa de 16 bits, y viceversa.

[BMB]

Siento reflotar el hilo, pero era para comentar que el resultado de map_get_pixel en modo 16 bits va a ser siempre el mismo, tanto en wiz, como pc, eeepc, etc ;)

[Rivroner]

Gracias por el dato. :)

[Drumpi]

Lo que cambia es la conversión nº_pixel<->RGB según la tarjeta de video.

[SplinterGU]

Lo que cambia es la conversión nº_pixel<->RGB según la tarjeta de video.

Drumpi, no se que quieres decir, pero me suena que eso no pasa con bennu... no deberia pasar... una cosa es que setees un pixel con un rgb y al leerlo nuevamente te de otro rgb, eso es posible por la precision, pero mas alla de este detalle, no deberia haber ninguna otra diferencia... o sea, que si lees un rgb de un pixel, ese rgb te dara el mismo valor, aqui, alla o en el polo norte...

[Drumpi]

A menos que hayas hecho radicales cambios en las librerías gráficas, desde fenix la cosa está así:

NT GET_PIXEL ( INT x, INT y )
Esta función recupera el color de un pixel determinado del fondo de la pantalla. Las coordenadas dadas crecen hacia abajo y a la derecha, y el punto (0, 0) representa la esquina superior izquierda de la pantalla.
En el caso del modo gráfico de 256 colores (8 bits), el valor devuelto por esta función es un color de 0 a 255. En el caso del modo de 16 bits, el valor devuelto es una codificación de las componentes del color que depende de la tarjeta de vídeo y el modo gráfico.

Fuente: ayuda oficial de Fenix 0.83.

Sinopsis

DWORD GET_PIXEL(INT x, INT y)
[editar]
Descripción

Esta función recupera el color de un pixel determinado del fondo de la pantalla. Las coordenadas dadas crecen hacia abajo y a la derecha, y el punto (0, 0) representa la esquina superior izquierda de la pantalla.

En el caso del modo gráfico de 256 colores (8 bits), el valor devuelto por esta función es un color de 0 a 255. En el caso del modo de 16 bits, el valor devuelto es una codificación de las componentes del color que depende de la tarjeta de vídeo y el modo gráfico.

Fuente: wiki de fenixworld.

[swapd0]

Porras ¿no seria mejor hacer una libreria para meter los mapas de durezas en un bitmap de n bits y asi ahorrar un porron de memoria y de quebraderos de cabeza?

[SplinterGU]

Porras ¿no seria mejor hacer una libreria para meter los mapas de durezas en un bitmap de n bits y asi ahorrar un porron de memoria y de quebraderos de cabeza?

????

no entiendo tu propuesta, no se hace ya eso?

[Drumpi]

Supongo que se refiere a mapas con profundidad de 3, 4 o 5 bits, según necesidad.
Pero no, mejor usar los de 8bits. Aunque sobren bits, las máquinas leen como mínimo los datos de 8 en 8 bits, usar menos podría ser complejo e ineficiente.
Aun está por ver el juego que necesite más de 256 durezas.

[swapd0]

Supongo que se refiere a mapas con profundidad de 3, 4 o 5 bits, según necesidad.
Pero no, mejor usar los de 8bits. Aunque sobren bits, las máquinas leen como mínimo los datos de 8 en 8 bits, usar menos podría ser complejo e ineficiente.
Aun está por ver el juego que necesite más de 256 durezas.

No tiene por que ser mas ineficiente, ya que al ocupar menos memoria hay menos probabilidades de tener fallos en la cache. Y por hacer una mascara y un desplazamiento no va a ralentizar mucho.

[SplinterGU]

no te creas, una mascara y un desplazamiento, puede relentizar bastante. pensa que no es 1 solo, sino que son muchos... ademas de calculos extra para obtener la direccion...