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.
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 . :)
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...
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...
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
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.
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.
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.
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...
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í
101
000
000
000
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í
111
000
000
000
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.
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.
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.
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.
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.
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...
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
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
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
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
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.
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...
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
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...
//-------------------------------------------------------------------
// 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
¿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.
?
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.
voy a crear un thread/documento APB para explicar (y linkear en mi firma) todo el tema de colores, paleta, transparencia y demases...
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.
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...
es un bug referente al alineamiento de bytes en memoria... tiene simple solucion, pero no lo puedo ver ahora...
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.
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...
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.
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...
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í
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.
Ok, revisaré , gracias por la respuesta.
Corregido bug de desplazamiento de bits en la carga de png.
Agredeceria lo prueben...