Errores inesperados en creación de fpgs a partir de pngs de 8 bits de color

[SplinterGU]

no, yo entiendo perfectamente el tema de los colores en 8 bits... en 8 bits cada pixel es un indice de 0 a 255 de una tabla de colores rgb llamada paleta, pero repito, el valor 0 de este indice es color transparente, no importa en lo mas minimo que valor tiene la en la paleta... para bennu es transparente.
olvidate la matriz, aca no hay matriz, el indice 0, es transparente... y en los modos realcolor (16 o mas) no se usa indice y esa informacion de tablita que vos decis que se llama paleta esta contenida en el pixel...

bennu no hara ninguna conversion rgb ni revisara la paleta de colores para saber que "color" es el cero, porque rgb(0,0,0) " NO ES" valor "NO COLOR", "ES" color "NEGRO". ya que hacer este chequeo o conversion consumiria mucho mas recursos y no nos podemos permitir tal lujo en un juego.

en todo sentido y caso, el valor "DE PIXEL" ("PIXEL! NO DEL COLOR") 0 (cero/zero/falso/ausente/null/off/apagado) significa ausencia de color, color transparente.

no hay error de conversion, repito, cuando el pixel es 0, se carga como transparente.

pero vamos que esto se hablo infinidad de veces... y todo el mundo sabe que el valor de pixel 0 es transparente...

y mas alla de todo esto, te estas olvidando que la paleta que se carga para ese fpg de 8 bits es la paleta del primer grafico, donde la informacion del color 0 es (0,0,0)...

EDIT:

A ver si probando este codigo se te aclara un poco la cosa... tenes que poner el png original en el mismo directorio y probar con el fpg de 8 bits...

Code Select Expand


import "mod_screen"
import "mod_video"
import "mod_map"
import "mod_key"
import "mod_text"

begin
    set_mode(640,480,8);

    load_pal("007-1-4.png");

    load_fpg(argv[1]);

    graph = 1;

    while (!map_exists(0,graph) && graph < 1000) graph++; end
   
    write_int(0,10,10,0,&graph);

    x = 320;
    y = 240;

    flags = B_NOCOLORKEY;

    while(!key(_ESC))
        if (key(_LEFT) && graph > 1)
            graph--;
            while (!map_exists(0,graph) && graph > 1) graph--; end
            while (key(_LEFT))
                frame;
            end
        end
        if (key(_RIGHT) && graph < 999)
            graph++;
            while (!map_exists(0,graph) && graph < 1000) graph++; end
            while (key(_RIGHT))
                frame;
            end
        end
        frame;
    end

end


[SplinterGU]

con ese codigo que subi antes, probado con los graficos como tenes, y luego con este codigo para generar los fpg... vas a entender como es la cuestion...

Code Select Expand


//-------------------------------------------------------------------
// PROYECTO: Classic Pack Games For Bennu.
// AUTORES: DCelso, TYCO, Kim-ele-to, PiXeL
// FECHA INICIO: Noviembre 2008.
// FECHA FINALIZACION: xx/xx/xxxx.
// REVISION: xx/xx/xxxx.
// VERSION PARA: Bennu WIP-15c2.
//-------------------------------------------------------------------
PROGRAM aFPGMake;
local
    int DEPTH = 16;
    String splitted[100];
    String filename;
    int id_map;
    int id_new_map;
    int lenght[1];
Begin
set_mode(100,100,DEPTH);
file=new_fpg();
    While( (filename = Glob("fpg/"+argv[1]+"/*.png"))!="" )
        split("[-\.]",filename,&splitted,100);
        id_map = load_png("fpg/"+argv[1]+"/"+filename);
        lenght[0]= graphic_info(0,id_map,G_WIDTH);
        lenght[1]= graphic_info(0,id_map,G_HEIGHT);
        id_new_map = new_map(lenght[0],lenght[1],DEPTH);
        map_xput(0,id_new_map,id_map,lenght[0]/2,lenght[1]/2, 0, 100, b_nocolorkey); // Aca se le dice que guarde sin transparencia !!!! valido para ver el grafico en modos 16 o superior, y aca el 0 del amarillo, deja de existir como pixel...
        fpg_add(file,splitted[0],0,id_new_map);
        say (lenght[0] + " " + lenght[1] + " " + graphic_info(0,id_map,G_DEPTH) + ">" + splitted[0] + " " + splitted[1] + " " + splitted[2]);
      if  (splitted[1]!="" AND splitted[2]!="")
         set_point(file,splitted[0],0,splitted[1],splitted[2]);
        End
        unload_map(0,id_map);
        unload_map(0,id_new_map);
    End
    save_fpg(file,"/fpg/"+argv[1]+DEPTH+".fpg");
End


[Drumpi]

¿Tan dificil de entender es que:

-8 bits: el color cero será el transparente, aunque tenga componentes de color rgb=(30,218,53).
-16 bits: el color negro puro (rgb=(0,0,0,)) es el color transparente.
?

[DCelso]

Muchas gracias por las explicaciones. Me has demostrado que el color amarillo se pierde.
Como prueba te dejo este ejemplo de la misma imagen en 4 pngs distintos dando resultados distintos, cosa muy curiosa porque gimp los ve los 4 iguales :D.

Tal me poneis las cosas veo que está hecho así a posta y que bennu usa como transparente este índice independientemente de la información de color que tenga. Es decir, no es el negro puro el color transparente, cosa que habría que corregir en infinidad de tutoriales que dicen que uses éste como transparente y colores cercanos como RGB(10,0,10) como negro sin hacer referencia a la densidad de color.
Esto lo veo lógico, aceptable y una buena solución ya que en otros proyectos se adoptó esta misma solución (caso de M.U.G.E.N) pero no es la solución que adoptó DIV, o es lo que yo tenía entendido :(.
Habría que hacer incapié en los tutoriales acerca de este aspecto.

El segundo error es que elimina un pixel de información de la primera fila que eso ya si que no me trago que sea un comportamiento programado a posta.
Y gracias por vuestra atención, espero no haber molestado mucho.

[SplinterGU]

voy a crear un thread/documento APB para explicar (y linkear en mi firma) todo el tema de colores, paleta, transparencia y demases...

[DCelso]

Muchas gracias de antemano por el APB  ,
por cierto el tema del segundo error a que se debe? Lo siento no me quedó claro si está relaccionado con el bug que comentaste anteriormente sobre el desplazamiento o es otro nuevo detectado.

[SplinterGU]

DCELSO: Por favor olvidate todo lo que pensas al respecto y lee lo que escribo como si no supieras nada del tema...

color/indice/pixel es el valor del elemento:
8 bits = 256 colores = valores de color valido 0-255 (color no es informacion de paleta)
16 bits = 65536 colores = 0-65535
32 bits = 4g de colores ....

paleta es la informacion rgb del color...
en 8 bits la paleta se encuentra en registros del DAC (informacion de hard)
en 16/32 bits la informacion rgb esta contenida en el color/indice/pixel... (no siendo asi en 8 bits ya que no se pueden meter 18-24bits de color en 8 bits)

luego extendere mas el tema en un documento bien claro...

nunca nadie dijo (por lo menos ni yo, ni los que saben del tema) que el color negro es el transparente... siempre digo el color "0" y lo recalco siempre, color 0 no es color negro...

lo del pixel, ya dije (en este mismo hilo) que es un error... me gustaria no tener que repetir varias veces las cosas, todos perdemos tiempo al pedo...

[SplinterGU]

es un bug referente al alineamiento de bytes en memoria... tiene simple solucion, pero no lo puedo ver ahora...

[DCelso]

Muchas gracias, me queda mas claro que antes, y reitero mis disculpas si causé molestias con el tema.
Intento estar al día en todos los post, pero como comprenderás son muchos muchos y a veces la búsqueda no devuelve los post esperados (hay que saber buscar :()

En MUGEN se usa mucho la técnica la paleta ya que con solo cambiar la paleta de colores consigues crear enemigos con distintos colores y mismo aspecto. Supongo que es típico de la era de 8 bits.
Lo que pasa es que en ese entorno existe un formato "SFF" que sí soporta inserción de imágenes con distintas paleta de colores.

[SplinterGU]

bien, no hay problema, claro que cuesta, mas cuando uno esta apurado...

ahora, aca tambien podes poner paleta por grafico, pero en modo 16/32 usando graficos de 8 bits, pero no podes usar fpg, porque se supone que un fpg8 (archivo) es una coleccion de graficos con la misma paleta, es una limitacion del formato, pero asi fue diseñado...

[DCelso]

He estado viendo el codigo fuente del cvs de fenix en sourceforge y he visto que la estructura de memoria para guardar los recursos gráficos sí soporta mapas con distintas profundidades de color aunque luego el archivo "fpg" no lo haga, curioso.

Otra cosa que he visto en el fgc_save (ya que fpg_save no existe), es que no hace ningún cambio de conversión de profundidad de color, así que si las imágenes (map que lo forman) eran de 16 bits, se guarda en esa profundidad.

[SplinterGU]

asi esta diseñado el formato... el fpg es asi...
el fgc se elimino porque estaba incompleto, y tenia algunas fallas al nivel diseño...

[DCelso]

Sería interesante un formato bennu graphics container que fuere lo mas fiel posible a la estructura que hay en memoria para almacenar los datos. Así sería mas directa la lectura del formato y asignación a memoria y también daríamos al archivo las maximas prestaciones que ahora mismo dispone bennu internamente.
En cuanto a hacer lo mismo con el map no se yo , no he investigado si la estructura que almacena el map en memoria es mas completa que la capacidad del archivo en sí

[SplinterGU]

fpg en memoria es una serie de maps...

creo que venimos muy retro, te sugiero uses la opcion buscar... ya se hablo de la futura inclusion de un container de recursos...

agrego, los fpg en memoria no contienen paleta, la paleta es la del sistema, si lo primero que se carga es el fpg, se carga esa paleta, sino se usa la paleta del primer grafico que se carga de 8 bits... esto es en 8 bits, en 16 o mas, cada mapa tiene su paleta, que en los casos de mapas cargados desde fpg comparten 1 misma paleta entre todos... pero esto no es la estructura del fpg en memoria, lo que vos ves como estructura en los headers es del archivo, no de la memoria... un fpg en memoria es un vector de ids de mapas.

[DCelso]

Ok, revisaré , gracias por la respuesta.