Carga de Bitmaps desde disco-Posible nuevo juego

Claro que se puede cargar desde la tarjeta.

El formato con más profundidad de la DS es R5G5B5A1 (16 bit), pero ocupa mucho. Si puedes pasar alguna textura a imagen con paleta de 8 bits mejor (los colores siguen teniendo formato de 16 bit). De todos modos, piensa que tienes como mucho 512 kb para cargar texturas 3D, es decir...
(512 * 1024) / 2 (bytes por pixel) = 512 * 512, el tamaño de una textura que llenaría toda la memoria de video que se puede asignar a texturas.

Efectivamente, tendrías que reducir bastantes cosillas, y usar imágenes con paleta cuando sea posible.

Hay muchisimos programas para la ds que cargan imagenes en bmp desde la sd. Algunas aguantan hasta los 24 bits de color sin problemas:
http://nds.scenebeta.com/noticia/eagle

De todas formas, si quieres hacer un uso mas inteligente de la memoria. Olvidate de las palibs y programa a pelo con las libnds... Eso si, necesitaras conocerte el hardware de la ds para manejarlo sin problemas...

Saludos!

Buf, es chunguete eso, porque ya digo que cuento las imagenes por miles. Ya no solo sprites si no también tiles y fondos. Por lo que el método paleta queda casi descartado ya que hay tantas imagenes y tantos colores que no se podrían meter en una paleta de 256 colores.

La carga de imágenes al vuelo, con la poca potencia de ds y la escasa velocidad de lectura de sd lo hacen casi imposible creo yo. Necesito una sugerencia gorda al respecto ya que mi aplicación carga todo lo necesario para el menú y el juego base, es decir, sprites de el muñeco, las armas, los corazones, las monedas y otros objetos base, coleccionables como llaves y pociones, efectos especiales, cosas así, además de los tiles del nivel, la imagen de fondo,

No me es problema usar libnds si tengo las directrices de como hacerlo, es decir como dibujar sprites, dibujar texto, reproducir sonidos y leer la entrada de teclas y táctil. Y ante todo, poder manuipular sprites. Es decir, si tengo un bmp en memoria poder dibujar sobre él.

Si todo sale bien podría adaptar esto a ds:

amchacon escribió:Hay muchisimos programas para la ds que cargan imagenes en bmp desde la sd. Algunas aguantan hasta los 24 bits de color sin problemas:

Toma, y si nos ponemos podemos cargar imagenes de 64 bit (si hubiera)... pero para que la DS las acepte, tienen que reducirse a 16 bit, por lo que es bastante tonto gastar mas espacio y tiempo (porque convertir una imagen no es algo que se tarde poco).

Blue escribió:Buf, es chunguete eso, porque ya digo que cuento las imagenes por miles. Ya no solo sprites si no también tiles y fondos. Por lo que el método paleta queda casi descartado ya que hay tantas imagenes y tantos colores que no se podrían meter en una paleta de 256 colores. La carga de imágenes al vuelo, con la poca potencia de ds y la escasa velocidad de lectura de sd lo hacen casi imposible creo yo. Necesito una sugerencia gorda al respecto ya que mi aplicación carga todo lo necesario para el menú y el juego base, es decir, sprites de el muñeco, las armas, los corazones, las monedas y otros objetos base, coleccionables como llaves y pociones, efectos especiales, cosas así, además de los tiles del nivel, la imagen de fondo, No me es problema usar libnds si tengo las directrices de como hacerlo, es decir como dibujar sprites, dibujar texto, reproducir sonidos y leer la entrada de teclas y táctil. Y ante todo, poder manuipular sprites. Es decir, si tengo un bmp en memoria poder dibujar sobre él.

La velocidad de la SD no te permitiría cargar imágenes al vuelo, asi que eso para empezar descartado. Lo de las paletas... planteatelo. Si usas 3D puedes usar hasta 64+16 kb para paletas, y no hay un número fijo, simplemente las que quepan ahí. Mi Nitro Engine usa los 64 kb solo, y sobra muchísima memoria en todas las cosas que programo. Además una textura de 8 bit ocupa la mitad que una de 16, y eso en la DS hay que tenerlo muy en cuenta. Dibujar en texturas y tal si se puede hacer, es cojer el puntero a la memoria de la textura, esperar al VBlank, pasar a modo LCD la VRAM, escribir, y volver a poner la VRAM como memoria de texturas.

Lo de sonidos y datos de entrada es una chorrada, asi que por eso no te preocupes. Eso sí, la música a ser posible que sea en formato mod, xm o similares (y raw para los efectos de sonido).

el problema de las paletas es que tendría que cambiar de paleta por cada objeto que dibuje, cosa que no me hace nada de gracia. Pero es que convertir todas esas imágenes en paletas es parecido a suicidarse . y 64kb no da para tanta paleta.

Convertir las imagenes a 16bit no es problema, un procedimiento en photoshop y listo, pero aun así dudo que me quepa todo en memoria. Es un programa bastante pesado, la verdad. Me gustaría algo de ayuda personal al respecto, alguien que esté dispuesto a perder su tiempo ayudandome a renderizar la aplicación.

Hay alguna forma de unificar mediante alguna aplicación distintos bmps en una única paleta aunque implique perdidas de color?
Solo tendría la paleta del personaje, la de elementos de pantalla, y 4 para los escenarios en las distintas partes del día. La cuestión es poder hacer todo esto con 4 clicks.


Este es un ejemplo de un nivel:

Imágenes a calidad 24bits

Tamaño de sprites aproximado: 3,28 MB (3.442.294 bytes) En disco 5,17 MB (5.431.296 bytes)
Tamaño de tiles aproximado:417 KB (427.368 bytes) En disco 508 KB (520.192 bytes)
Tamaño de imagen de fondo: 225 KB (230.454 bytes) En disco 228 KB (233.472 bytes

Otros ficheros:
data (tamaño fijo)
Tamaño de nivel: 16,4 KB (16.800 bytes) En disco 24,0 KB (24.576 bytes)

sonido (diferentes rangos, se pueden reducir de tamaño)
Tamaño de sonidos (creciendo) 921 KB (944.069 bytes) 988 KB (1.011.712 bytes)

Música:
4-8 Mb (wav). Puede pasarse a mp3/ogg


Por no hablar de todas las estructuras que hay que tener en memoria, textos, etcétera.


Ya no hablemos de optimización de código para que se mueva a plena velocidad

Blue escribió:el problema de las paletas es que tendría que cambiar de paleta por cada objeto que dibuje, cosa que no me hace nada de gracia. Pero es que convertir todas esas imágenes en paletas es parecido a suicidarse . y 64kb no da para tanta paleta.

64*1024 / 2 (bytes por color) / 256 (máximo de colores) = 128 paletas de 256 colores... unas poquitas...

Blue escribió:Hay alguna forma de unificar mediante alguna aplicación distintos bmps en una única paleta aunque implique perdidas de color?
Solo tendría la paleta del personaje, la de elementos de pantalla, y 4 para los escenarios en las distintas partes del día. La cuestión es poder hacer todo esto con 4 clicks.

Que yo sepa el PAgfx hace algo así... no se de mas programas que lo hagan, pero alguno habrá...

Blue escribió:Este es un ejemplo de un nivel:

Imágenes a calidad 24bits

Tamaño de sprites aproximado: 3,28 MB (3.442.294 bytes) En disco 5,17 MB (5.431.296 bytes)
Tamaño de tiles aproximado:417 KB (427.368 bytes) En disco 508 KB (520.192 bytes)
Tamaño de imagen de fondo: 225 KB (230.454 bytes) En disco 228 KB (233.472 bytes

Otros ficheros:
data (tamaño fijo)
Tamaño de nivel: 16,4 KB (16.800 bytes) En disco 24,0 KB (24.576 bytes)

sonido (diferentes rangos, se pueden reducir de tamaño)
Tamaño de sonidos (creciendo) 921 KB (944.069 bytes) 988 KB (1.011.712 bytes)

Música:
4-8 Mb (wav). Puede pasarse a mp3/ogg


Por no hablar de todas las estructuras que hay que tener en memoria, textos, etcétera.


Ya no hablemos de optimización de código para que se mueva a plena velocidad

Bua, lo tienes bastante complicaillo... Primero haz las conversiones a los formatos que usarías ahora a ver si cuadra mejor en los 4 mb de la ds.

Por conversión, coje. al pasar a 8 bits implica dividir entre 3 ese espacio, por lo que si que cojería todo lo que es gráficos en 4 megas.
La cuestión es el resto, es decir, lo que ocupa en si la aplicación.

Textos y datos hay a porrón. Podría tener fácilmente 500 kb de datos entre información de los enemigos, textos de los menús, información del equipo, conversaciones y tal.

Y luego las estructuras. Es decir, aunque un bmp sea de 8 bits, la estructura que guarda esa información guardará sus dimensiones, su paleta, y a saber que más. Si guardo 1000 bitmaps en memoria, a parte de su tamaño habría que añadir un kilobyte por byte de infomación.

Y luego la cantidad de información que guarda la estructura animación




mas lo que tenga cada objeto Bitmap.
Ya hay más de 100 estructuras.

Voy a hacer una cosa. Cuando llegue a casa crearé una aplicación para DS desde cero y meteré lo que es el código de mi aplicación dentro borrando lo que es toda la carga, solo que cree estructuras vacías, y veré el tamaño de la rom. Si no voy a tener que empezar a quitar cosas, y me gustaría que quedase la aplicación íntegra.

Otra cosa. Hay virtual buffers? Me gustaría tener un buffer de memoria de 320x240 y dibujar en él, para luego reducur el tamaño a la ventana de ds mediante aceleración gráfica. Is it possible?

Blue escribió:Voy a hacer una cosa. Cuando llegue a casa crearé una aplicación para DS desde cero y meteré lo que es el código de mi aplicación dentro borrando lo que es toda la carga, solo que cree estructuras vacías, y veré el tamaño de la rom. Si no voy a tener que empezar a quitar cosas, y me gustaría que quedase la aplicación íntegra.

Otra cosa. Hay virtual buffers? Me gustaría tener un buffer de memoria de 320x240 y dibujar en él, para luego reducur el tamaño a la ventana de ds mediante aceleración gráfica. Is it possible?

Te respondo solo a eso, que lo de los numeritos no me hace gracia ahora mismo, jeje.

En 3D -> Matriz ortogonal para 2D -> Escalar pantalla para que 320x240 se ajusten a 256x192
Igual queda mal por el escalado, pero no se me ocurre otra cosa.

ANTONIOND escribió:

Blue escribió:Voy a hacer una cosa. Cuando llegue a casa crearé una aplicación para DS desde cero y meteré lo que es el código de mi aplicación dentro borrando lo que es toda la carga, solo que cree estructuras vacías, y veré el tamaño de la rom. Si no voy a tener que empezar a quitar cosas, y me gustaría que quedase la aplicación íntegra.

Otra cosa. Hay virtual buffers? Me gustaría tener un buffer de memoria de 320x240 y dibujar en él, para luego reducur el tamaño a la ventana de ds mediante aceleración gráfica. Is it possible?

Te respondo solo a eso, que lo de los numeritos no me hace gracia ahora mismo, jeje.

En 3D -> Matriz ortogonal para 2D -> Escalar pantalla para que 320x240 se ajusten a 256x192
Igual queda mal por el escalado, pero no se me ocurre otra cosa.

Se le puede añadir un blender para suavizar el zoom? No se que clase de efectos se puede hacer. No es mi primera aplicación con ds, pero no es que entrase mucho en el tema.

Blue escribió:Se le puede añadir un blender para suavizar el zoom? No se que clase de efectos se puede hacer. No es mi primera aplicación con ds, pero no es que entrase mucho en el tema.

Puessss... tiene antialias, pero solo funciona entre distintos polígonos... Y filtro para las texturas... el filtro birria ese de cojer el color del pixel mas cercano en lugar de mezclar... asi que mal vamos.

EDIT: De mezclar varios frames ni hablamos, que necesitarías gastar la cuarta parte de la ram de video dedicada a texturas...

ANTONIOND escribió:Bua, lo tienes bastante complicaillo... Primero haz las conversiones a los formatos que usarías ahora a ver si cuadra mejor en los 4 mb de la ds.

Primera vez que oigo que la capacidad maxima de un nds es de 4 mb.

Aqui te doy una prueba de lo contrario (este nds ocupa 13 mb):
http://nds.scenebeta.com/noticia/nightfox-colors

PD: lo de los 24 bits ha sido un gran fail, lo reconozco xDDD

amchacon escribió:

ANTONIOND escribió:Bua, lo tienes bastante complicaillo... Primero haz las conversiones a los formatos que usarías ahora a ver si cuadra mejor en los 4 mb de la ds.

Primera vez que oigo que la capacidad maxima de un nds es de 4 mb.

Aqui te doy una prueba de lo contrario (este nds ocupa 13 mb):
http://nds.scenebeta.com/noticia/nightfox-colors

PD: lo de los 24 bits ha sido un gran fail, lo reconozco xDDD

Segundo fail, yo también he visto juegos de 8 mb y similares.

No he dicho tamaño de la rom, me refería a la ram. Y bueno, EFS y nitrofs y todas las librerías que hacen eso lo único que hacen es "pegar" los archivos extra al nds, el límite de 4 mb sigue ahí, si no tienes acceso al sistema de archivos (fat, también vale la ram del cartucho en los flashcards de slot-2) ya puedes decir misa que no puedes hacer nada con esos archivos "pegados".

Si no, intenta añadir como datos a un nds mas de 4 mb. Es decir, cojes un archivo de mas de 4 mb, ponle de nombre "cosa.bin", lo pones en la carpeta "data", incluyes "cosa_bin.h" y haces alguna operacion... yo que se... int * cosa = cosa_bin; A ver si te deja el compilador. (Instrucciones para un template de libnds, claro)

ANTONIOND escribió:

amchacon escribió:

ANTONIOND escribió:Bua, lo tienes bastante complicaillo... Primero haz las conversiones a los formatos que usarías ahora a ver si cuadra mejor en los 4 mb de la ds.

Primera vez que oigo que la capacidad maxima de un nds es de 4 mb.

Aqui te doy una prueba de lo contrario (este nds ocupa 13 mb):
http://nds.scenebeta.com/noticia/nightfox-colors

PD: lo de los 24 bits ha sido un gran fail, lo reconozco xDDD

Segundo fail, yo también he visto juegos de 8 mb y similares.

No he dicho tamaño de la rom, me refería a la ram. Y bueno, EFS y nitrofs y todas las librerías que hacen eso lo único que hacen es "pegar" los archivos extra al nds, el límite de 4 mb sigue ahí, si no tienes acceso al sistema de archivos (fat, también vale la ram del cartucho en los flashcards de slot-2) ya puedes decir misa que no puedes hacer nada con esos archivos "pegados".

Si no, intenta añadir como datos a un nds mas de 4 mb. Es decir, cojes un archivo de mas de 4 mb, ponle de nombre "cosa.bin", lo pones en la carpeta "data", incluyes "cosa_bin.h" y haces alguna operacion... yo que se... int * cosa = cosa_bin; A ver si te deja el compilador. (Instrucciones para un template de libnds, claro)

Ahhh, te referias a la ram no a la capacidad del nds. Eso si que ha sido un fail xDDDD
Se que la ram de la ds es de 4 mb, por tanto los arm no pueden superar los 4 mb... Hay que "pegar" los datos a otros archivos del nds usando librerias como las efs o el nitrofs... Lo se, lo se.
Saludos!

Vamos a ver, desconozco como has programado el juego para ordenador, pero el tema de los sprites no creo que te sea muy molesto.
Teniendo en cuenta que hay 16 paletas, en las que puedes llegar a almacenar 256 colores, tienes un total de 16x256=4096 colores. No se cuantos sprites tienes, pero no creo que tengas tantos colores para llenar los 4096. Organizate para tener que usar el menor numero de paletas, ya sea metiendo los sprites con colores semejantes en las mismas paletas. Para los fondos no tienes mucho problema, ya que van aparte (creo que tambien tienen que ser de 256 colores), o podrias currarte los mapas tileados. Si vas a usar la efs lib, puedes llegar a cargar 128 sprites a la vez, supongo que no usaras todos los huecos para cada nivel. En fin, si me he confundido en algo corregidme

Si que uso los 128 sprites. Uso alrededor de 300 por lo que tengo que tirar de opengl. Ahora mismo he convertido todos mis bmps en binarios de 8 bits con paleta.

Alguien puede decirme como se carga la paleta y como se dibuja un sprite cargado? un ejemplo sencillo por favor.

Blue escribió:Si que uso los 128 sprites. Uso alrededor de 300 por lo que tengo que tirar de opengl. Ahora mismo he convertido todos mis bmps en binarios de 8 bits con paleta.

Alguien puede decirme como se carga la paleta y como se dibuja un sprite cargado? un ejemplo sencillo por favor.

vaya, no me referia a usar 128 sprites, si no que si te es necesario tener cargados 128 sprites a la vez, puesto que no creo que vayas a mostrarlos todos en la pantalla a la vez. Sobre los ejemplos sencillos, te puedes mirar la wiki de palib (si es que vas a usar palib, aunque dicen que son mejores las libnds). salu2

Suikoden77 escribió:(si es que vas a usar palib, aunque dicen que son mejores las libnds)

Es que son mejores...

Blue escribió:...

Si eso mañana te hago un ejemplo para cargar una textura o 2 con paleta y mostrarlas en la pantalla usando 3D.

ANTONIOND escribió:

Suikoden77 escribió:(si es que vas a usar palib, aunque dicen que son mejores las libnds)

Es que son mejores...

Blue escribió:...

Si eso mañana te hago un ejemplo para cargar una textura o 2 con paleta y mostrarlas en la pantalla usando 3D.

las libnds tienen alguna libreria para pasar datos en plan liblobby? en ese caso pasare todo mi proyecto a libnds

Suikoden77 escribió:las libnds tienen alguna libreria para pasar datos en plan liblobby? en ese caso pasare todo mi proyecto a libnds

Que las PAlib hayan incluído una librería (ojo, que no es parte de PAlib) que da bastantes problemas como liblobby (la he usado y se de lo que hablo) no tiene ningún mérito. PAlib es una librería llena de bugs, mientras que libnds no (es más sencilla, si, pero está más cuidada). Yo me volvía loco cuando usaba sprites con PAlib, a veces me borraba varios a la vez, si tienes varios sprites iguales se animan igual... En fin... Y eso por no hablar de otras cosas como la lectura del pad y la táctil, que PAlib hace cada VBlank sin importar que tu juego vaya más despacio, así que los eventos "Newpress" y "Released" se pierden a veces. Luego está el tema de añadir otras librerías, para lo que tienes q modificar el "PA_Makefile" y con ello modificar tooodo lo que compiles usando PAlib (a no ser que lo cambies otra vez). Luego está el tema del arm7... Varios binarios distintos... Pero no son precisamente una maravilla. Tener ASlib como librería de sonido principal es una burrada, porque los novatos se piensan que eso de reproducir mp3 es algo muy sencillo, cuando en realidad le cuesta mucho trabajo a la DS y tiene que ser evitado salvo que sepas muy bien que haces. Podría seguir hablando, por ejemplo, de la mierda de función de borrado de sprites 3D, o de lo poco práctico que es tener los bancos de VRAM asignados de forma fija a una tarea... Pero creo que con esto es suficiente...

De todos modos, si no recuerdo mal en gbadev vi unas funciones para mandar paquetes raw usando dswifi. Y supuestamente el autor de dswifi está trabajando en un modo "ad-hoc".

No sabía eso de palib. Menos mal que me decanté por libnds. Aunque todo hay que decirlo, es bastante más compleja. Acostumbrado a darle a dibujar_sprite(x,y), tener que cargar ahora texturas en memoria de video, cargar paletas y dibujar mediante quads se me está haciendo pesadísimo, y más con tanta llamada a métodos de iniciación que no se que demonios hacen xD. Pero suopongo que una vez tenga la forma de dibujar-dibujar alpha- dibujar rotado- dibujar invertido- dibujar con zoom- dibujar con efectos especiales- dibujar lineas y cuadrados- dibujar texto podré empezar a ver a que velocidad me funciona la aplicación

Ale, aquí tienes el ejemplo. Como base he cogido el de Paletted_Cube de libnds.

Gracias me pongo con ello a toquetear.

Veo chungo portar eso a DS.Lo ideal seria que esperes a que avance la scene en DSi, y lo programes para ella, ya que tiene 16 MB de RAM, y el procesador es un poco mas rapido ademas, podria ser el primer juego homebrew que aproveche las capacidades de DSi

Hero Of Time escribió:Veo chungo portar eso a DS.Lo ideal seria que esperes a que avance la scene en DSi, y lo programes para ella, ya que tiene 16 MB de RAM, y el procesador es un poco mas rapido ademas, podria ser el primer juego homebrew que aproveche las capacidades de DSi

tambien podria portalo a PSP (o a la dingoo o a la gp2x)

p.d.: tiene muy buena pinta el juego, y ademas da gusto oir hablar a antoniond temas de programacion