Bennu Game Development

Foros en Español => Herramientas => Topic started by: DCelso on December 10, 2008, 05:06:44 PM

Title: fpg32converter
Post by: DCelso on December 10, 2008, 05:06:44 PM
Hola a todos, he hecho una adaptación de códigos que he ido viendo para crear un conversor (y a la vez compresor) de fpgs a fpgs de 32 bits, gracias a que el nuevo bennu solo graba pngs de 32 bits.

viene con un runme.bat para windows y necesita tener en el path el directorio de bennugd o bién copiar todos sus archivos al directorio del fpg32converter.
ejemplo de ejecución
runme.bat miarchivo.fpg
Title: Re: fpg32converter
Post by: SplinterGU on December 10, 2008, 05:13:44 PM
graba png de 32 solo si esta en modo 32, en modo 16 no deberia grabar png de 32...

gracias
Title: Re: fpg32converter
Post by: DCelso on December 10, 2008, 06:26:51 PM
Ostras, pues entonces he encontrado un bug o algo raro, resulta que si haces set_mode(20,20,16); cargas un png (8,16 o 32), luego guardas con save_png y luego abres el resultado con el GIMP, ves que tiene el canal alpha activado, y si vas a las propiedades del archivo te pone quees un png de densidad 32 bits.
En cambio curiosamente si haces set_mode(20,20,16) insertas en un nuevo fpg los load_png y haces save_fpg sí que guarda un fpg de 16 bits que se puede abrir con el fpgedit. (pero para mi que por dentro debe tener las imágenes png de 32 bits.)

Dejo la nueva versión de fpgconverter que ahora crea los dos tipos, 16 y 32, el de 8 no lo crea porque cualquier valor de 16 bits en el set_mode da como resultado un fpg de 32 bits.


Title: Re: fpg32converter
Post by: SplinterGU on December 10, 2008, 07:34:54 PM
no, no tiene de 32 bits... deberia tener de 16 o 24...
Title: Re: fpg32converter
Post by: DCelso on December 10, 2008, 10:26:14 PM
¿?
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 09:03:42 AM
no entendí lo de los 24 bits, ¿a qué te refieres?
Al exportar los pngs y abrirlos con el microsoft office picture manager (o cualquier otro visor) pone densidad de color 32 bits, de todos los modos que puse con set_mode, es decir, nunca conseguí que pusiera ni 24 ni 16 ni 8.

Mira el ejemplo con una imagen de tu sistema de menus.
8 + 8 + 8 + 8 = 32
R__G__B__Canal_Alpha.
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 12:15:44 PM
es cierto, los png son siempre de 32 bits... incluso los png al leerlos en bennu, siempre son de 32 bits, salvo el caso de 8 bits...
Title: Re: fpg32converter
Post by: animanegra on December 11, 2008, 12:34:57 PM
Los pngs se pueden guardar con color indexado y de manera que usen paleta de n colores ocupando lo que toque en cada caso. Usea que no tienen porque ser de 32 bits de profundidad de color.
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 01:28:30 PM
yo tampoco, preguntale a los creadores originales de fenix...
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 02:27:41 PM
http://en.wikipedia.org/wiki/Portable_Network_Graphics
http://libpng.org/pub/png/spec/1.2/PNG-DataRep.html

yo creo que hay que tirar a la mierda la vieja implementacion fenix de carga de imagenes y hacer una nueva...
Title: Re: fpg32converter
Post by: osk on December 11, 2008, 03:09:04 PM
¡¡Más leña al fuego!!
¿E implementar el APNG: http://en.wikipedia.org/wiki/APNG ?
Aaaahhhh!!!!!
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 03:40:01 PM
ummm... mapas animados, descartado... pero... quizas estaria bueno implementar esas cosas como si se trataran de fpg... o sea, un mapa animado, seria un fpg... del cual los id de grafico irian de 1-N, siendo N el ultimo cuadro de animacion del grafico... pero eso si, no se tendria otra informacion del mismo como ser tiempo de cada cuadro, etc... pero bueno, eso se puede tener en un archivo de datos... creo que seria interesante...
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 03:46:55 PM
ok, yo he estado haciendo pruebas con el GIMP haciendo pngs simples y el resultado es el siguiente.
He tenido que hacerme mi propio programa para leer la info de los pngs ya que actualmente todos los que he probado me engañan y me dicen que el png es de densidad de color 32 bits y cuando los abres te das cuenta que son indexados.

http://www.megaupload.com/es/?d=U2E4CIGX

Adjunto una imagen que he ido acrecentando en número de colores empezando por dos colores, azul-blanco y terminando con RGB y canal alpha.

Como conclusión decir que libpng permite guardar pngs en todos los formatos conocidos de imagen. :D. En contraoposición a bennu que las haca todas de 32 bits.
Fenix no guardaba pngs así que npi.
Title: Re: fpg32converter
Post by: Prg on December 11, 2008, 04:44:40 PM
Entonces no estaba loquito, y cuando quería esportar pngs en mi programa y me daban cosas raras no eran problemas de visión ni nada de eso :) .


Quoteyo creo que hay que tirar a la mierda la vieja implementacion fenix de carga de imagenes y hacer una nueva...

mmm!!! Suena bien!!!
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 06:28:28 PM
Quote from: DCelso on December 11, 2008, 03:46:55 PM
ok, yo he estado haciendo pruebas con el GIMP haciendo pngs simples y el resultado es el siguiente.
He tenido que hacerme mi propio programa para leer la info de los pngs ya que actualmente todos los que he probado me engañan y me dicen que el png es de densidad de color 32 bits y cuando los abres te das cuenta que son indexados.

http://www.megaupload.com/es/?d=U2E4CIGX

Adjunto una imagen que he ido acrecentando en número de colores empezando por dos colores, azul-blanco y terminando con RGB y canal alpha.

Como conclusión decir que libpng permite guardar pngs en todos los formatos conocidos de imagen. :D. En contraoposición a bennu que las haca todas de 32 bits.
Fenix no guardaba pngs así que npi.

Te equivocas, bennu y fenix siempre guardaron png... lo que fenix no guardaba era fpg y map...
A ver que haya dicho que hay que tirar a la mierda, no tiene nada que ver con el tema en discusion...
Segun la documentacion, hay 3 tipos de png... paleta indexada (1 hasta 8 bits), escala de grises y rgb (32 bits)...
Todos funcionan... los png de 16/24, son en realidad 32 bits, solo que se toma de ellos los bits necesarios y se descartan el resto... asi funciono siempre la lectura de png en 16 bits... y para los 32 bits, lo unico que se hizo fue no descartar bits... o sea, que si el gimp te dije que es 32 bits, es correcto, los png rgb son 32 bits, siempre, y esto no tiene nada que ver con bennu...
Y deberias poder generar png de 8 y png rgb sin problemas...
Title: Re: fpg32converter
Post by: animanegra on December 11, 2008, 06:47:16 PM
Expongo lo que he entendido, si guardo con una paleta de mas de 256 colores me deberia de usar modo rgb. O no exactamente pero lo que ocupe la imagen si que deberia de ser igual o superios a guardando en RGB.

Entonces algo no me cuadra, porque si uso una paleta de 1024 colores para obligarle a usar mas de 8 bits me ocupa menos que el rgb? Pero bastante menos.

animanegra@T0m4t0:~$ ls -al prueba1.png
-rw-r--r-- 1 animanegra animanegra 200 2008-12-11 19:47 prueba1.png

animanegra@T0m4t0:~$ ls -al prueba2.png
-rw-r--r-- 1 animanegra animanegra 919 2008-12-11 19:48 prueba2.png

:S

Si los modo indexados de mas de 256 colores (8 bits) tira de rgb deberia de ocupar lo mismo o mas, si ademas debe de guardar la informacion de paleta. :S

Creo que o te entendido mal o me estoy haciendo la picha un lio. XD O las dos cosas a la vez
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 07:01:11 PM
La wiki dice...

"With indexed color images, the palette is always stored in RGB at a depth of 8 bits per channel (24 bits per palette entry). The palette must not have more entries than the image bitdepth allows for but it may have fewer (so if an image for example only uses 90 colors there is no need to have palette entries for all 256).

Indexed color PNGs are allowed to have 1, 2, 4 or 8 bits per pixel by the standard; greyscale images with no alpha channel allow for 1, 2, 4, 8 or 16 bits per pixel. Everything else uses a bit depth per channel of either 8 or 16. The combinations this allows are given in the table above. The standard requires that decoders can read all supported color formats but many image editors can only produce a small subset of them."

Dice:

Indexed color PNGs = 1, 2, 4 u 8 bits por pixel...
Indexed color PNGs = si una imagen usa 90 colores no tiene necesidad de tener la PALETA COMPLETA de "256" entradas.

Te estas olvidando que con index guardas 1 byte por pixel, y este byte es el indice de la paleta (parcial, no necesariamente los 256 colores) y en RGB van 4 bytes por pixel.

Y tambien dice otras tantas cosas mas...
Title: Re: fpg32converter
Post by: animanegra on December 11, 2008, 07:04:38 PM
Acabo de fijarme lo que es. ^^ que le pongo usa 1024 colores... pero nanai :D Pero es guai ver como funcionan los programas... bueno y los usuarios. Joder, hay que reportarles para que te salte un error y no te lo guarde y confies que tienes una paleta de mas colores :P
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 07:10:26 PM
Por favor lean en el wiki la informacion de la tablita "PNG color options,[6] cell values are total bits per pixel for that combination"... donde dice que soporta cada tipo de formato...

index solo es para graficos de 8 bits o menos...

y los demas (por lo menos eso veo en el codigo de carga de los png) son de 32 bits... se descarte o no bits al leer para adaptarlo al modo requerido... repitiendo, nunca el codigo de carga de png de fenix/bennu cargo pngs que tengan fisicamente tamaño de 16 bits por pixel, siempre manipulo datos de 32 (salvo palette index, que son de 8 bits o menos)... convirtiendolos en cada caso... es lo que la libpng retorna, y por ende debo suponer que esos datos no los inventa la libpng...

Lo que si es cierto es que al guardar los png, se le dice que son de 8 bits por canal... cuando estos son de 16 o 32, pero se les dice que son de paletas de 8 bits (y palette index) cuando son de 8 bits los graficos...
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 07:13:46 PM
una cosa es la informacion del header del png y otra el contenido...
Title: Re: fpg32converter
Post by: Prg on December 11, 2008, 07:22:41 PM
mmm, quizá mi comentario está fuera de linea (como la mayoría), sin embargo considero que para un juego, que es lo que hacemos, exportar en 8, 16 o 32 bits no es muy importante, si se van a editar fpgs la cosa cambia, por las reglas (eso de no mezclar profundiades), sin embargo si en algún juego decean que el jugador modifique su protagonista o algo así, y por eso necesitan salvar los pngs y cargarlos, creo que no debe haber problemas, pues no es necesario agregarlos a un fpg, con un array con sus códigos vasta. :)

Y si se exportan en 32 y no en 16 bits, pero bennu los puede cargar entonces no hay problema con esto.

Bueno, es mi opinión, quizá no estoy pensando en posibilidades grandes, pero pues para lo que hacemos (repito videojuegos), no es muy necesario todo esto. :)
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 09:59:32 PM
Con lo que he leído, corroboro que nadie ha probado mi ejemplo en donde se ven echos no conjeturas.   ;)
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 10:06:32 PM
si tu ejemplo hace algo fuera de la especificacion png entonces esta haciendo algo mal...
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 10:25:30 PM
Acabo de ver tu ejemplo, haberlo visto antes y nos ahorrabamos toda esta charla...

El error no esta en bennu sino en la filosofia de tu ejemplo... El png que se guarde no va a depender del modo de video, sino que va a depender del fuente, en tu caso del fpg... si tu fpg es de 16 o 32 bits, nunca en tu vida vas a guardar un mapa de 8 bits...

aca te pongo un ejemplo clarito...


import "mod_video";
import "mod_map";
import "mod_say";

private
g;
begin
set_mode(640,480,16);
g = load_png("sample.png");
save_png(0,g,"sample-out.png");
end


Resumen:
PNG leido = 8 bits
PNG guardado = 8 bits
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 10:45:55 PM
Ok, muchas gracias, aclarado, hablando se endiende la gente. Aunque yo me refería al ejemplo último subido a megaupload donde con GIMP creo una imagen de dos colores, guardo, pongo tres vuelvo a guardar, pongo cuatro, ...., pongo 10, ... paso a RGB, y finalmente a RGBA.
http://www.megaupload.com/es/?d=U2E4CIGX
Todas las pruebas dan pngs distintos. Curiosamente los visores de pngs dicen que son imágenes de 32 bits de profundidad de color, pero yo he hecho un programilla en c usando libpng1.2 en el que extraigo la información de cabecera del png y muestro lo que realmente se encuentra en el png y que verdaderamente coincide con la realidad cuando lo abres con el GIMP. Mas o menos guarda relación con lo que comentas, no contradice lo que viene en la wiki.
Como resultado se aprecia que en GIMP imágenes indexadas sólo son permitidas de 1,2,4,8 bits por pixel.  Después ya se pasa a RGB de 24 bits y por último al añadir el canal alfa se pasa a 32 bits.
Vuelvo a repetir que todos estos formatos se pueden guardar en un png y que son pngs distintos al que extrayendo la cabecera correctamente se puede acceder a dicha información.
Se puede ver que 16bits de densidad por pixel no los crea GIMP, es lo que siempre se ha dicho de que 5-6-5 para RGB no es muy cómodo.
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 10:47:13 PM
yo probe tu ultimo ejemplo, en 2do que pusiste... no vi otro...
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 10:49:53 PM
por lo que yo veo en el codigo de bennu, los 16 se arman en memoria a partir de uno de 32 en archivo, de 32 bits que no tiene alpha...
los de menor profundidad que 8 bits, bennu los graba como 8 bits...
y los de 32 o 16 bits depende del grafico, pero realmente son todos 32 bits (RGB)...
Title: Re: fpg32converter
Post by: Prg on December 11, 2008, 11:00:38 PM
QuoteCon lo que he leído, corroboro que nadie ha probado mi ejemplo en donde se ven echos no conjeturas.   Wink
en realidad yo sí lo había mirado :)
[code language="bennu"]
---------------
info_ptr->pixel_depth :1
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :2
-------------------------------------------------------
info_ptr->pixel_depth :2
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :3
-------------------------------------------------------
info_ptr->pixel_depth :2
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :4
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :5
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :6
-------------------------------------------------------
info_ptr->pixel_depth :4
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :15
-------------------------------------------------------
info_ptr->pixel_depth :8
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :1
info_ptr->num_palette :20
-------------------------------------------------------
info_ptr->pixel_depth :24
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :3
info_ptr->num_palette :0
-------------------------------------------------------
info_ptr->pixel_depth :32
info_ptr->width :100
info_ptr->height :100
info_ptr->channels :4
info_ptr->num_palette :0
------------------------------------------------------- [/code]

sale esto
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 11:10:58 PM
No se, no te estoy contradiciendo, supongo mas bien que son problemas de conceptos, ya que a medida que se va profundizando en el tema se va complicando más la cosa.
Es que si ya nos ponemos a hablar de densidad de bits por canal la liamos (o lo aclaramos).
Este enlace aclara un poco la idea
http://luciaalvarezplastica.googlepages.com/introducirimágenes

Si hablamos de color verdadero de pixel:
Actualmente lo más utilizado es 8bits por canal dando posibilidad de valores desde 0 hasta 255.
*una imagen a un canal es la típica imagen de escala de grises desde el 0-negro hasta el 255 blanco. Esto es 8 bits por pixel.
*una imagen a dos canales es una imagen con un canal gris y un canal alfa que representa la opacidad. Esto es 16 bits por pixel. (no podemos confundirlas con las pseudo RGB 5-6-5 que maneja fenix/bennu)
*una imagen a tres canales es la típica RGB, canal red, canal green, canal blue. Esto son 24 bits por pixel.
*una imagen a cuatro canales es la típica RGBA, canal red , canal green, canal blue , canal alfa. Esto son 32 bits de color.

Luego se complica si usamos 16bits por canal, actualmente algunas cámaras llevan un RGB en este formato por lo que daría 48 bits por pixel.

Si hablamos de color indexado complicamos más el tema porque es tener hasta un maximo de 256 colores en cualquiera de los formatos anteriores mencionados formando una paleta de colores. Y después un array de información de color de 8 bits por pixel, es decir que cada pixel se representará con un número del 0 al 255 que a su vez indica una posición dentro de la paleta de colores, siendo imposible dibujar un pixel con un color distinto a los 256 permitidos en la palate.

Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 11:12:29 PM
Ok prg, veo que lo viste,perdona entonces. Si que lo habeis mirado algunos :)
Title: Re: fpg32converter
Post by: SplinterGU on December 11, 2008, 11:19:40 PM
me imagine que me ibas a decir que 32 es RGBA... y tambien me imagine la respuesta que te daria...

hablo a nivel generico, RGB o RGBA en el caso estoy hablando de color verdadero, no de modo paletizado. Creo que se sobreentiende...

Creo que si yo no conociera lo que son los modos paletizados, 16, 24, 32 bits, nunca podria haber llevado adelante este proyecto...
Title: Re: fpg32converter
Post by: DCelso on December 11, 2008, 11:45:58 PM
Nunca dije que no los conocieras. :(.
En fin, por mi parte todo aclarado.
Gracias de nuevo.
Title: Re: fpg32converter
Post by: SplinterGU on December 12, 2008, 12:37:20 AM
:)
si, por mi tambien... disculpa que no siga con el intercambio de informacion, pero estos dias vengo tan aprisa que no logro poder concentrarme en charlas largas...
Title: Re: fpg32converter
Post by: simulatorone on January 15, 2010, 11:10:48 AM
Me encanto este tema, ya que adoro la manipulacion de graficos, sobretodo con el png y los fpg!!
:)