[DS] FAQ Programación en Multiplataforma

webez 12 mar 2006 13:33 *

MegaAdicto!!!

1.051 mensajes
desde dic 2003

Editado 1 vez. Última: 13/03/2006 - 18:49:49 por webez.

Bueno creo este post porque creo que hay una carencia de respuestas generales en cuanto a programación para la DS iré poniendo preguntas según se me ocurran y váis proponiendo más según veáis.

BASICO

P: ¿Qué necesito para empezar a programar?

Sólo necesitas bajarte devkitpro que puedes conseguir de aqui. http://www.devkitpro.org/
El devkitpro incluye el compilador, liberías para facilitar la programación y ejemplos. Además configura todo el entorno para que esté todo listo.

P: ¿En que lenguajes puedo programar?

El compilador soporta 3 lenguajes: ensamblador , C y C++ .

P: ¿Existe alguna librería o código para usar lenguaje script en la DS?

Actualmente hay 2 disponibles (aunque con sus limitaciones):
-Lua : http://www.dslua.com/
-Python : http://www.disinterest.org/NDS/Python24.html

P: ¿Tengo que hacerlo todo yo o hay alguna librería que facilite el desarrollo?

Lo primero es que realmente no necesitas ninguna librería para programar en la DS. Conociendo los registros puedes definirlo tu todo. Pero para los demás mortales hay unas librerías para facilitar el trabajo.

-Libnds : es la que viene con devkitpro y la que siempre está más al día en cuanto a funcionalidades básicas. Realmente es un pequeña abstracción de los registros que hace que no tengas que conocer todas las direcciones de memoria. Sin embargo la parte 3D tiene unas funciones muy similares a opengl.
http://sourceforge.net/projects/devkitpro

-PAlib : está librería proporciona funciones de más alto nivel que libnds. Facilita temas como el 2D o sistema de ficheros. En 3D y sonido aporta poco. Útil para el que no quiera profundizar mucho
http://www.palib.tk/

-SDL : actualmente en su versión 1.2.9, permite que la gente que conozca ésta librería pueda pasar sus proyectos de forma rápida. No sporta sonido ni sistema de ficheros.
http://gpf.dcemu.co.uk/

P:Bien y ahora, ¿Donde escribo el código y como lo compilo?

Para escribir el código puedes usar desde el notaped hasta programas más intuitivos como Programmers Notepad (inlcuido con devkitpro) o un IDE más avanzado. Especialmente recomendable Visual Studio .NET que podéis ver como configurarlo aqui
Para compilar tendrás que usar los makefile. Recomendable usar los que vienen con las respectivas librerías

CARACTERISTICAS TECNICAS

P: Bien ya se como empezar, ¿qué tengo que tener en cuenta a la hora de hacer las cosas?

Buena pregunta. He aquí un resumen de las cosas más importantes a tener en cuenta

-Memoria principal : hay 4 Mbytes de memoria para uso y disfrute. Eso significa que el código más lo que cargues en tiempo de ejecución no puede superar éste tamaño. Si utilizas un sistema de archivos podrás generer ejecutables mayores de 4Mbytes ya que los archivos no se cargaran en memoria hasta ser utilizados.

-Memoria gráfica :en está memoria se encuentran los gráficos, texturas o paletas que se están usando actualmente . En la DS esta memoria es bastante especial pues queda en manos del programador como asignarla. Y para más complicación ésta asignación no es totalmente libre. Como resumen decir que se tiene que distribuir entre las 2 pantallas y entre fondos, sprites, paletas y texturas. Casi nada.

-Sonido : el responsable de reproduir el sonido es el ARM7. ¿Y que me quieres decir con eso? te preguntas. Pues que es responsabilidad del programador establecer la comunicación entre ambos procesadores para que pueda leer y empezar su reproducción. Además la DS reproduce de forma nativa ADPCM y dispone de 16 canales de sonido

-Pantallas : realmente tendríamos que llamarlos "cores" pero asi nos entendemos mejor. La DS se divide internamente en pantalla "lógicas" principal y secundaria y es el programador el que elige en que pantalla "física" apareceran, puediendo en cualquier momento cambiarlas. A partir de ahora me referiré a ellas como principal y secundaria. La principal es la que tiene más posibilidades, y muy importante la única que puede mostrar directamente 3D (lo que no quiere decir que no haya formas de mostrarlo en las dos).

P: ¿Podrías explicar un poco más la memoria gráfica?

Bueno lo intentaremos, pero es todo bastante técnico. La DS posee 9 bancos de VRAM (memoria de video) que tienen que ser asignados a un propósitos en concreto de forma individual. Esta asignación consiste en enlazar direcciones de memoria con los bancos. Para saber el tamaño de cada banco asi como a que permiten asignarse recomiendo está dirección en la sección VRAM:
http://tobw.net/dswiki/index.php?title=Graphic_modes

Ahora trataremos de salir de la primera y mala impresión que nos dejan todos esos datos. ¿Qué nos interesa de ahi? Primero el tamaño de cada uno. Es un dato bastante obvio. Y después para que se usan. Este es su significado:

-Main_Bg : puede ser asignada para guardar fondos de la pantalla principal
-Sub_Bg : puede ser asignada para guardar fondos de la pantalla secudaria
-Main_Sprite : puede ser asignada para guardar sprites de la pantalla principal
-Sub_Sprite : puede ser asignada para guardar sprites de la pantalla secundaria
-Texture_slot : puede ser asignada para guardar texturas
-Bg_ext_palette : puede ser asignada para guardar paletas "extendidas" para los fondos de la pantalla principal
-Sub_Bg_ext_palette : puede ser asignada para guardar paletas "extendidas" para los fondos de la pantalla secundaria
-Obj_ext_palette : puede ser asignada para guardar paletas "extendidas" para los sprites de la pantalla principal
-Sub_sprite_ext_palette : puede ser asignada para guardar paletas "extendidas" para los sprites de la pantalla secundaria
-Tex_palette : puede ser asignada para guardar paletas de las texturas

Visto esto vemos que no podemos dedicar toda la memoria que queramos al propósito que queramos, sino adaptarnos a lo que hay

P: He oido que la DS no tiene fpu ¿que significa eso?

Pues significa que como tal la DS no sporta el tipo float y por tanto decimales. !Qué me cuentas! Pues si te cuento. Si bien el compilador permite su uso, realizar operaciones con floats produce un gran impacto en el rendimiento. Es por ello que se utilizan los llamados "números de coma fija" (fixed point numbers). ¿Y qué es esto? Pues utilizando un entero, se dedica cierta parte a la parte entera y otra a la parte decimal. A pesar de haber una cierta pérdida de precisión en los decimales, es absolutamente recomendable usarlos en la DS. En libnds el equivalente a float es f32 y hay múltiples macros para convertir cualquier tipo númerico a f32 y viceversa

ARCHIVOS

P: Vale, ahora quiero incluir imágenes, sonido o culquier tipo de archivo, ¿cómo lo hago?

Pues principalmente podemos dividirlo en 2 formas. Una usando un sistema de archivos y la otra generando cabeceras (.h) acompañadas de .c, .o o .s

P: ¿Y cómo genero esas cabeceras (.h)?

Aqui también tenemos principalmente 2 formas: por programas existentes o que hagamos nosotros, o usando reglas para ello en el makefile

-Por programas: éste método es el más sencillo de incluir archivos siempre que exista ya el programa para ello (PAGfx o gfx2gba por ejemplo). Estos programas normalmente generan un .h con las cabeceras y un .c con los arrays que contienen los datos. Para incluirlos en tu proyecto simplemente incluye los .h como siempre y usa los arrays para acceder a los datos

Por reglas en Makefile : esto es menos conocido. El makefile puede coger cualquier archivo y pasarlo a binario. En tiempo de compilación genera un .h (que tendrás que incluir en tu proyeto auqnue físicamente aun no esté creado). Estos son los pasos a seguir (usando los makefile que proporciona libnds en examples\templates)

-Poner los archivos en una carpeta data (por ejemplo) al mismo nivel que la de source (vamos source y data en la misma carpeta)
-Abrimos el makefile y al principio vemos que DATA está vacío.Ponemos

DATA :=data

-Al final del todo está la regla para convertir los archivos. Hay que añadir una por cada extensión (distingue entre mayúsuculas y minúsculas)

#---------------------------------------------------------------------------------
%.extension.o : %.extension
#---------------------------------------------------------------------------------
@echo $(notdir $<)
@$(bin2o) -include $(DEPENDS)

-Si tu archivo se llamaba archivo.jpeg generará un archivo_jpeg.h que es lo que tendrás que incluir en el proyecto
-En el .h encuentras lo siguiente (fin, datos y tamaño respectivamente)

extern const u8 archivo_jpeg_end[];
extern const u8 archivo_jpeg[];
extern const u32 archivo_jpeg_size;

P: ¿Y que me cuentas de los sistemas de archivos?

Un sistem de archivos es una serie de clases que permiten abrir los archivos sin tener que incluirlos implicitamente en el código. Hablaré un poco sobre algunos conocidos y sobre otros que no lo son tanto.

-GBFS : es el más antiguo (viene de gba) y viene incluido en libnds y PAlib (adaptándolo a su manera). Hay 2 formas de usarlo: una generando el archivo y compilándolo con el makefile como se indica anteriormente, y la otra que es la más interesante, "pegándola" después del código generado.
PROS: compatible con todo o casi todo el hardware existente y la mayoría de emuladores.
CONTRAS: sólo permite lectura. Todos los archivos tienen que estar en una sóla carpeta
http://www.pineight.com/gba/#gbfs

-PA_FS : el creador de las PAlib basándose en gbfs ha creado su sistema de archivos que hasta donde se tiene las mismas carácterísticas que el ya mencionado, añdiendo soporte para multiples carpetas.
PROS: supondremos que las mismas que gbfs añdiendo soporte para múltiples carpetas.
CONTRAS: sólo permite lectura. Sólo en PAlib

-FAT : es la única librería que permite acceso nativo a lastarjetas CF y SD para los diversos hardwares que las usan. Permite escritura y lectura de archivos, asi como navegación por la tarjeta
PROS: escritura y lectura en tarjetas CF y SD. Funciones similares a las tradicionales para apertura de ficheros
CONTRAS: problemática. A veces va a veces no. No todo el hardware está sportado y no de la misma forma. No compatible con emuladores. No está claro que un mal uso de la misma pueda dañar las tarjetas
http://www.geocities.com/chishm1/gbamp/

-romdiskFS : la más desconocida y menos usada. Poca información puedo daros salvo que implmenta el sistema de archivos ROMFS de Linux y que en prestaciones creo que es similar a gbfs.
PROS: -
CONTRAS: -
http://gpf.dcemu.co.uk/ndsromdisk.shtml

P: Bien, ya me hago una idea de lo que hay, ¿que me recomiendas?

Bien, aqui hay que tener las cosas bien claras y que queremos hacer. Usar .h tiene un gran incoveniente, y es que esos archivos se incluyen con el código al compilarse. ¿Qué significa esto? Que ese archivo SIEMPRE está en memoria y como sabréis la memoria no es algo que sobre. Esto es factible en proyectos pequeños que no supere su tamaño total el de la memoria. Por otra parte con un sistema de archivos el límite lo pone el soporte que utilicemos y los archivos se cargan en memoria según lo necesitemos.

LINKS

P: Me quedo con ganas de más ¿de donde puedo sacar más información?

Estos son todos los links sobre documentación técnica que he encontrado

http://neimod.com/dstek/
http://dualis.1emulation.com/dsti.html
http://www.bottledlight.com/ds/index.php/Main/HomePage
http://tobw.net/dswiki/index.php?title=Graphic_modes
http://www.drunkencoders.com/documents/DS/ndslib.htm

P: ¿Y unos tutoriales no tienes por ahi?

Aquí algunos tutoriales en inglés sobre la DS

http://www.double.co.nz/nintendo_ds/index.html
http://www.dspassme.com/programmers_guide/tutorial/

Para gba pero válidos en su mayoría para la DS
http://user.chem.tue.nl/jakvijn/tonc/toc.htm

Y sobre PAlib
http://www.palib.info/wiki/doku.php