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

DCelso · November 26, 2008, 12:10:59 PM

Problemas en bennuwip15c2 o problemas de programación.
Bueno para el proyecto apagame, y basándome en la información que kim-ele-to necesita en su galaxian.fpg, (Que al parecer solo necesita un punto de control por imagen) he creado una herramienta de automatización para pasar los png a un fpg.
el nombre de los png debe ser el siguiente
"Numero de grafico"-"valor x del punto de control"-"valor y del punto de control".png

Pues me pasa que los primeros resultados no son los esperados.
Adjunto un ejemplo con el .fpg origina, las imágenes extraídas en formato png de 8 bits, los programas de conversión de png a fpg y el script de ejecución para windows.

A ver si alguien me puede ayudar a ver los motivos del comportamiento inexperado.
En el primer caso, intento hacer un fpg sin cambiar la densidad de color de los pngs.
En el segundo caso obligo a que el fpg tenga las imágenes en 16 bits de color
En el tercer caso obligo a que el fpg tenga 32 bits de color.

Pues el primer caso, todas las imágenes del fpg comparten la paleta de la primera imagen por tanto todas se ven mal excepto la primera. Además las imágenes desde la 30 en adelante se ven desfasadas unos píxeles con respecto a la original

En el segundo caso, todas las imágenes se ven bien pero la 7 y la 22 están en negro completo, además sigue pasando lo del desfase comentado.

En el tercer caso, el fpg parece que se genera bien, pero luego al usarlo en el programa las imágenes no se ven, o bien las genera todas en negro (o transparente) o bien el fpg está corrupto. No he podido ver la información ya que fpgedit no abre los fpgs de 32 bits.

Para ver el ejemplo, descomprimr el zip adjunto y ejecutar el script llamado "ejecutar.bat". Nota: debes tener en el path el directorio de bennu.

Prg · November 26, 2008, 03:58:39 PM

para ver los fpg de 32 b usa mi herramineta, ahí funciona bien. En cuanto a lo de los pngs de 8 bits, creo que así funciona esto, en el Div todas las imágnenes que corrían sobre un mismo juego deberían tener la misma paleta, creo que aquí también... ese es uno de los problemas del fpg editor que hago, las imágenes se ven mal en modo 8 b por esta razón. Lo del 16 b se me dio en una ocación, pero Splinter ya había solucionado el problema y ya no se me daba. Puedes probar con mi editor de fpg, que utiliza bennu, si funciona todo pues entonces pudeo darle una revisada a tu código, de lo contrario entonces esperamos a Splinter para preguntarle. (El enlace de descarga del fpg editor versión actual está en la parte que nadie lee, en el primer mensaje del tema, voy a subir hoy [si termino] una nueva versión para arreglar algunas cositas, pero por ahora ahí está la descarga).

Saludos y gracias por lo de la IA del conecte 4 . :)

SplinterGU · November 26, 2008, 05:08:26 PM

estoy viendo el tema, parece haber un error, pero que me suena haberlo corregido... yo con tu editor no veo nada en los graficos, incluso con un visor hexadecimal veo las imagenes todas en 0x00, o sea, transparente o negro, segun el caso. Pero bueno, supongo yo eso, quizas estoy viendolo mas, se complica un poco el tema en linux.

yo si leo la primera parte, y el help en imagenes te quedo muy lindo...

SplinterGU · November 26, 2008, 05:47:51 PM

Bien los fpg estan bien generados... solo veo el bug del corrido en la carga de los png, esto estaba corregido, o eso pense, se ve que hay otro caso donde tambien pasaba... aunque no descarto que sea algo en el png que no este soportado por la libpng, ya la ultima vez me paso lo mismo cuando lo corregi, que el formato no era el adecuado, se corrige esto temporalmente no usando graficos de ancho impar.

proba con este codigo para visualizar los fpg...

Code Select


program fpgbrowser;

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

begin

    set_mode(640,480,32);

    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;

    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

Prg · November 26, 2008, 05:48:36 PM

Quoteestoy viendo el tema, parece haber un error, pero que me suena haberlo corregido... yo con tu editor no veo nada en los graficos, incluso con un visor hexadecimal veo las imagenes todas en 0x00, o sea, transparente o negro, segun el caso. Pero bueno, supongo yo eso, quizas estoy viendolo mas, se complica un poco el tema en linux.

yo si leo la primera parte, y el help en imagenes te quedo muy lindo...

:D
Gracias

Eh estado haciendo mis fpgs para conecte 4 y eh encontrado un montón de cosas que solucionar en mi editor y eh solucionado algunas.

SplinterGU · November 26, 2008, 05:48:46 PM

El error que no veia nada es que la carpeta era GALAXIAN en mayusculas, no en minusculas... hay que tratar de no usar mayusculas en los nombres de archivos.

DCelso · November 26, 2008, 07:14:27 PM

Gracias a sendos.
De todas formas me sigue siendo raro el problema de los 8 bits, puesto que el fpg original tiene insertadas las imágenes en 8 bits o almenos eso creo.

Yo lo que he hecho ha sido extraerlas con el fpgedit2005 a formato png, luego extraer sus puntos de control, luego añadirlos al nombre del archivo y luego pasar el programa aFPGmaker.prg
Debería de obtener el mismo fpg que el original pero no es así, se me escacharran los colores.
Yo creo que el motivo es que el fpgedit puede insertar imágenes de 8 bits con distintas paletas (algo como no usar la opción "shared palette" que hay en otros formatos de otros lenguajes de programación de juegos), en cambio bennu no me deja hacer eso mismo y siempre usa la de la primera imagen. Necesitaría que alguien me confirmara esta afirmación.

También he probado a ir cambiando la paleta con load_palette a medida que voy insertando la nueva imagen pero no se lo traga bennu, no se porqué sigue usando la primera para la generación del fpg final.

Tampoco entiendo el motivo de porqué desde fpgedit2005 se pueda insertar imágenes con anchos o altos impares correctamente y desde bennu no.

A ver, he ejecutado el "ejecutar.bat" (valga la redundancia)
he abierto los cuatro fpgs de la carpeta fpg(otra vez :D)
*el original se ve perfecto (es el realizado por kim-ele-to con el fpgedit)
Los siguientes los he generado con los pngs extraídos del original así que deben de reproducir el mismo fpg.
*el de 8 bits generado se ve mal, además las imágenes impares desfasadas cosa que no entiendo porque es una simple carga e inserción fpg_add(load_png
*el de 16 y 32 van casi perfectos a no ser por culpa del desfase que también existe (esto se podría solucionar usando un xputnp en vez de put <<algo cutre pero podría valer>>) pero hay dos imágenes que van mal la 7 y la 22, estrañisimo porque en 16 bits no se ve y en 32 bits va algo raro, es como haber invertido lo que se tiene que ver transparente con lo que no se tiene que ver transparente.

A ver si podeis comprobarlo.

SplinterGU · November 26, 2008, 08:10:54 PM

yo probe tu ejemplo, y los graficos se ven perfectos, igual al original... no compares el tamaño del fpg, porque uno esta comprimido y otro no.
veo que los colores en 8 bits se invierten, pero claro, no tienen la misma paleta, el fpgedit "optimiza" las paletas al exportar... y ese es el problema...
tambien veo corrido el grafico, pero eso es problema del load_png, asi que por mas que uses load_png directamente vas a seguir teniendo el problema...
ahora mismo no puedo ver la solucion, pero seguro es una estupides... luego lo reviso... con respecto a las paletas deberias convertirlas por codigo, hay una funciones para eso, luego pongo un codigo de ejemplo.

no, fpgedit convierte el grafico a la paleta del fpg cuando importar, cuando exportas, "optimiza" la paleta del grafico exportado, por eso ni el original es igual al final exportado, ni el que esta en el fpg al exportado... pero incluso fpgedit siempre usa la primer paleta cargada (cuando se crea el fpg).

es perfecto que siempre use la primer paleta.

lo del ancho ya explique que es un bug.

ahora no puedo ver estas cosas, estoy con bastante trabajo... pero lo vere luego...

DCelso · November 26, 2008, 09:28:24 PM

gracias por las aclaraciones Splinter, voy entonces a intentar extraer las imagenes de otra forma.
Por otro lado, la explicación a los dos gráficos erróneos el 7 y el 22 ¿cual sería?.
Si te das cuenta en el fpg original la imagen 7 es una especie de i de color amarillo algo así

Code Select

donde el 0 es amarillo y el 1 es negro (que se ve transparente).
En los fpgs de 16 y 32 bits el 1 es negro puro y el 0 es transparente.
he ido más allá y viendo la paleta de la imagen he visto que la posicion primera de la paleta es el amarillo, así que debe de estar relacionada la posición al hacer la conversión a 16 y 32 bits y buscar el transparente. Parece usar la primera posicion de la paleta en vez de buscar el color negro y usarlo como transparente.¿estoy en lo cierto?

De todas formas he hecho una prueba más intercambiando los colores de la paleta y ahora me pasa algo más extraño aún, que quiza esto tambien sea el mismo problema que el desfase en las otras imágenes
el gráfico obtenido queda tal que así

Code Select

Es decir se pierde el color amarillo de la primera fila.
A lo mejor es otro bug o no pero perder se pierde la información de este pixel.

SplinterGU · November 26, 2008, 09:40:54 PM

ahi esta el problema, no hay que usar 0 para los colores, 0 es transparente siempre... y cuando se carga si es cero no lo carga... es cero...
no, olvidate de la paleta, es el color, 0 es transparente... 0 siempre reservalo para transparente.

DCelso · November 26, 2008, 11:50:29 PM

kucha pixa, te hablo a nivel de indexación, recuerda que es la posicion 0 de la paleta de colores, yo no he inventado el sistema de indexación de imágenes. Ahí está el error entonces de la conversión a 16-32 bits, tienes que usar como transparente el color negro (0,0,0) para intentar hacer una aproximación más real (ya que así funciona en 8 bits), ahora parece que usa 0 que es el índice del primer color de la paleta confundiendolo comocolor transparente, por eso la caga y se pierde el primer color de la paleta en la conversión.
Prueba el programa que te adjutno, que es una modificación de tu programa brownser pero para comparar dos fpgs a la vez.

De todas formas aún evitando el error haciendo que el primer color sea el negro y se pierda éste sigue haciendo cosas raras, con la imagen adjunta puedes ver el ejemplo, se pierde un pixel de información comparando el fpg16 bits generado con el png origen y con el fpg8 bits original.

DCelso · November 26, 2008, 11:55:32 PM

Adjunto imagen obtenida con aumento 4.

Edit:
Juas, me vais a pegar por pesado, sigo haciendo pruebas pero ahora me he encontrado otra limitación.
Bennu solo me deja guardar pngs a 32 bits de color, da igual a la profundidad a la que obligue a trabajar al sistema. Así que no puedo probar a extraer las imágenes del fpg original
A ver si podeis ayudarme una vez mas.

DCelso · November 27, 2008, 12:55:16 AM

Estoy ocecado, pero resulta que el fallo se produce con los pngs de 8 bits. Usando los pngs extraídos a 32 bits va bien, sorprendentemente la conversión a fpg16 la hace bien pero como es de esperar en la conversión a fpg8 la caga.
Dejo ejemplo.
Ya he integrado todo en el ejecutar.bat para que sea simplemente ejecutar y ver resultados.

SplinterGU · November 27, 2008, 05:25:52 AM

Quote from: DCelso on November 26, 2008, 11:50:29 PM
kucha pixa, te hablo a nivel de indexación, recuerda que es la posicion 0 de la paleta de colores, yo no he inventado el sistema de indexación de imágenes. Ahí está el error entonces de la conversión a 16-32 bits, tienes que usar como transparente el color negro (0,0,0) para intentar hacer una aproximación más real (ya que así funciona en 8 bits), ahora parece que usa 0 que es el índice del primer color de la paleta confundiendolo comocolor transparente, por eso la caga y se pierde el primer color de la paleta en la conversión.
Prueba el programa que te adjutno, que es una modificación de tu programa brownser pero para comparar dos fpgs a la vez.

De todas formas aún evitando el error haciendo que el primer color sea el negro y se pierda éste sigue haciendo cosas raras, con la imagen adjunta puedes ver el ejemplo, se pierde un pixel de información comparando el fpg16 bits generado con el png origen y con el fpg8 bits original.

no, ya lo explique cientos de veces... (0,0,0) es paleta... esto es 0 valor del elemento = 0, sea indice/color real, etc... o sea, si [pixel] == 0, entonces es transparente. Siempre fue asi, nunca fue (0,0,0), esto es algo que repito siempre...

creo que tu error proviene de este concepto... es necesario entender esto... olvidate de rgb, porque rgb es solo una funcion que convierte valores rgb a valor elemento/pixel, y los valores pixel = 0 (no rgb = 0,0,0) es el color transparente...

DCelso · November 27, 2008, 09:59:20 AM

A ver, creo que o no me expresé bien o no entiendes como van las imágenes indexadas (de index de índice). Está claro que el problema radica en estas imágenes porque con las de 32 bits y 16 no pasa.
Estamos de acuerdo que en este tipo de imágenes se guarda una paleta de colores en un array y que luego hay otra matriz con la informacion de colores a usar de la paleta para cada pixel?
A ver, hablando en plata, el caso que he explicado es el siguiente

Code Select


array de colores = 
RGB(255,255,0)
RGB(0,0,0)  
matriz de información = 
101
000
000
000

¿Para tí qué significan los ceros de la matriz de información?
Porque en realidad están haciendo referencia al color de la posición uno de la paleta.
La conversión a 16 bits de color sería esta

Code Select


RGB(0,0,0) , RGB(255,255,0), RGB(0,0,0) 
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)

Pues bennu no hace esto, sino esto otro

Code Select


RGB(0,0,0) , 0, RGB(0,0,0) 
0,0,0
0,0,0
0,0,0

Es decir confunde el índice "0" (que sirve para hacer algo como array_de_colores[0] para obtener el color amarillo) de la paleta con el color 0 (transparente) del que hablas. La pifia, por lo menos eso demuestran las pruebas de conversión.

Y creo que la conversión correcta es o bien olvidarnos del transparete y cambiar todos los colores por los verdaderos o considerar que el índice de la paleta que tenga el color negro sea el transparente, para acercarnos más a la realidad que existía en 8 bits. En este caso array_de_colores[1] que vale RGB(0,0,0)
dando como resultado esto

Code Select


0 , RGB(255,255,0), 0
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)
RGB(255,255,0) ,RGB(255,255,0),RGB(255,255,0)

Podría asumir que no usara el transparente y creara una imagen sin transparentes, algo lógico y cosa que hacen los editores de imágenes normalmente, esto olvidaría el consenso que se hizo en div de considerar el índice de la paleta con color negro como el transparente y para no olvidarlo estaba proponiendo el caso anterior.
Pero nunca podré asumir que se pierda el color primero de la paleta en la conversión, que en este caso es el amarillo.

Si ya con datos no captas lo que quiero decir, entonces tenemos un severo problema de entendimiento de idiomas porque no se me ocurre manera más clara de expresar los resultados, :(, lo siento de veras.