Image.{dll,so}

Started by josebita, May 11, 2009, 07:39:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

josebita

Estoy subiendo la extensión image a mi PPA. Dado que el otro día tenía algo de tiempo libre y con la ayuda de Splinter la he adaptado a los 32 bits.
Aún le queda algún fleco pero creo que debería funcionar bien, a ver si soy capaz de compilarla un día de estos en windows (si alguien lo quiere compilar, en mi PPA hay un enlace a los fuentes).

josebita

#1
Acabo de compilar la versión con soporte para 32 bits en windows. Debería funcionar bien con gif, jpeg y png sin necesidad de más librerías, porque la librería está compilada estáticamente contra ellas.

Espero que os funcione bien.

Podeis tomarlo de aquí.
De nuevo, gracias a Splinter por su ayuda con esto.

Prg

será genial para el editor fpg  ;)
en humos puedes mover la camara con los cursores. es necesario para los niveles a partir del dos :)

josebita

Espero que sea útil :)

Prg

#4
lo he adaptado al editor, carga bmp, jpg, tga, etc, etc, etc... está genial :)

ahora el editor carga
"*.png",
        "*.map",
        "*.pcx",
        "*.bmp",
        "*.gif",
        "*.jpg",
        "*.lbm",
        "*.pnm",
        "*.tga",
        "*.tif",
        "*.xcf",
        "*.xpm",
        "*.xv";

y de una forma muy rápida :)
en humos puedes mover la camara con los cursores. es necesario para los niveles a partir del dos :)

DCelso

tooma PRG, de poca madre para el editor ¿no?
Siento que tu implementación de lectura de bmp no te sirva ahora para nada :D, al menos te queda lo que aprendiste.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

josebita

Vamos a mirarlo por el lado bueno; por lo menos ya no tiene que implementar el LZW.

Prg

 :D quizá mi código sirva para sistemas en que no se ha compilado aún la librería....
en humos puedes mover la camara con los cursores. es necesario para los niveles a partir del dos :)

josebita

Quote from: Prg on May 19, 2009, 09:31:38 PM
:D quizá mi código sirva para sistemas en que no se ha compilado aún la librería....

No es ninguna tontería... Y creo que (si no está aún en el wiki) sería pero que muy interesante añadirlo a él (ahora mismo no me ofrezco, mi vida es un caos :)).

Drumpi

La pregunta del millón es si se soportan los gifs animados, porque si la librería no lo hace (aun no he visto ningun programa que la use y muestre los demás frames) hay que seguir con el LZW a pelo.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

splinter_work

en los gif animados hay varios problemas...

1) los gifs animados tienen deltas para cada frame (bueno, no es un problema real, pero si ocuparian mucha mas memoria una vez cargados)
2) como indicariamos los tiempos entre cada frame... estos no son siempre iguales... seria necesario usar algun tipo de estructura especifica o guardar en mapa en algun formato especial que no sea, map, o asociarlo de alguna forma a este, y que el mapa se vaya actualizando frame a frame y que bennu lo vea como un unico mapa que va cambiando... (esto es una buena idea, y es posible, podria ser un modulo de animacion... creo que se viene un nuevo modulo...)

darío

No era esa la idea de los FBM que se quitó hace algún tiempo?
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

DCelso

un gif animado no se parece mas a un fpg que a un map? yo diría que es como un fpg con alguna información distinta como tiempo de frames.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

splinter_work

Quote from: DCelso on May 20, 2009, 08:13:09 PM
un gif animado no se parece mas a un fpg que a un map? yo diría que es como un fpg con alguna información distinta como tiempo de frames.

si y no...
si, en el hecho de que es una libreria de graficos...
no, en el hecho de que en un fpg los graficos no estan linkeados unos a otros... si tienen un orden pero no representan una animacion... sino una coleccion de graficos y no tienen tiempo... se podria suponer que cada grafico es una animacion secuencial, y se podria cargar un array con los tiempos, pero esta pensado para eso... y seria un poco confuso darle ese sentido...

splinter_work

Quote from: darío on May 20, 2009, 08:12:30 PM
No era esa la idea de los FBM que se quitó hace algún tiempo?

No realmente... vos sabes bien como era el formato del fbm, y tiene fallos a nivel conceptual como tambien lo tenia para integrarse a todo y como estaba implementado.

La idea actual seria que cada frame sea un mapa no asociado a ninguna lib (salvo la del sistema)... y que el modulo devuelva una estructura ANIM (como si fuera un FILE o un PAL) y que el modulo se encargue de animarlo actualizando el area de datos (puntero a la data) del grafico base, que es el mapa visible para el mundo de dicho grafico... con funciones del estilo:

- ANIM_GetMap (para poder asignar este valor a la variable graph o cualquier operacion de mapas)
- ANIM_Clone (para poder tener una misma animacion con diferentes momentos de animacion)
- ANIM_Destroy
- ANIM_Load
- ANIM_Stop
- ANIM_Start
- ANIM_Pause

en principio se me ocurren esas, sin posibilidad de edicion de estos archivos, pero podria ser una opcion interesante y rapida.