Kana DS

Learning Japanese writing on the Nintendo DS

23 February, 2007

Menú principal rediseñado, empollando Unicode

Ya he modificado el menú principal respecto a los cambios que propuse en la anterior entrada. Aun no he actualizado los ficheros en la forja, pero tiene este aspecto:

Me gustaria implementar ya alguno de los mini-juegos, pero antes tengo que terminar una tarea inesperadamente dura: el manejo de texto en japonés. En un principio, los textos asociados a cada juego van en ficheros .txt con codificación UTF-8. Tengo que investigar un poco más sobre las capacidades de newlib para tratar con 'widechar' strings, pero creo que me va a tocar hacerme al menos un parser de UTF-8. Luego en memoria ya veremos que TAD uso para las cadenas...

Una vez tenga los textos en japonés en memoria, necesitaré una fuente gráfica para todos los caracteres hiragana, katakana, y unos 80 kanjis. Voy a ponerlos todos en un bitmap, organizándolos de alguna manera respecto a su orden en Unicode, para que luego las funciones de pintado sean lo más sencillas y rápidas posible.

Algunos enlaces sobre lo comentado:

17 February, 2007

Yosh!

Al igual que el resto de concursantes, voy con retraso en el proyecto. Sólo quedan dos meses escasos, y mucho trabajo por delante. Sin embargo, mi meta inicial no era terminar el juego completo, sino lograr un prototipo avanzado, con las funcionalidades básicas y varios de los mini-juegos. Creo que aun tengo tiempo para lograrlo, veremos.

Precisamente por esta falta de tiempo los contenidos del juego sólo van a estar -de momento- en inglés. Traducir todo es fácil, pero implementar ahora mecanismos de localización decentes supondrían un tiempo que prefiero invertir en otra funcionalidad. Como el proyecto no termina al final del Concurso, sino que seguirá hacia delante, ya habrá tiempo para añadir más idiomas.

Éste es el aspecto del menú principal, y el menú de consulta de silabarios y kanji:

kana ds

Desde el punto de vista de la usabilidad, me auto-propongo los siguientes cambios:
  • Usar iconos junto a texto en menú principal.
  • Ajustar el tamaño de los botones segun su importancia. Por ejemplo, agrandar "start practice" y hacer "options" más pequeño.
  • Sustituir la etiqueta "back" en el menú de consulta por un simple icono.
Generalmente, cuando menos texto contenga una interfaz mejor, pero tampoco se puede prescindir totalmente de él, ya que a veces es imposible deducir la función exacta de un elmento mediante su icono.

Comentar estas decisiones y cambios es precisamente lo que le da valor a esta entrada, y hace que enseñar algo a medias tenga sentido. Una vez tenga el menú de consulta más o menos funcional(exceptuando quizá la parte de kanjis), pasaré a implementar las fuentes gráficas con el alfabeto inglés y los silabarios hiragana/katakana, que serán empleados en los mini-juegos.

Ah, se me olvidaba: todo lo que he mostrado no es final, el diseño, colores y funcionalidad de los menús irán cambiando. Aun así, cada 10 dias aproximadamente publicaré una "release" en la forja, por si alguien quiere curiosear. De momento podeis probar la primera release pre-alpha, que no es más que dos menús con escasa interacción.

13 February, 2007

Status: 2

Por fin he comenzado a picar código y voy usando el repositorio SVN regularmente. He aprovechado para cambiar el estado del proyecto en la forja, de (1) 'planning' a (2) 'pre-alpha'. Me voy ayudando con un diagrama de casos 'rústico' y algunos casos de uso, pero aun queda por lo menos un mes hasta que tenga algo jugable. Ya iré comentando los progresos por aquí.

Comentar tambien que el código ya hace uso de la nueva revisión de DevKitPRO (R20) y Libnds que aparecieron hace varias semanas. Se han corregido unos cuantos bugs en las librerias y renombrado la mayoría de constantes de Libnds para conseguir una mayor consistencia respecto a la documentación que hay en la red.

Ah, por cierto: Rudolph Steady Go! consiguió el segundo puesto en la DrunkenCoders Xmas Compo! Una pequeña motivación más para continuar trabajando..

02 February, 2007

Arquitectura de Nintendo DS (III)

Este es el último artículo sobre la arquitectura de Nintendo DS. En el primero mostré un mapa de memoria de la consola, incluída la memoria de vídeo. Esta vez voy a poner un ejemplo práctico con la asignación de bancos de vídeo que he usado en Rudolph Steady Go!

Cuando comienza el juego activo el modo de vídeo 5 con las funciones de Libnds:
videoSetMode(MODE_5_2D | DISPLAY_BG3_ACTIVE );
videoSetMode( MODE_5_2D | DISPLAY_BG3_ACTIVE | DISPLAY_BG2_ACTIVE);

vramSetMainBanks( VRAM_A_MAIN_BG_0x6000000, VRAM_B_MAIN_BG_0x6020000, VRAM_C_SUB_BG_0x6200000 , VRAM_D_MAIN_BG_0x6040000 );

BG2_CR = BG_BMP8_256x256 | BG_BMP_BASE(16) | BG_PRIORITY(0);
BG3_CR = BG_BMP8_256x256 | BG_BMP_BASE(0) | BG_PRIORITY(3);

SUB_BG2_CR = BG_BMP8_256x256;

El código anterior no está completo, ya que faltan algunas funciones que no necesito repetir y que llamo al comienzo del juego, cuando se inicializa el modo gráfico para el menú principal. Gráficamente la asignación de memoria y uso de los bancos queda así:

CLICK PARA AGRANDAR

Como los contenidos del banco C (pantalla superior) y el A(fondo de la pantalla inferior) no se actualizan frecuentemente, no uso ninguna técnica especial para pintar en ellos. Simplemente transfiero bloques de memoria para actualizar ciertas zonas, como los marcadores de puntuación y las ardillas.

En cambio el plano que se superpone al A(pantalla inferior), y que muestra los círculos y botones que hay que pulsar, se actualiza constantemente cada frame. Por ello, para evitar parpadeos y que la animación sea lo más suave posible utilizo un esquema de doble búfer: Voy alternando los bancos B y D, de manera que nunca pinto en el banco que se está mostrando en el frame actual. De la superposición de varios planos ya se encarga la consola, basta especificar una prioridad o valor-Z a cada banco. En este caso se superponen los bancos B/D sobre el A.

En el modo 5, cada una de las dos pantallas tiene asignada una paleta de 256 colores, entendiéndose el índice 0 (cero) como color transparente. Con otros modos de vídeo se pueden usar hasta 16 bits de color, reservando el último bit para marcar los píxeles tranparentes.

Con este juego no he utilizado el motor de sprites (OAM) ni los modos de vídeo para 'tiles', cuyo uso es necesario para casi cualquier cosa que implique planos de scroll o escenarios grandes.

Más información sobre los modos de vídeo en Dev-Scene.