Tratamiento de archivos PNG en BennuGD

[Prg]

hola
se que ya casi no es el tema de esto, pero he preparado un código para brincarnos la restriccion de que el color 0 sea el transparente... aunque se necesita primero cargar una paleta válida (con el color transparente como posición 0).

[code language="bennu"] import "mod_text";
import "mod_grproc";
import "mod_video";
import "mod_map";
import "mod_screen";
import "mod_rand";
import "mod_say";
import "mod_mouse";
import "mod_dir";
import "mod_math";
import "mod_proc";
import "mod_string"
import "mod_key";
import "mod_draw";
import "mod_time";
import "mod_sound";
import "mod_wm";
import "mod_regex";
import "mod_file";
import "mod_sys";
import "mod_blendop";

type mic;
byte rojo;
byte azul;
byte verde;
end
global
pal1;
fondo;
begin
set_mode(800,600,32);

fondo=new_map(800,600,32);
map_clear(0,fondo,rgb(200,150,120));
put_screen(0,fondo);
pal1=load_pal("default.pal");
graph=load_png("grafico.png");
convert_8_8(0,graph,0,graph,pal1);
x=400; y=300;
loop
if (key(_esc)) exit(); end
frame;
end
end




function convert_8_8(file1,graph1,file2,graph2,pal2);
private

        temp_graph;
        anc,alt;
        mic colors[256];
        paleta[256];

        pal1;
begin

anc=graphic_info (file1, graph1, g_wide );
alt=graphic_info (file1, graph1, G_HEIGHT   );
temp_graph=new_map(anc,alt,8);
pal1=PAL_MAP_GETID(file1, graph1);
pal_map_assign(0,temp_graph,pal2);
map_put(0,temp_graph,graph1,anc/2,alt/2);
PAL_GET(pal1,0, 256, &colors);
say(colors[z].rojo +","+colors[z].azul+","+colors[z].verde);
say(find_color(colors[z].rojo,colors[z].azul,colors[z].verde));
from z=0 to 255;
paleta[z]=find_color(colors[z].rojo,colors[z].azul,colors[z].verde);


end
convert_palette(0,temp_graph,&paleta);

fpg_add(file2,graph2,file1,temp_graph);
unload_map(0,temp_graph);
end[/code]

[SplinterGU]

jejeje, en 8 bits, la posicion 0 es el color 0.

[Prg]

je je je
si, tienes razón,
pero lo anteriro es buena idea, no? si tienen problemas con sus gráficos, que los carguen como en el ejemplo anterior y listo, tomará la coloración más parecida a la original...  :)

oye, find_color sobre qué paleta trabaja? sobre la primera que se carga o cómo está ??? es que algunas veces parece que lo entiendo y otras nomás no... je je je

[DCelso]

Gracias, PRG por el ejemplo, yo por mi parte no lo veo práctico, pero oye ahí está como ejemplo :D.
Yo lo que he sacado de conclusión es que hay que evitar trabajar con imágenes PNG de 24 bits de color.
Y también evitar de trabajar con profundidad de 8 bits en BennuGD.

Lo suyo, claro hablo siempre en programación para pc, es trabajar siempre con bennu en 16 o 32 bits.
Usar imágenes PNG de 8 bits sin transparencias y sabiendo que Bennu usará el primer color de la paleta como el colr transparente. Este último formato creo que es el ideal para los juegos típicos 2d ya que un sprite no va a necesitar por lo general más de 256 colores distintos, ocupa poco y si usamos muchos sprites se nota, y permite el cambio de color de los sprites rápidamente con sólo cambiar la paleta por otra.
O bien usar imágenes PNG de 32 bits si necesitas mucha calidad o semitransparencias.

[SplinterGU]

png de 24 bits no hay problemas, porque se convierten a la resolucion adecuada... lo que no hay de 24 bits son mapas en memoria ni modo de video.
8 bits tiene las mismas caracteristicas que tuvo siempre (fenix/bennu), salvo que ahora en modos 16 y 32, los mapas en 8 bits tienen una paleta propia (o pueden usar la del sistema)

[DCelso]

ya, pero los png de 24 bits no tienen transparencias, así que solo nos sirven para fondos. :D.

[DCelso]

efectiviwonder, Juan Piruleta, el fpgedit es el que hace la conversión. Prueba:
Abres fpgedit.
Creas un nuevo fpg 16 bits.
Añades un png sin transparencias de 24 bits.
Guardas fpg.
Cargas en fenix el fpg
Creas dos procesos con la misma imagen del fpg.
Al segundo proceso pones que se pueda mover con las flechas.
Mueves éste por el otro y ves que el negro que había en la imagen no se dibuja.

Curioso, siempre creí que era una restricción de fenix y resulta que era de fpgedit. Osk, con esto podemos decir que tu manual no tenía una errata, sino más bien información incompleta  :o. Sería cuestión de aclararlo nada más. :).

POST DATA: he descubiero que la herramienta map también puede hacer esa misma conversión de negro a transparente si pones -z=0. Bueno, me doy cuenta que no tengo PI de programación en div/fenix/bennu :( :(

[darío]

A mi me parece normal que en un png de 24 bits se setee la transparencia al color 0,0,0, ya que los png de 24 no tienen canal alfa.

Splinter dijo:

en 16 bits tambien es el valor 0, pero solo cuando ya esta cargado en memoria, los pngs convierte a 0 (transparente) cuando el alpha es menor al 50%, y obviamente el color 0 tambien es transparente.

Según esto yo entiendo que no es que el FPGEdit "añada" la transparencia. Cuando añades un png de 24bits a un FPG de 16bits y trabajas en este modo en BennuGD, el color (0,0,0) se considera transparente. Por eso, la parte negra se ve transparente. En realidad FPGEdit no está convirtiendo nada, simplemente está manteniendo el color que tiene la imagen en el PNG. Para que no saliese transparente habría que convertir los píxeles que están a 0,0,0 a un color cercano (1,1,1)

[DCelso]

Mal, ahí splinter se refería a pngs de 32 bits, que son los que llevan canal alpha.
A las pruebas me remito. Crea  un proyecto bennu con "set_mode(640,480,16)" crea dos procesos uno encima del otro cargando una imagen de 24bits, es decir graph=load_png("img24bits.png") y verás que no convierte el negro a transparente.

Por las pruebas anteriores se deduce que la conversión se produce al pasar el png a map usando map.exe con la opción "-z=0". Y que FPGEdit debe de hacer algo al estilo.

[SplinterGU]

Pon un fondo de pantalla (putscreen) para hacer una prueba mas acertada, porque las prioridades de las z pueden hacer que un objeto se vea transparente y otro no.
O no entendi la explicacion.

Con respecto al canal alpha, obviamente hablo de pngs que tienen dicho canal.

[darío]

Pero si es así (y eso no lo pongo en duda ya que has hecho la prueba) es porque la rutina "load_png" de bennu estará convirtiendo el color 0,0,0 de la imagen PNG a un color cercano. Hasta donde yo creo tener entendido, internamente todas las imágenes cargadas se convierten a un "map" tal y como es entendido por Bennu, y un MAP de 16bpp entenderá el color 0,0,0 como transparente.
El tema está, que FPGEdit no hace esa conversión de color 0,0,0 en imagenes de 24 bits a un color cercano y por eso, una vez dentro del FPG, el gráfico (que ahora tiene estructura de un MAP) tendrá píxeles a 0,0,0, que se interpretarán como transparente.
Cuando usas el map-exe con la opción -z=0, lo que yo entiendo que se hace es precisamente que no se convierta. Cuando no usas -z=0 entonces es cuando realmente se están convirtiendo los píxeles 0,0,0 a un color cercano.

En fin, este asunto me interesa porque estoy trabajando en un editor FPG (SmartFpgEditor) y me gustaría saber como debo tratar los PNGs de 24 bits a la hora de agregarlos al FPG (es decir, si debo convertir los píxeles 0,0,0 a un color cercano para eliminar transparencia o si no debo hacerlo).

[Drumpi]

Yo lo que no acabo de entender son los problemas asociados a hacer un intercambio de colores, en la carga de PNGs de 8 bits, entre el definido como color transparente y el color cero: todas las operaciones relativas a los colores de cada pixel los hace el propio programador, que ya conoce (o debería conocer) esta característica de las paletas.
Aunque claro, deberíamos ser nosotros los que al crear el PNG tuviéramos esto en cuenta a la hora de crearlos ;D (siempre que no estemos "tomando prestados" gráficos :D)

[splinter_work]

Se complican demasiado.
Tienen que pensar en los png, pcx, o cualquier otro formato grafico, solo como un container... como un transporte de lo que realmente es un MAP.
Eso es lo que termina aplicando.

[darío]

Sí, yo lo único que quería hacer ver es que FPG Edit no está convirtiendo los pixeles negros de una imagen de 24bits en transparente, simplemente que el 0,0,0, siempre representará transparente en 16bits y que si un MAP no muestra unos pixeles transparentes es porque no están a 0,0,0.

[Drumpi]

Se complican demasiado.
Tienen que pensar en los png, pcx, o cualquier otro formato grafico, solo como un container... como un transporte de lo que realmente es un MAP.
Eso es lo que termina aplicando.

A eso me refiero: cuando se crea el map en memoria, usar como color 0 el color definido como transparente en el PNG, y como color X el color 0 del PNG. Luego ya se preocupará el programador de hacer las cosas bien con las durezas o lo que sea (no tomar el color X como "sin dureza", sino el 0 por el que ha sido sustituido).
De todas formas, PNG lo cargaba la image.dll de Fenix ¿no? entonces una pasadita por mi cambia_color y varios PNG en un BMP/MAP con los colores bien puestos del tirón (en FPG creo que no arreglé el tema de paletas y siempre detecta todas las paletas distintas ^^U)