Introducción
Voy a intentar escribir un log de desarrollo del emulador donde vaya mostrando a grandes razgos que y como voy construyendo una pieza de software para que cumpla (mas o menos) con algunos lineamientos de eso que llaman "buenas prácticas de programación".
Para los que no saben, 3d'oh -en adelante "3doh" a secas para no tener que escribir la comilla- es un emulador de la consola 3do (Fabricada por un consorcio entre la empresa 3do, Panasonic, Sanyo y Goldstar). Larga historia hecha corta, lean el resto en su enciclopedia amiga, por ejemplo en http://es.wikipedia.org/wiki/3DO_Interactive_Multiplayer.
Hace unos años el proyecto Freedo liberó el source del núcleo de emulación de 3do, llamado "Freedo" (lol). A partir de allí se puede armar un emulador simplemente "enganchando" el video, sonido y controles con algunas lineas de código. Hasta ahora hubo pocos proyectos que hicieron esto, entre ellos 4DO, 3DOx y creo que alguno suelto por ahí para GNU/Linux. Con mi hermano siempre venimos pensando en portear algunos emus a GNU/Linux, porque el soporte que se le da a la emulación es bastante pobre (no tenemos idea la razón de fondo). Freedo estaba disponible, yo estaba al pedo y me gustaba la consola, así que en un rato de ocio extremo nació este proyecto.
Empezando el proyecto
El proyecto inicial era bastante simple y la idea era primero "probar si anda", cuestión de saber como funciona la librería de Freedo (leyendo los sources de 4do se resuelve ese asunto) y escribir código propio para hacerlo funcionar, la verdad fue bastante simple y en pocos días ya tenía algo funcionando. La cosa se complica cuando se comienza a armar un proyecto serio, con lineamientos como:
- Multiplataforma.
- Debe incluir una GUI.
- Debe ser altamente configurable.
- Fácil de usar.
- Tiene que funcionar rápido.
- Estable.
Por supuesto otra de las limitaciones está en el conocimiento limitado que tengo sobre el asunto, escribir software es dificil, escribir un emulador es MAS DIFICIL. Siempre tuve como "heroes" a esos tipos del MAME que con sus manos desnudas se atrevieron a enfrentarse a cuanto hardware raro se les puso encima para emularlo, son como una especie de estrellas del rock, son inalcanzables, tienen todas las mujeres, autos deportivos, casas de oro...bueno, creo que no, pero igual son buenos. En síntesis, es un mundo demasiado complejo para un niñito indefenso como yo.
El nombre
Otra cuestión que puede parecer estúpida es el nombre. Por experiencia propia, el nombre de un emulador debe representar varias cosas, primero tiene que ser representativo a la consola que emula y segundo no tiene que ser un nombre estúpido. Sin entrar en detalles, estaba en una encrucijada...empecé a tirar nombres y con la ayuda del amigo
DCERIC, surgió una idea que derivó en el nombre. No es EL NOMBRE, pero al menos es representativo...
Lenguaje, Librerías, Compiladores
En este aspecto no anduve con vueltas, no hay nada más simple que C, no hay nada mas performante que el C (salvo el assembler o el código de máquina, pero eso se lo dejo a los rusos locos). Para el resto una mezcla entre SDL y OpenGL hace el trabajo, pero también tenía que dejar abierta la posibilidad de no utilizar OpenGL, ya que hay plataformas que no lo soportan (como mi tablet), por eso también agregue esa posibilidad y seguramente en el futuro un backend en OpenGLES también va a ser necesario. Como ven se empieza por una boludez y se termina escribiendo diez veces lo mismo, todo sea por la inclusión.
Respecto a compiladores, GCC. Herramientas de "building" (hace poco me enteré que le dicen así, estúpidos globbers de globolandia), GNU MAKE es lo mejor, es simple, es barato, es rápido ¿para que complicarse con automake o cmake?
Valgrind, Callgrind, CacheGrind, KCacheGrind
Una vez que todo funciona más o menos -y digo más o menos porque es el estado actual de "la cosa"- se empiezan a aparecer otros problemas, especialmente el de la PERFORMANCE, cuestión que no tengo idea de como abordarla, simplemente porque soy un principiante. Una de las primeras aproximaciones, por supuesto, es leer el código de Freedo para entenderlo, pero el tema está en saber después que partes son las mas críticas en términos de consumo de CPU. Para esto me puse a leer sobre este tipo de herramientas sobre GNU/Linux y encontré
Valgrind.
Valgrind es un framework para análisis y depuración de rendimiento, contiene un set de herramientas que la verdad no conozco en profundidad, pero una de ellas se llama "Cachegrind". Cachegrind nos permite analizar la ejecución de un programa y este se encarga de armar datos estadísticos de la ejecución, mostrándonos que funciones son las que mas se utilizan. En conjunto con
KCachegrind, que es una herramienta gráfica, nos arma una hermosa tabla donde podemos ver cuales son las funciones que se están "comiendo" la CPU. Todavía no se muy bien que hacer ahora, pero al menos se por donde tengo que empezar a revisar el código si quiero mejorar la performance.
Trabajando con otras gentes
Una de las cuestiones de estos proyectos es la de trabajar con "forasteros", gente desconocida de otros pagos (franceses, españoles, ingleses, marcianos) que se interesan por el proyecto y se dedican a romperte las bolas -en el buen sentido- para que termines alguna cosa que dejaste incompleta. Lo bueno de esto es que te animan a completar cosas que normalmente uno deja inconclusa (total al único que le importa es a mi que soy el autor). Gracias a eso el emu esta funcionando en
Open Pandora y seguramente eso va a llevar a un port a otra plataforma y otra y otra y otra...así es la vida del software multiplataforma.
Redondeando
Pueden encontrar más información del emulador y el source en su
sitio web. Púdranse.
Continuará...
