Estado del soporte archivos 1bpp?

Started by darío, February 18, 2016, 12:06:38 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

darío

Para poder dar soporte a los archivos nativos de Bennu/PixTudio en MonoDevelop estoy escribiendo una librería en .NET (el código está aquí debido a que todo empezó como un port a VB.NET de la librería bennulib que usaba SmartFpgEditor pero al final acabé migrando todo a C# y en breve crearé un repositorio en particular).

He estado mirando los sources de PixTudio y he visto que las funciones de carga incluyen soporte para archivos gráficos 1bpp (fuentes, maps y fpgs). Se sabe si funcionan este tipo de archivos? No tengo ninguno y antes de crearme uno a mano pregunto si alguien sabe algo...

Muchas gracias, un saludo,
Darío


My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

JaViS

Excelente noticia! :D esto abre un montón de posibilidades :D
Working on Anarkade. A couch multiplayer 2D shooter.

josebita

Todos los formatos gráficos cuya densidad sea < 16bpp se pueden utilizar en memoria (como mapas de durezas y cosas así) pero no se muestran en pantalla.
He estado dándole vueltas y la verdad es que hacer que se pinten esos gráficos es tan sencillo como tener un gráfico de la densidad que sea pero una textura de 32bpp siempre. Seguro que tiene sus pegas, pero creo que lo haré y así se volverá a poder pintar gráficos de densidades menores que 32bpp correctamente (los mapas de 16bpp ahora mismo no pintan el color 0 como transparente, lo cual tampoco es muy bueno),

panreyes

A mí me interesa poder elegir qué mapas se actualizan en la tarjeta gráfica. A veces hago mapas de durezas absurdamente grandes (en píxeles), y eso en 32bpp ocuparía una barbaridad de memoria.

josebita

Quote from: PiXeL on February 18, 2016, 09:46:19 AM
A mí me interesa poder elegir qué mapas se actualizan en la tarjeta gráfica. A veces hago mapas de durezas absurdamente grandes (en píxeles), y eso en 32bpp ocuparía una barbaridad de memoria.
Ya, por eso no lo he hecho. Es precisamente la clase de detalles de los que creo que el usuario de Bennu/PixTudio no debería tener que preocuparse... Podría añadir un flag a map_new que diga que no se renderice a una textura, pero ¿lo añado también a las funciones de carga de MAPs?

SplinterGU

Quote from: josebita on February 18, 2016, 10:02:44 AM
Quote from: PiXeL on February 18, 2016, 09:46:19 AM
A mí me interesa poder elegir qué mapas se actualizan en la tarjeta gráfica. A veces hago mapas de durezas absurdamente grandes (en píxeles), y eso en 32bpp ocuparía una barbaridad de memoria.
Ya, por eso no lo he hecho. Es precisamente la clase de detalles de los que creo que el usuario de Bennu/PixTudio no debería tener que preocuparse... Podría añadir un flag a map_new que diga que no se renderice a una textura, pero ¿lo añado también a las funciones de carga de MAPs?

lo ultimo que estuve trabajando en bennugd2 fue eso, poder elegir que tipo de bitmap es, teniendo por default texturas, pero ya no se como quedo, ahora que estoy de vuelta con esto lo revisare...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

josebita

Quote from: SplinterGU on February 18, 2016, 11:18:19 AM
lo ultimo que estuve trabajando en bennugd2 fue eso, poder elegir que tipo de bitmap es, teniendo por default texturas, pero ya no se como quedo, ahora que estoy de vuelta con esto lo revisare...
Agradezco sugerencias sobre una forma sensata/común de implementarlo de cara al usuario final.

SplinterGU

Quote from: josebita on February 18, 2016, 12:37:07 PM
Quote from: SplinterGU on February 18, 2016, 11:18:19 AM
lo ultimo que estuve trabajando en bennugd2 fue eso, poder elegir que tipo de bitmap es, teniendo por default texturas, pero ya no se como quedo, ahora que estoy de vuelta con esto lo revisare...
Agradezco sugerencias sobre una forma sensata/común de implementarlo de cara al usuario final.

estoy analizando en que estado deje todo y viendo si lo deje de una forma aceptable, porque lo ultimo que recuerdo es que habia estado batallando el asunto a nivel diseño, de que forma podia quedar coherente y sencillo... se que escribi codigo, tire y reescribi y dando vuelta atras varias veces... asi que cuando lo tenga resuelto te digo.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

panreyes

Josebita, yo propondría una flag global, justo antes de cargar o generar recursos, para decidir qué tipos de gráficos se deben guardar en VRAM.

No se me ocurre un nombre bueno, pero En plan MINIMUM_BPP_TO_VRAM=1/8/16/32

Y por defecto la dejaría en 16, ya que probablemente no se creen mapas de durezas de más de 8 bits.

Luego, la siguiente posibilidad sería añadir un tercer parámetro a todas las funciones de generación o carga de mapas/fpgs, pero eso ya será un trabajazo grande seguro.

josebita

Quote from: PiXeL on February 18, 2016, 01:02:17 PM
Josebita, yo propondría una flag global, justo antes de cargar o generar recursos, para decidir qué tipos de gráficos se deben guardar en VRAM.

No se me ocurre un nombre bueno, pero En plan MINIMUM_BPP_TO_VRAM=1/8/16/32

Y por defecto la dejaría en 16, ya que probablemente no se creen mapas de durezas de más de 8 bits.

Luego, la siguiente posibilidad sería añadir un tercer parámetro a todas las funciones de generación o carga de mapas/fpgs, pero eso ya será un trabajazo grande seguro.
Lo de la global no me gusta demasiado, la verdad. Añadir un parámetro es trabajo pero no es ninguna locura, pero no sé si me gusta demasiado desde el punto de vista de diseño.

JaViS

Y si se cargan todos los graficos como texturas por defecto, y existiera una funcion para descargar la textura  de un grafico en particular, para ahorrar memoria?
Working on Anarkade. A couch multiplayer 2D shooter.

SplinterGU

la global tampoco seria muy buena idea...

uno de las opciones que probe (no se si es la que quedo), es poder definir carga de graficos y/o creacion de mapas rendereables o no... o sea, donde aloja la data de los pixels... pero esta data no es rendereable, ni puede dibujarse encima, a menos que uno lo haga accediendo a los pixels... la idea de esto era para hacer mapas de durezas o incluso para modificar un grafico... PERO, luego esta data puede ser copiada/clonada a un mapa rendereable...
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

darío

Antes que nada, gracias por la respuesta (la conclusión es que sí, que debería dar soporte a 1bpp).


Otra opción a cargar los gráficos con texturas por defecto sería:


- Cargar solo los archivos de 32bpp como texturas pero hacer que el intérprete falle (error o warning) cuando se intente utilizar en un GRAPH una cosa que no sea una textura. El error/warning podría deshabilitarse quizás con un parámetro del intérprete. El error debería indicar claramente cuál es el problema y qué se recomienda (así como cuando git te dice: "no he podido hacer esto, pero podrías probar esto".


- Crear una función map_clone_as_texture() o map_clone_as_drawable() o similar que permita obtener una versión "representable" de los mapas para los casos en los que así se quiera. O incluso podría ser un parámetro del map_clone(). También podría llamarse algo como map_clone_32 o fpg_clone_32.


Motivos:


- Un usuario novel no es confundido por parámetros extra. Un usuario novel no es muy probable que utilice archivos de 8, 1 o 16bpp, y sí lo hace, tendrá un error que sabrá.


- Los usuarios avanzados tienen todas las opciones, pero son conscientes de lo que están haciendo en el caso de que cargen ese tipo de archivos. Tienen la posibilidad de "visualizarlos" cuando lo necesiten (por ejemplo, debugging purposes), sin recurrir en gasto de memoria innecesario (si solo quieren la versión de 32bpp, basta un unload_map en el mapa original)






My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats

SplinterGU

en bgd2 se pueden cargar cualquier grafico y se convierte la textura a 32bits internamente.
Download Lastest BennuGD Release: http://www.bennugd.org/node/2

Drumpi

#14
Yo me resisto a abandonar la idea de tener mapas de 8 bits representables en pantalla, y que sean modificables mediante paletas en runtime, especialmente porque luego, para cambiar un color en concreto, tenemos los problemas de que en 16bits no se correspondían los mismos RGB en diferentes tarjetas gráficas y teníamos que recurrir a "trucos" como mapas de los que obteníamos los valores mediante map_get_pixel + rgb en plan paletas.
Habría que usar las tablas de blendops, que serían enormes (2^16 * 2 o 2^32 * 2, según profundidad de color)... a menos que dichas tablas se reduzcan a los colores que sufren alguna modificación, o se realicen operaciones a grupos de ellos.
Y luego los gráficos de 1bit, que dependían de DRAWING_COLOR, igual que las primitivas gráficas y los textos.

Si no entiendo mal, el problema que tenemos ahora es que tenemos dos tipos de memoria: la RAM y la VideoRAM, en la segunda hay que cargar los gráficos que se van a ver, y el resto van en la RAM ¿no? Bueno, ideas que planteo.

- El nuevo parámetro: pues eso, indicar con un nuevo parámetro si se va a ver o no, o qué tipo de imágen estamos cargando.
- Un nuevo set de instrucciones: tener LOAD_MAP para los mapas de bits, como hasta ahora, y LOAD_GRAPH para cargar gráficos que se van a ver en pantalla.
- Autoflag: hacer que el sistema los cargue todos en la RAM, pero si alguno de los mapas es asignado a la variable GRAPH de algún proceso, este se mueva de la RAM a la VRAM. Sería una carga a dos tiempos, pero a la hora de descargar quizás se podría hacer un sistema automático de descarga de VRAM a la RAM tras la ejecución de todos los procesos o en algún tiempo muerto posterior. Y corregidme si me equivoco, pero el paso de RAM a VRAM es infinitamente más rápido que la carga habitual a la RAM. Otro problema sería que si se carga un FPG, y este contiene "mapas de durezas" (o mapas que no se van a ver) y "texturas" (mapas que sí se van a ver) mezcladas, no sé si es posible leer de RAM y VRAM al mismo tiempo.
- Flag manual: similar al paso anterior, pero el paso de la RAM a la VRAM se efectúa si al proceso se le modifica una variable local, algo tipo "flag_visible" o "flag_vram". Obviamente si el mapa se ha cargado anteriormente, no se crea otra copia.

Y a todo esto, las modificaciones en los mapas ¿se harían todos desde la VRAM o se pueden hacer indistintamente en ambas memorias? Por el tema de MAP_XPUTNP, por ejemplo. ¿O tendríamos restricciones en estas operaciones según si son "mapas de bits" (RAM) o "gráficos" (VRAM)?
Si no hay problemas de distinción, yo creo que de cara al usuario la tercera opción sería la ideal, que UNLOAD_MAP o GRAPH = 0 marque el mapa de VRAM como "dirty" para comprobar si debe borrarse o no, si aun está en uso por otro proceso en su variable GRAPH, y hacer una especie de "recolector de basura" (y a las malas, tener una instrucción avanzada tipo FORCE_VRAM_UNLOAD, para los que odiamos los recolectores de basura).

No sé si os sirve de algo, yo digo lo que se me ocurre ^^U
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)