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í (https://bitbucket.org/dacucar/smart-fpg-editor/src/7769405f1b8f814bbde3483e532507be08fc2536/net-bridge/BennuLib/?at=net-bridge)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
Excelente noticia! :D esto abre un montón de posibilidades :D
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),
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.
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?
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...
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.
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.
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.
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.
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?
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...
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)
en bgd2 se pueden cargar cualquier grafico y se convierte la textura a 32bits internamente.
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
no es tan simple drumpi... y las operaciones de paso entre una memoria a otra son muy costosas, no son para nada rapidas.
si mal no recuerdo, en opengl no tenes paletas 8bits...
tampoco podes modificar facilmente lo que ya cargaste, tenes que descargarlo a ram, modificarlo y luego mandarlo de nuevo a vram... y no con todas las texturas se puede, hay que copiar/transformar y otras operaciones costosas... todas son costosas, y el rendimiento seria peor que hacer render por soft...
podes renderizar una textura sobre otra, pero no es una filosofia diferente...
es un mundo bastante distinto...
Lo que quiere drumpi se soluciona facilmente con lo que yo he propuesto. Puesto que los mapas de 8bits tienen q ser explicitamente convertidos en nuevos mapas de 32 el que quiera cambiar la paleta lo puede hacer, pero tendra q recrear el grafico de 32. Todos los colores de un map de 8 bita son representables en 32 argb...
Algo hay que hacer, porque los cambios de color en un mapa directamente siempre terminan perdiendo información. Es decir, si yo paso todos los pixels rojos a azules, después no puedo deshacer la acción, porque los que ya eran azules también se volverían rojos.
La ventaja de las paletas era eso, que era un "filtro" que convertía de unos colores a otros, y no perdías información (repetías colores visualmente, pero no era el mismo color).
Si tan costosas son las modificaciones de los mapas, entonces se pierden muchísimas cosas interesantes, entre ellas, el scroll a mapa ¿no? Recuerdo cuando usaba VSE (librería que permitía crear modos7 con alturas), necesitaba un mapa de textura y otro de alturas, y modificando el segundo en runtime con DRAW_BOX hacía plataformas móviles. Ni qué decir de, por ejemplo, hacer efectos de olas en el agua y...
Bueno, siempre puedo seguir con BennuGD r307 :D :D :D
no, scroll a mapa es un render de una textura sobre otra, son 2 texturas que no van a RAM.
Yo es que no he llegado a trabajar con VRAM, así que no sé cómo va eso ^^U
Y eso de render de una textura sobre otra ¿cómo va?
¿Sería posible hacerlo teniendo una tabla de conversión de 256 colores concretos? Lo digo porque se podría tener para 8 bits dos mapas guardados: uno con la info de color original (el valor de la posición de la paleta), y otro donde se copie pero con los colores transformados de byte(paleta) a int(rgb).
No sé, sería lo ideal, tener la textura en la VRAM con pixels de 8bits, y la tabla de transformación a RGBA (paleta), y que sea la gráfica la que haga la conversión sobre la imágen en 32bits (no sé si se puede usar el multiprocesamiento de la GPU para eso, o si lo permite SDL u OpenGL).
Tampoco sé cuán costoso es el paso de RAM -> VRAM ¿Más de de tarjeta SD -> RAM, que de RAM -> RAM y que las herramientas PUT?
no recuerdo el tema con los 8bits, pero las pruebas fueron quebraderos de cabeza, y un sin fin de no resultados...
con respecto al multiprocesamiento de la GPU, lamento informar (que creo es por limitaciones SDL, no me acuerdo, tengo que volver a mirar los fuentes de SDL), no permite multiprocesamiento, o sea, las texturas generadas en un thread sirven solo para ese thread, incluso no recuerdo si es a nivel global de la implementacion... lo seguro es que el multiprocesamiento es un problema... de hecho tengo problemas para los load de graficos en background, porque creo la textura en la carga... o quizas era a nivel surface... voy a tener que splitear un poco mas la cosa... ya vere, son varias cosas que estoy viendo a la vez... y ahora que estoy un poco entusiasmado estoy metiendo mano al asunto...
En realidad no hablaba del multithreading clásico de las CPUs, más bien de que, internamente, las GPUs llevan cientos de hilos de ejecución simultaneos, usados para hacer operaciones de multiplicación+suma de forma paralela y masiva.
Pero claro, yo hablo de HW y de fotos de rayos-x tomadas a viejas GPUs de la época del Pentium II :D
Si supiera más de eso, o de OpenGL o de SDL, sería de más ayuda, pero ahora sólo puedo dar tiros a ciegas, con la esperanza de encenderle una luz a alguien.
Me gustaría poder ayudar, pero tendría que entrar haciendo algo pequeño, e ir ampliando mi alcance poco a poco al resto del código... y ahora estoy en modo "terminar proyectos" (Montezuma, el juego de la Jam del año pasado, el TFM... incluso he estado leyendo esta noche el worklog que escribí en el foro del Echo, dado que me ha dado por revisar el código del editor de mapas de tiles 2.0, para poder terminarlo).
ahi ya no se, supongo que si lo hace el GPU.
Lo que dice Splinter es correcto: en SDL las texturas creadas desde hilos que no sean el principal no son válidas.
Sobre lo que habláis: creo que previamente lo que busca vulkan es dar control al programador sobre esa clase de cosas, aunque no sé mucho de eso...
Volviendo a retomar el tema original (archivos 1bpp). Tengo otra duda:
- En Bennu, imagino que sí que se pueden pintar estos gráficos en pantalla. El color 0 se considera opaco o transparante? Cambia la respuesta en función de si el modo de video es de 16 o 32? Qué ocurre con el modo 8? Es posible hacer un set_mode a 1bpp? (Cool! :D)
Gracias! (a cambio de toda esta información en breve tendréis una librería en .NET con soporte para todos los archivos Bennu/PixTudio)... Así el que quiera hacer editores FPG, FNT, MAP o PAL ya no tendrá excusa...
Darío
Hasta donde recuerdo, los mapas de 1bpp son tratados de la misma manera que las primitivas gráficas o los textos de 1bpp (por ejemplo, la fuente del sistema): usan dos colores, el transparente y el que se defina mediante DRAWING_COLOR (bueno, los textos tiene SET_TEXT_COLOR, pero ya me entiendes).
Eso debería funcionar en todos los modos de color.
No recuerdo que existiera un modo de color de 1bit, pero tras ver lo que se hace con el emulador de Pico8 te dan ganas de que incluso haya modo de 3 ó 4 bits :D :D :D
Lo que no se si llegué a entender bien es que si una línea de un mapa no es múltiplo de 8, los bits sobrantes del último byte se descartan ¿no?