hola, este post es para presentar lo que llevo en un módulo para cargar bmp, y a la vez para pedir ayuda en map_buffer ;)
abajo tengo el módulo y un ejemplo funcionando, el problema es que el tiempo que tarda en cargar gráficos de 1280*1024 o gráficos de 16 colores es muy grande (el de 16 colores por todas las transformaciones binarias).
imagino que con map_buffer obtendré mejores velocidade que con put_pixel, sin embargo me interesa que sean mapas de 32 bits, así que si map_buffer no trabaja así.... me lo dicen :-[ .
también quiero preguntarles sobre sugerencias y todo lo que puedan aportar es bueno. ya que, cuando publiqué en ayuda, ayer, nadie me respondió :-[ ... imagino la razón... je je je
nos vemos luego :)
pd ¿qué tan bueno es inlcuir lectura de bmp comprimido si es rarísimo encontrar un bmp comprimido (según lo que leí)?
hola, he modificado las funcinones, ahora los bmp de 2,16 y 256 colores se cargan como mapas de 8 bits, los de 16 teóricamente de 16 bits y los de 32 de 32bits. he corregido bugs y aumentado la velocidad de carga. actualmente lo uso en el editor fpg y funciona a la perfección. no abre bmp con compresión, (devuelve -1).
también agrego unas funciones para cambiar de 8 a 16 y 32 bits, de 32 a 8 y 16, y teóricamente de 16 a 8 y 32 (no he tenido la ocación de probar los últimos, en cuanto lo haga y si hay errores lo corrijo). bueno, pongo los enlaces.
las funciones deben correr en modo de 32 bits para funcionar, ya que a 16 bits un color de 16 bits tiene como máximo, de cada color, 255, y a 32 bits tiene 31 y 63 ;)
El ejemplo compila y funciona correctamente, pero para ejecutar desde el Crimson Editor da un problema, ya que el nombre del fuente lleva un espacio y no es capaz de ejecutar el .dcb si su nombre tiene algún espacio (He cambiado el nombre "abrir este.prg" por "abrir.prg" y sin problemas).
En cualquier caso, siento no poder ayudarte, nunca había oído hablar de map_buffer... No me extraña que no te respondieran la vez anterior, preguntas sobre cosas bastante retorcidas xD
Lectura de un bmp comprimido... No lo veo mucho sentido, no estaba al corriente de que existiesen.
Espero que alguien pueda echarte una mano con ese map_buffer, salu2!
Hombre, responderte te podría responder, pero es algo tan vago:
Se que te devuelve el puntero a la primera direccion de memoria del mapa, una vez que te leas los campos del mapa (no me preguntes cuales son porque no lo se), ya vienen los datos: cada pixel se representa por un número de bytes igual a la profundidad (256 colores-> 1B, 16bits-> 2bytes en formato 565, 32bits -> 4B (RGBA, un byte por cada)
Lo de los campos, o son los del registro que usa internamente Bennu para guardar los mapas, o son los que guarda en el formato MAP, pero me inclino más por lo primero. eso es tan a bajo nivel que o te lo dice splinter, o investigas por el código (lectura bastante interesante, por cierto)
Mmmhhh... Todavía no me he puesto a mirar los fuentes de las librerías de Bennu, qué morbo tiene que dar... Echaré un vistazo ya que lo propones ;)
map_buffer apunta a los pixels del mapa, no apunta a la informacion del mismo.
je je je, ya había investigado. map buffer devuelve el puntero a el código del color de cada pixel (el puntero al primero, y desde ahi podemos leer y escribir los otros), ya aprendí el uso y .... el problema es que usándolo tarda un segundo más en cargar que usando map_put (un bmp de 1280*1024 me tardó con map buffer 4 seg, y con map_put 3 seg aprox), supongo que es porque para map_buffer tengo que saber lìmites de lectura del buffer para no leer fuera del array, y algunas otras cosas que me pasan por inexperto...
he decidido dejarlo con map put, sin embargo map_buffer puede ayudarme a generar efectos muy buenos.
estoy investigando otros formatos y algunas particularidades del bmp para completar el código éste.
gracias por sus comentarios. :)
Quote from: SplinterGU on April 23, 2009, 10:48:37 PM
map_buffer apunta a los pixels del mapa, no apunta a la informacion del mismo.
Eso no es lo que me dijiste la última vez que te pregunté.
Quote from: Drumpi on April 24, 2009, 11:11:29 AM
Quote from: SplinterGU on April 23, 2009, 10:48:37 PM
map_buffer apunta a los pixels del mapa, no apunta a la informacion del mismo.
Eso no es lo que me dijiste la última vez que te pregunté.
Siempre fue asi, quizas hubo una mala interpretacion, pero siempre dije que map_buffer apunta al area de datos/pixels del mapa. Y cuando digo datos no me refiero a la estructura interna sino a los pixels, por otro lado, no tiene sentido devolver estructuras internas, donde, 1) no se conoce a nivel usuario y 2) seria una horrible limitacion en pro de la compatibilidad entre versiones para el usuario.
Okis, reemplazando información en el banco de datos...
Información actualizada.
Pulse OMBLIGO para continuar...
jeje
modificadas las funciones...
... al fin comienzo a entender la funciones de paletas. dentro de poco presentaré el editor fpg. sólo agrego cargado de paleta (al comenzar fpg de 8 bits), una fuente de 16 para el entorno, conversión de fpgs completos, y ya... todo lo demás se ve muy bien... je je je... eso de cargar bmp me emocionó mucho, sin embargo tarda un poco en cargar más de 40 así que los que pesan más de cierta cantidad no se cargan en previsualización, pero sí a la hora de pasarlos... ;D
Hola PRG, no es por desanimarte pero veo un poco tonto cargar bmps, suelen ocupar mucho más que los pngs, además por lo que comentas tardan más en cargarse. ¿Qué ventajas le ves?
Sería más interesante que bennu pudiera usar imágenes vectoriales debido a sus grandes ventajas, por ejemplo los archivos SVG (http://es.wikipedia.org/wiki/.svg) que puedes crear con inkscape.
Hombre, por algo hay que empezar, y los BMP son lo más sencillo de leer. Es normal que tarden más en cargar: son más datos y se está haciendo por código Bennu, si se metiera en una dll... o módulo... o lo que se use ahora :D pues tardaría la mitad o menos.
Se podrían leer SVG, pero al pasarlo a MAP perderíamos lo mejor del formato, ya no sería vectorial y al reescalar se celebraría la fiesta de los pixelacos. Otra cosa sería crear el módulo correspondiente para que tratase los SVG como gráficos realmente vectoriales.
entre más formatos pueda cargar un editor fpg mejor... no es verdad? después de todo al meterse al fpg, dejan de pesar mucho, pues forman parte del fpg.
Pues sí, tienes razón. Visto así, no hay nada que decir.
De camino te sirve para aprender.
je je ;)
Un detallito sin importancia: que no se olvide el formato MAP, como pasó con el FPGEdit XD
no, no te preocupes, en mi editor podemos cargar *.map (también bmp,png,pcx) y exportarlo también
A ver si algún día consigo interpertar el código de los GIF y te lo paso. Quiero hacer un conversor GIF->MAP o GIF->FPG, pero el algoritmo LZW se me resiste (ya ha caducado la licencia, al parecer).
seguro que caduco?
Parece fácil leyendo las especificaciones, claro que otra cosa es ponerse a implementarlo.
http://es.kioskea.net/contents/video/format-gif.php3
Sí, el algoritmo del GIF ya ha caducado.
http://en.wikipedia.org/wiki/Gif
QuoteA ver si algún día consigo interpertar el código de los GIF y te lo paso. Quiero hacer un conversor GIF->MAP o GIF->FPG, pero el algoritmo LZW se me resiste (ya ha caducado la licencia, al parecer).
muchas gracias amigo, sería muy bueno :)
Quote from: SplinterGU on May 12, 2009, 10:40:18 AM
seguro que caduco?
No sólo ha caducado, sino que la libungif ha dejado de actualizarse para dar paso a la ¿lgif se llamaba?
Me di cuenta cuando buscaba el paquete de la libungif para recompilar Fenix para mi ubuntu (me sigue haciendo "cosas raras").
Así que, en teoría, el MAP.exe de Bennu podría tenerlo sin problemas.
Lo que es el GIF es sencillo de leer (salvo el tema de las paletas, que aun no me acabo de aclarar, porque el la especificación general se habla de una paleta de un tamaño, y luego cada imagen puede usar su propia paleta, modificando valores de la principal... no recuerdo bien, hace un año que no toco el código que puse aqui (http://www.fenixworld.com/e107_plugins//depot/files/fw75.lectorgif.zip) (no se si es el último que tengo)). El problema es cuando llega la hora de descomprimir la imagen, no sólo por la serie de pasos que hay que seguir (que en los sitios que miré no dejan claras las cosas), sino tambien porque el tamaño de los datos es de ancho variable (puede empezar teniendo 4 bits cada dato y terminar con 9 bits).
En fin, que es algo que aun le tengo que dar un buen repaso.