modificaciones a mod_map para soporte de pngs de 24 bits con transparencias.

[SplinterGU]

el cambio de meterle la informacion del color transparente en 8bits me parece correcto, lo incluire.

gracias!

[FreeYourMind]

free... muy bueno tu comentario,  me rei un buen rato... gracias... ;)

O sea, te reiste de mi  :o

[FreeYourMind]

Felicidades Splinter, record de 3 revisiones en un día  ;D
Por cierto, eso de transparencias en 8 bits, me da un poco miedo de ver que todo lo antiguo sigue funcionando, modo 7, etc.

[SplinterGU]

free... muy bueno tu comentario,  me rei un buen rato... gracias... ;)

O sea, te reiste de mi  :o

jajaja, si, de lo despistado que estuviste, hablamos 1000 veces sobre los alphas (transparencias) a nivel pixel (32bits).

Felicidades Splinter, record de 3 revisiones en un día  ;D
Por cierto, eso de transparencias en 8 bits, me da un poco miedo de ver que todo lo antiguo sigue funcionando, modo 7, etc.

no cambia nada, solo cuando graba un png, pone en el la info del png guardado que el primer color de la paleta (tabla indexada de colores) es el transparente... cierto DCelso?

[DCelso]

cierto

[DCelso]

En cuanto al guardar, no crearía compatibilidades porque como guardas justo el mismo PNG que ahora podemos cargar, si lo vuelves a cargar verías el mismo PNG que guardaste y que podrías haber guardado con 32 bits.

De todas formas el guardar actual que tienes guarda la misma información que este pero añadiendo un byte más por pixel, yo veo más lógico no guardar un 32 bits ya que no tienes información de 32 bits porque la perdiste al convertirlo a 16, pero bueno  es un mal menor guardarlo en 32 o 24 , simplemente la diferencia radica en que ocupará más el PNG final, porque información tendrá la mismísima :D.

He visto también un ligero problemilla en el guardado actual en 16 bits que el mío también arrastra. Un png de 24 bits cargado en modo de 16 bits convierte todo color negro R=0, G=0, B=0 creado con tu editor de imágenes a R=0,G=0,B=8 (por el tema de poder usar 0 como transparente) y resulta que al guardarlo guarda R=0,G=0,B=8, así pues el png inicial no es el mismo que el png final y al cargarlo en tu editor de imágenes verás que no hay ningún pixel con  R=0, G=0, B=0. :D. El ejemplo lo puedes ver abriendo A24.png y salida24.png (adjuntos en el zip anterior que subí) con un editor de imágenes. Bueno, otro mal menor porque son muy parecidos :D.

Además con el nuevo formato PNG soportado pasa algo más, resulta que pierdes el color RGB que hay asignado a tratar como transparente (imagínate que pusiste el rojo puro R=255,G=0,B=0) ya que la carga actual busca todos los píxeles que tengan dicho color y le asigna el  R=0, G=0, B=0 (cero absoluto, osea 0) para que internamente bennu sepa que es el color transparente, así que al guardarlo, ya sea con tu guardar de 32 bits o con éste guardar nuevo guardas el R=0, G=0, B=0 (detrás del transparente) en lugar del original, (el R=255,G=0,B=0).

La solución para no perder ese color radicaría en insertar éste color en la estructura GRAPH de alguna forma, para que luego al hacer el save_png puedas reasignarlo y así tener la misma imagen que cargaste :D. Pero bueno es otro mal menor ya que como vas a tratarlo como transparente pues te da igual que en la nueva imagen tengas ahora el negro en vez del rojo detrás de tu color transparente :D.

Está claro que con todo en 32 bits esto no pasa :D, porque no hay trucos de por medio para mostrar transparentes :D.

[DCelso]

en PIXEL_FORMAT del BITMAP se usan todos estos valores?
    uint8_t  Rloss;
    uint8_t  Gloss;
    uint8_t  Bloss;
    uint8_t  Aloss;

    uint8_t  Rshift;
    uint8_t  Gshift;
    uint8_t  Bshift;
    uint8_t  Ashift;

    uint32_t Rmask;
    uint32_t Gmask;
    uint32_t Bmask;
    uint32_t Amask;

a lo mejor en alguno de estos se podría guardar la información del color que hay por detrás del transparente, solo necesitamos 24 bits.
o en
    int16_t * blend_table;   /* Pointer to 16 bits blend table if any */
de BITMAP.

O bien, crearle a BITMAP tres nuevos uint8_t llamados Rhidden,Ghidden,Bhidden, para guardar el color escondido detrás del transparente :D.

[FreeYourMind]

Me pierdo en tanta charla tecnica :)
Yo nunca he salvado un png con Bennu (ni sabia que se podia :)), lo que me interesa, es que al recorrer los colores estos sigan estando en el mismo sitio (tanto en 8 como 16 bits), no vaya ser que ahora, al cambiar un color por otro, ya no tengan el mismo indice, o me salgan colores distintos al cargar png's con las nuevas versiones de Bennu :)

[SplinterGU]

En cuanto al guardar, no crearía compatibilidades porque como guardas justo el mismo PNG que ahora podemos cargar, si lo vuelves a cargar verías el mismo PNG que guardaste y que podrías haber guardado con 32 bits.

De todas formas el guardar actual que tienes guarda la misma información que este pero añadiendo un byte más por pixel, yo veo más lógico no guardar un 32 bits ya que no tienes información de 32 bits porque la perdiste al convertirlo a 16, pero bueno  es un mal menor guardarlo en 32 o 24 , simplemente la diferencia radica en que ocupará más el PNG final, porque información tendrá la mismísima :D.

He visto también un ligero problemilla en el guardado actual en 16 bits que el mío también arrastra. Un png de 24 bits cargado en modo de 16 bits convierte todo color negro R=0, G=0, B=0 creado con tu editor de imágenes a R=0,G=0,B=8 (por el tema de poder usar 0 como transparente) y resulta que al guardarlo guarda R=0,G=0,B=8, así pues el png inicial no es el mismo que el png final y al cargarlo en tu editor de imágenes verás que no hay ningún pixel con  R=0, G=0, B=0. :D. El ejemplo lo puedes ver abriendo A24.png y salida24.png (adjuntos en el zip anterior que subí) con un editor de imágenes. Bueno, otro mal menor porque son muy parecidos :D.

Además con el nuevo formato PNG soportado pasa algo más, resulta que pierdes el color RGB que hay asignado a tratar como transparente (imagínate que pusiste el rojo puro R=255,G=0,B=0) ya que la carga actual busca todos los píxeles que tengan dicho color y le asigna el  R=0, G=0, B=0 (cero absoluto, osea 0) para que internamente bennu sepa que es el color transparente, así que al guardarlo, ya sea con tu guardar de 32 bits o con éste guardar nuevo guardas el R=0, G=0, B=0 (detrás del transparente) en lugar del original, (el R=255,G=0,B=0).

La solución para no perder ese color radicaría en insertar éste color en la estructura GRAPH de alguna forma, para que luego al hacer el save_png puedas reasignarlo y así tener la misma imagen que cargaste :D. Pero bueno es otro mal menor ya que como vas a tratarlo como transparente pues te da igual que en la nueva imagen tengas ahora el negro en vez del rojo detrás de tu color transparente :D.

Está claro que con todo en 32 bits esto no pasa :D, porque no hay trucos de por medio para mostrar transparentes :D.

la incompatibilidad que digo podria generar, seria sobre productos externos, por ejemplo, que yo hago algo en bennugd que genera png que alimentan a otro programa, prefiero no cambiar eso ahora, si antes generaba png de 32, que se sigan generando lo mismo, en todo caso se podria agregar una funcion adicional para esto, pero de momento no parece necesario.

de que se guarda un byte mas, estamos de acuerdo, como ya lo dije unos mensajes atras.

igual el cambio queda en el codigo comentado, para futuro aprovechamiento.

se lo del rgb008, y tambien que se pierde el color, y que se convierte, y que incluso si hay otro rgb008 previo, se perdera diferencias cual es cual, pero bueno, eso ya se comporta asi desde tiempos de fenix, lo se.

gracias.

[SplinterGU]

Me pierdo en tanta charla tecnica :)
Yo nunca he salvado un png con Bennu (ni sabia que se podia :)), lo que me interesa, es que al recorrer los colores estos sigan estando en el mismo sitio (tanto en 8 como 16 bits), no vaya ser que ahora, al cambiar un color por otro, ya no tengan el mismo indice, o me salgan colores distintos al cargar png's con las nuevas versiones de Bennu :)

siempre se convirtieron colores desde fenix, no vas a tener problemas con la visualizacion no te preocupes, si no los tuviste hasta ahora, lamentablemente en 16 bits es necesario hacer ese cambio.

[DjSonyk]

Rebuenas a todos,siento haber estado ausente tanto tiempo ^^,no lo leido del todo bien,pero DCelso me estas diciendo que se puede poner en transparente algo que ya este pintado?,lo digo porque tengo el editor de niveles atascado por eso mismo porque al "borrar",lo que realmente es que pone un cuadrado negro,y claro si te equivocas al dibujar algo y lo quieres borrar no lo borras realmente sino que dejas un cuadro negro y eso en un mapa para un scroll se veria los cuadritos negro.... me explico?
O va de otra cosa .... ^^

[DCelso]

pues no te entiendo, chico, lo siento, no se si está relaccionado con esto. Ponnos un ejemplo práctico corto de lo que te pasa a ver si veo la luz.
Y sí, si que puedes poner a transparente algo que se ve, pero solo en modo 32 bits, ya que no tocas el RGB del pixel sino su cuarta compontente alfa y variando este valor puedes hacer que se vea el color del pixel total o parcialmente (entremezclandose con los colores que haya por detrás) o nada (dejando ver los colores que haya por detrás).

[SplinterGU]

lo que hace el fix de DCelso, es poder definir cual color (solo 1) es el color transparente, luego cuando se carga el png en memoria ese color se reemplaza por 0 (transparente)

[DjSonyk]

A ver ,imaginate vas hacer el primer plano de un scroll con el editor ,(parte ladrillos) y te equivocas al poner un tile,el que esta en el aire en la imagen de arriba,al borrar lo que realmente ocurre esque se queda negro,vease en la imagen de abajo,el azul se supone que es el segundo plano,el cielo por ejemplo,pero como ves con el siguiente codigo no lo borro realmente si no que se crear un cuadrado negro que al ser el fondo del editor negro da la sensacion de que esta borrado pero no....

[code language="bennu"]
Este es el codigo que tengo para supuestamente borrar...
CapaAncho[CapaActual]=Graphic_Info(CapaGrafico[CapaFichero[CapaActual]],Capa[CapaActual].Graph,G_WIDTH);
CapaAlto [CapaActual]=Graphic_Info(CapaGrafico[CapaFichero[CapaActual]],Capa[CapaActual].Graph,G_HEIGHT);
MapaVirtual=Map_New(CapaAncho[CapaActual],CapaAlto[CapaActual],32);   //Crea un nuevo mapa Ancho,Alto,Profundidad del color
Map_Clear(0,MapaVirtual,RGB(0,0,0));
Fpg_Add(CapaGrafico[CapaFichero[CapaActual]],998,0,MapaVirtual);   // Añade el grafico de borrar al fichero
Map_Block_Copy(CapaGrafico[CapaFichero[CapaActual]],999,
(TileX*CapaAncho[CapaActual])+Scroll.X0,(TileY*CapaAltoCapaActual])+Scroll.Y0,998,0,0,20,20,0);
[/code]

[DjSonyk]

lo que hace el fix de DCelso, es poder definir cual color (solo 1) es el color transparente, luego cuando se carga el png en memoria ese color se reemplaza por 0 (transparente)

Ah vale ,muchas gracias Splinter tan amable y tan claro como siempre ,sigue asi   :P .
Yo por la informacción que e intentado leer,casi ni papa de ingles,creo que la solución seria que me hiciera una sentencia en la que primero deveria pintarlo por ejemplo de negro y luego con una mascara ya pasarlo a transparente pero me parece un poco lento,aun asi me baje el archivo para modificarle y aun no lo he tocado ,por eso mismo me parece un poco lento....
¿Recomendaciones para hacerlo yo mismo ?Si alguien tiene algo mas de informacion vendria bien,pues se podria usar tambien como un borrador de FOG de guerra en los juegos de estrategia por ejemplo....