Entornos libres para el desarrollo de videojuegos: un caso prático
Full text
Títol: Entornos libres para el desarrollo de videojuegos: un caso prático. Volum: 1 Alumne: Raúl González Moya Director/Ponent: Antoni Soto i Riera Departament: LSI Data:
DADES DEL PROJECTE Títol del Projecte: Entornos libres para el desarrollo de videojuegos: un caso prático. Nom de l'estudiant: Raúl González Moya Titulació: Ingeniería Técnica Informática de Gestión. Crèdits: 22,50 Director/Ponent: Antoni Soto i Riera Departaent: LSI MEMBRES DEL TRIBUNAL (nom i signatura) President: Josep Vilaplana Pastó Vocal: Manuel Alejandro Pajuelo González Secretari: QUALIFICACIÓ Qualificació numèrica: Qualificació descriptiva: Data:
Índice general 1. Introducción 1 1.1. Motivación ...................................... 1 1.2. Objetivos ....................................... 1 1.3. Estructura del documento .............................. 2 2. Análisis 5 2.1. Hardware de la PS2 y carga de software ...................... 5 2.2. Carga de software Ocial ............................... 7 2.2.1. Modchips ................................... 8 2.2.2. Discos de arranque .............................. 10 2.2.3. Carga a través de disco duro mediante discos de arranque ........ 11 2.3. Carga de software NO ocial ............................ 11 2.3.1. Disco duro .................................. 11 2.3.2. El emulador PCSX2-0.8.1 .......................... 12 2.3.3. Loaders .................................... 13 2.4. Entornos de desarrollo para PS2 .......................... 14 2.4.1. Kit ocial de desarrollo de Sony ....................... 14 2.4.2. Kit de GNU/Linux para PS2 ........................ 14 2.4.3. Programación RAW ............................. 16 2.5. Compilación cruzada ................................. 16 2.5.1. Canadian Cross ................................ 17 2.6. Autotools ....................................... 18 2.7. Simple DirectMedia Layer (SDL) .......................... 19 3. Entorno de desarrollo para la PS2 21 3.1. Sistema operativo ................................... 21 i
ii ÍNDICE GENERAL 3.2. Software para desarrollar ............................... 21 3.3. Entorno de programación RAW (PS2DEV) .................... 22 3.4. Librerías SDL ..................................... 23 3.5. El método de carga de software NO ocial ..................... 24 4. Portando un juego a la PS2 27 4.1. Tests básicos del entorno PS2DEV ......................... 27 4.2. Test del port de SDL con un proyecto PS2 en SDL ................ 29 4.3. Test de portabilidad básicos ............................. 31 4.4. Cuadrado ...................................... 31 4.5. Círculo ........................................ 32 4.6. Teclas ......................................... 32 4.7. Colisiones ...................................... 33 4.8. Tests de entrada/salida ................................ 33 4.9. hello.c ......................................... 33 4.10. helloFile.c ...................................... 34 4.11. helloFile.c ...................................... 35 4.12. helloFileToFile.c .................................. 35 4.13. Test de portabilidad de un proyecto SDL que utiliza autotools .......... 36 4.13.1. Autotools y compilación cruzada ...................... 38 5. Valoración económica 49 5.1. Costes de hardware y software ............................ 49 5.2. Costes de dedicación ................................. 50 5.3. Detalles de las tareas realizadas ........................... 51 6. Conclusiones 53
Índice de guras 2.1. Kit ocial de GNU/Linux para PS2 ......................... 15 2.2. Diagrama de entorno de compilación cruzada. ................... 17 2.3. Diagrama de entorno canadian cross. ........................ 18 4.1. Pongix versión SDL de Pong para Linux ...................... 37 iii
6 CAPÍTULO 2. ANÁLISIS Sintetizador Gráco (GS) Es el encargado de recoger los display list que le envía el EE y los representa en la pantalla. El GS es lo que sería la tarjeta gráca de la PS2, como comentamos antes, en las últimas versiones de PSTwo estan unidos ambos chips. Procesador de sonido (SP) Es la tarjeta de sonido de la PS2. Es capaz de reproducir sonido digital 3D, por su salida óptica digital. Procesador de Entrada/Salida (IOP) Es el encargado de manejar los puertos USB, el puerto FireWire, y todo el tráco de los mandos de control(DualShock [DSK2004]) del juego y de las tarjetas de memoria. En las últimas versiones de PS2 y en todas las versiones de PSTwo el puerto del FireWire fue suprimido, e incorporaron de serie el puerto infrarrojo para el mando a distancia. La función que realiza el IOP es la de enviar la entrada de los mandos de control o la de los puertos USB al Emotion Engine para que este pueda actualizar el estado del juego apropiadamente. Estos son los componentes principales de la arquitectura de la PS2, para ampliar más la información en cuanto a la arquitectura de cada uno de los chips de la PS2. Ver [DOC.01] A parte de estos componentes la PS2 tiene más hardware, que a continuación detallaremos. Lector de CD/DVD Es el principal dispositivo que utiliza la PS2 para cargar los programas que queramos ejecutar en ella. Entre estos programas podemos encontrar desde videojuegos ociales, discos de música y además para reproducir películas de DVD. Hoy en día el lector ha perdido importancia con la aparición de aplicaciones capaces de cargar los videojuegos desde un disco duro instalado en la PS2 o con la aparición de cargadores de programas desde PC(loaders) los cuales explicamos en la sección de Carga de software NO ocial. Los dos puertos para los DualShock Estos controles son el medio de comunicación del usuario con la PS2, con ellos aparte de jugar, podemos también darle ordenes a la PS2 para poder entre otras cosas reproducir películas de DVD o cambiar algunos aspectos de la conguración. Las puertos para las tarjetas de memoria (Memory Card) Estos puertos son utilizados para la conexión de las tarjetas de memoria. Éstas son utilizadas para almacenar los datos de las partidas guardadas, las tarjetas ociales tienen una capacidad de almacenamiento de 8MB, pero también existen otros
2.2. CARGA DE SOFTWARE OFICIAL 7 fabricantes no ociales que han llegado a fabricar tarjetas de memoria de hasta 64MB. Puertos USB Estos puertos actualmente están obteniendo mayor importancia porque ahora cada vez más videojuegos utilizan este tipo de conexión. Aparte de ser utilizado para poder conectar accesorios exclusivos para algunos juegos los puertos USB también sirven para conectar disco duros externos, memorias USB, teclados, ratones o micrófonos. El puerto de expansión Dev9 El puerto Dev9 permite conectar el dispositivo de Ethernet y con él un disco duro ATA, sin embargo la PSTwo para reducir su tamaño se quito este puerto, pero a cambio se le incorporó de serie el puerto de Ethernet. El uso del puerto de expansión Dev9 ha abierto un camino para poder interactuar entre el PC y la PS2. Otros accesorios Como comentamos en los puertos USB Sony ha desarrollado videojuegos que utilizan una serie de dispositivos que se comunican mediante estos tipos de puertos: EyeToy [EYE2004] es una cámara USB capaz de capturar el movimiento del usuario y enviárselo a la PS2 para interactuar con videojuegos especícos ya diseñados para este dispositivo. Los micrófonos USB utilizados para el SingStar [SIN2004] videojuego que simula un karaoke, pero con la especial característica que es capaz del reconocimiento de las entonaciones de la voz. La guitarra este dispositivo es utilizados para videojuegos en los que simulas tocar una guitarra, entre estos juegos se encuentra el Guitar Hero [GUI2005] y todos los que derivan de esta compañía. 2.2. Carga de software Ocial Una vez explicado el hardware lo siguiente es explicar el software de PS2, el soporte básico de los videojuegos de PS2 son el DVD. PS2 no tiene sistema operativo ni nada parecido a éste, lo único que tiene es un simple menú en el que poder congurar algunos aspectos de la videoconsola y un pequeño reproductor de audio y vídeo. Debido a este motivo y a que la PS2 ha sido diseñada para cargar software desde la unidad lectora, la carga de software que no sea original de Sony cuesta más trabajo, sobretodo porque para que la PS2 sea capaz de cargar software implementado por el usuario, es necesario grabarlo en CD-ROM y de una forma en concreto que explicaremos en el capítulo de Entorno de desarrollo para la PS2.
8 CAPÍTULO 2. ANÁLISIS Sony para la carga de los videojuegos de PS2 diseño un sistema de seguridad que básicamente consiste en grabar al inicio del CD o DVD unos sectores defectuosos, para que después cuando un usuario intente hacerse una copia de seguridad con su grabadora no le funcione correctamente, ya que las grabadoras caseras en cuanto detectan estos sectores defectuosos se limitan repararlos en el momento de crear la copia, y luego la PS2 cuando carga la copia busca estos sectores defectuosos y como no los encuentra detecta que no es un juego original. Como consecuencia de este método de seguridad han surgido uno métodos para poder cargar backups de software ocial de Sony sin la necesidad de que este sea original, estos métodos de carga los podemos agrupar en los modchips y los discos de carga. Modchip Es un pequeño dispositivo electrónico utilizado para modicar una videoconsola para añadirle mejoras que no vienen de serie o para eliminar posibles limitaciones a la hora de cargar backups de software ocial y NO ocial. Discos de arranque Son unos discos desarrollados para manipular los videojuegos añadiendo a éstos mejoras entre ellas la posibilidad de vidas innitas, súper velocidad del personaje, salto de niveles, entre otras muchas posibilidades del mismo estilo. Además de esta función también ofrece poder realizar el intercambio de discos (SWAP), para la carga de backups. Cualquiera de estos dos métodos de carga podemos utilizarlo para el desarrollo del PFC. Las ventajas que vemos del uso del modchip respecto al disco de carga es que el modchip ofrece mayor comodidad ya que no requiere tener que estar haciendo el cambio de discos y además esto aporta mayor seguridad ya que no debemos forzar la bandeja mecánicamente para realizar el cambio. Por otro lado es importante mencionar que los discos de arranque son un método de carga más económico ya que su precio se aproxima a unos 33 ¿ mientras que la instalación de un modchip acostumbra a costar 100 ¿ . También usar discos de arranque son recomendables siempre que no queramos perder la garantía de fábrica, ya que no requieren abrir la PS2 para instalar nada tal y como necesitan los modchips. 2.2.1. Modchips Modchips hay muchos y para saber cual instalar básicamente nos tenemos que jar en la calidad y el precio, como en cualquier otro producto que compremos. Aparte de esto dependiendo del modchip que escojamos podremos realizar más o menos cosas con nuestra PS2. Los tres modchips que hemos escogido para comentar son el Modbo 760, el Matrix Innity y el DMS 4 Pro.
2.2. CARGA DE SOFTWARE OFICIAL 9 DMS 4 Pro Es el más completo de los tres y el más complicado de instalar por su gran número de soldaduras complejas que hay que realizar, por eso también es el más caro de instalar. Este chip se vende sin programar y una vez instalado nosotros mismos le podemos cargar el software necesario a través de un CD. DMS4 Pro es la versión profesional de DMS4 Lite. Tiene todas las características de DMS4 Lite añadiendo una memoria ash interna de 2MB para almacenar y ejecutar aplicaciones o sea archivos .ELF sobre todo. Detecta el tipo de medio insertado (PS1, PS2, CD-R, DVD-R, DVD+R, DVD-RW, DVD9 o DVD+RW ) y lo carga automáticamente sin necesidad de métodos de carga o interacción adicional por parte del usuario. El DMS4 tiene varios tipos posibles de instalación, instalación simplicada (número de cables reducido) 17 cables en V1-V7 PAL/USA o 18 cables en V1-V7 JAP/ASIA . 18 cables en V9-V10 PAL/USA (19 con soporte DVD+/-RW, punto T ) o 19 cables en V8,9 y 10 JAP/ASIA (20 con soporte DVD+/-RW, punto T ). En su página ocial podemos encontrar si queremos el diagrama instalación. [URL.01] Tiene una alta seguridad ya que el código de DMS4 esta protegido mediante una tecnología de origen militar para protegerlo contra cloners y fakers. Es el más compatible con todos los modelos de PS2 de todas las regiones: V1-V10 PAL/USA/JAP. Su software, fabricado por el equipo de ToxicOs (ver [URL.02]), se puede actualizar fácilmente desde CD y este software lo que aporta es un menú mucho más completo que el de la PS2 y que nos facilita la posibilidad de utilizar y congurar todas las prestaciones que nos aporta la instalación del DMS4Pro. Nos permite visualizar películas DVD de cualquier región, fuerza el modo de color y suprime el efecto verde en la reproducción de películas DVD con cable RGB. Es compatible con el modo Dev1, carga aplicaciones y software desde la Memory card de PS2 usando el modo especial DEV.olution, también es compatible con el modo Dev2, el cual permite la carga de aplicaciones y software desde el disco duro de PS2. DEV.olution mode 2 es el sucesor de DEV.olution 1 mode. Tiene distintas posibilidades de conguración del modo de arranque además de otros parámetros, como la opción de poderlo desactivar fácilmente presionando el botón cuadrado en el mando durante el arranque de la PS2. Matrix Innity Es el más equilibrado en cuanto a calidad precio y es el principal rival del DMS4. Tiene las mismas características que el DMS4 excepto que el modchip Matrix tiene tan solo 512KB de memoria interna. El software que incorpora este modchip tiene actualizaciones más a menudo respecto del software que tiene el DMS4, pero por otro lado es importante destacar que el
10 CAPÍTULO 2. ANÁLISIS equipo de ToxicOs tarda más en publicar las actualizaciones para el DMS4, para así poder ofrecer muchas más mejoras en su sistema que sus competidores. Tiene menos soldadura que los otros dos y además tiene mejor soporte por correo electrónico que el DMS 4. Modbo 760/versiones anteriores Este modchip es el más económico de los tres que explicamos, es un clon del Matrix pero con mucha menos calidad que éste. Tiene soporte igual que el DMS4 y el Matrix en lo que se reere a la carga de aplicaciones y software desde la Memory card o el disco duro de la PS2 (modo Dev1 y Dev2). Estos modos de carga los encontramos en casi todas las versiones disponibles del chip, aunque la versión 760 es la más completa y la más recomendada. El chip se desactiva al abrir la bandeja después de haber cargado un backup previamente, lo cual hace que este chip sea más incomodo que sus competidores. En algunas versiones de este chip, permitían que la consola se calentará más de la cuenta, lo cual hacia que se acortara la vida de la videoconsola. La PS2 con la que realizamos el proyecto tiene instalado un DMS4. La versión del DMS4 es una versión anterior a la versión Pro que acabamos de explicar, con la última versión del software de ToxicOs compatible con este modelo de modchip. 2.2.2. Discos de arranque Si no queremos tener que manipular la PS2 y mucho menos instalar en ella un chip que manipule las funcionalidades de la videoconsola, entonces debemos optar este tipo de método de carga. El funcionamiento de este método de carga se basa en el uso de un disco de arranque el cual nos permite realizar un intercambio entre un disco original de PS2 y un backup de PS2 ocial. Para poder cargar con este método un backup inicialmente hay que arrancar la PS2 con el disco de arranque. Con este disco de carga lo que conseguimos es que siguiendo un proceso, que varía dependiendo del fabricante del disco, la PS2 deje de leer datos del lector en mitad de una carga de un disco de PS2 original. Se utiliza primero el disco original para que la PS2 lea los sectores defectuosos que explicamos en la sección del análisis del lector de CD/DVD. Una vez ha leído estos sectores defectuosos el software con el que arrancamos para el lector, y es en ese preciso momento cuando, mediante alguno de los métodos existentes Cogswap (intercambio en este caso de discos) en la consola, se debe cambiar el disco original de PS2 por el backup que deseamos cargar. De los distintos tipos de discos de arranque que hay en el mercado el que probamos es el Swap Magic 3 ver [URL.03]. Además de los discos de arranque también necesitamos como comentamos en el párrafo anterior un método para Cogswap y para ello encontramos dos sistemas. El primero método se basa en quitarle el frontal protector de la bandeja del lector del DVD de la PS2, con la nalidad de así tener espacio suciente para poder introducir una Slide card, tarjeta
2.3. CARGA DE SOFTWARE NO OFICIAL 11 con una ranura ya adaptada para poder abrir de forma mecánica la bandeja, ver [URL.04]. Por experiencia propia utilizando este método tienes que realizar el cambio con mucho cuidado, ya que puedes meter la tarjeta antes de tiempo y sin querer enganchar algún componente de esta que este en movimiento. El segundo método se basa en sustituir la carcasa original de la PS2, por otra la cual en lugar de expulsar la bandeja, se abre una tapa hacia arriba, para así poder realizar el intercambio de discos. El cambiar la carcasa original de Sony por esta especial implica perder la garantía de fábrica. Para el desarrollo de este PFC, personalmente escogemos la instalación de un modchip porque tenemos que ir ejecutando muchas pruebas y cada vez que realicemos una de ellas deberemos de hacer todo el proceso de Cogswap. 2.2.3. Carga a través de disco duro mediante discos de arranque Como explicamos en la sección de dispositivos de la PS2, podemos conectar a ésta un disco duro ATA y utilizarlo gracias a software como por ejemplo el HD Advance (ver [URL.05]) para cargar backups de PS2. El HD Advance son unos discos de arranque que permiten copiar y cargar imágenes al disco duro. También podemos utilizar un backup del propio HD Advance, pero para poder utilizar este backup entonces necesitamos uno de los dos métodos de carga de los anteriores explicados. 2.3. Carga de software NO ocial Entendemos por software NO ocial o Homebrew, cualquier clase de aplicación de un usuario realizada para una videoconsola, como para este caso la PS2. Este tipo de software, también puede ser ejecutado utilizando alguno de los dos métodos de carga que explicamos en la sección anterior, pero además existen tres métodos más que nos permite cargar software NO ocial. Es importante decir que exceptuando el método del uso de un emulador de PS2, el resto de sistemas para cargar software NO ocial requiere del uso de uno de los métodos de carga de backups anteriores. 2.3.1. Disco duro La idea básica de este sistema de cargar es semejante al método que explicamos para cargar backups en el disco duro utilizando el HD Advance. La diferencia ahora es que necesitamos utilizar el HDD Dump Tool, este software permite copiar archivos desde el lector de CD/DVD al disco duro de la PS2 para así luego poder ejecutarlo desde este último. Ver [URL.06]
12 CAPÍTULO 2. ANÁLISIS 2.3.2. El emulador PCSX2-0.8.1 Otro método estudiado es el uso de un emulador el PCSX2, usar emulador tiene la gran ventaja de que no es necesario tener la PS2 para poder realizar las pruebas de las aplicaciones que compilemos. Para la instalación del emulador es requisito indispensable descargarnos el PCSX2, la última versión disponible es la 0.9, pero la versión que probamos es la pcsx2-0.8.1, esta versión la descargamos de la página ocial del emulador [URL.07]. Otra cosa indispensable para poder llevar a cabo la instalación son los plugins necesarios para la conguración del emulador, estos también se pueden descargar la mayoría de la página web ocial. En la página ocial se encuentra una guía del funcionamiento del emulador y de como congurar cada uno de sus plugins, la cual seguimos para congurar el emulador. Ver [URL.08] A continuación comentamos que plugins hemos utilizado para congurar el emulador PCSX20.8.1, para el desarrollo del PFC. Plugin gráco El que probamos y utilizamos actualmente para los grácos es el GSdx9(SSE2)0.8, este plugin soporta el directX 9 y realmente se nota en la velocidad de proceso de los grácos. Plugin sonido En cuanto al plugin de sonido probamos ambas posibilidades tanto el plugin nulo SPU2null v0.3 como el plugin PEOPS SPU2 el cual pese a estar en una versión beta no nos ha causado problemas. En la guía comentan que con el uso del sonido puedes perder 1 o 2 FPS, pero ya que nuestras demos no requieren de grandes cálculos grácos, no apreciamos ese descenso de velocidad. Plugin Pad Tan solo probamos el PADwinKeyb Driver 0.9 , este plugin es necesario para con- gurar que teclas del teclado emularan los botones del Dualshock de la PS2, este plugin no tiene ninguna dicultad en lo referente a su conguración. Plugin CDVD De este plugin probamos el CDVDbin Driver 0.65 con una imagen de un videojuego que teníamos en el PC y funcionó sin problemas. Pero el plugin que es necesario para el proyecto es el CDVDnull Driver 0.6 ya que este es el que nos permite ejecutar los archivos .ELF que generemos en las pruebas. El resto de plugins no nos han sido necesarios para el proyecto. Por último nos queda la conguración de la parte más importante del emulador, la BIOS, la cual la extraemos de nuestra PS2 con la ayuda de un Volcador de BIOS. Ver [URL.09]
2.3. CARGA DE SOFTWARE NO OFICIAL 13 Es importante decir el PCSX2 también tiene una versión disponible que corre bajo GNU/Linux, el creador te facilita las fuentes sin ningún problema en la página web ocial, estas fuentes son software libre bajo la licencia GPL. El único inconveniente de utilizar un emulador como método de carga, es no poder asegurar que funciona totalmente bien ante las aplicaciones que compilemos. 2.3.3. Loaders Los loaders son aplicaciones diseñadas para cargar software entre dos plataformas, en este caso práctico para cargar software entre el PC y la PS2. El funcionamiento de este método de carga se basa en la ejecución de dos aplicaciones, una cliente y otra servidor. En este caso la aplicación cliente corre sobre GNU/Linux y la aplicación servidor la arrancamos sobre la PS2. En la sección del método de carga que utilizamos para los experimentos del capítulo siguiente, explicamos con más detalle la conguración de este método. En la comunidad de PS2DEV [URL.10] encontramos todos los loaders disponibles para cargar software a la PS2. Todos estos loaders los podemos agrupar según el tipo de conexión que utilizan en dos grupos. Loaders Ethernet Este tipo de loader requieren que la PS2 tenga conexión Ethernet. Dentro de este grupo encontramos por la parte del cliente el pksh y el PS2client . Ambos loaders tiene un funcionamiento similar, que se basa en abrir una consola de comandos para poder ejecutar instrucciones sobre la PS2. Por el lado de la PS2 tenemos el PS2link, esta aplicación se ejecuta en el momento de arrancar la PS2 y esta a la espera de recibir instrucciones desde el cliente instalado. Loaders USB En esta agrupación se encuentran todos los loaders que utilizan una conexión USB para la carga de software. Para poder realizar la conexión con estos loaders necesitamos disponer de un cable USB que tenga el chip PL2301, este tipo de cables lo podemos comprar en cualquier tienda de electrónica especializada. El cliente que hay disponible para este tipo de loaders es el npsh . Este loader tiene de igual manera que los clientes Ethernet una consola por la que enviamos instrucciones a la aplicación servidor. Como aplicación servidor encontramos el Naplink el cual debemos usar a la hora de arrancar para así poder realizar la conexión con el PC. De este método de carga opinamos que para llevar a cabo los experimentos que debemos de hacer es el más práctico.
14 CAPÍTULO 2. ANÁLISIS 2.4. Entornos de desarrollo para PS2 Podríamos decir qué entendemos por entorno de desarrollo: Un conjunto de herramientas y aplicaciones utilizadas para poder programar con ellas, pueden dedicarse en exclusiva a un sólo lenguaje de programación o bien, usarse para varios. Durante la fase de búsqueda de los diversos entornos que existen para desarrollar software para PS2, encontramos principalmente tres, de estos explicamos con más detalles los que se adapten a los requisitos no funcionales del PFC. 2.4.1. Kit ocial de desarrollo de Sony Las compañías de desarrollo de videojuegos, que quieren desarrollar para la PS2 de manera ocial, Sony les ofrece un kit de desarrollo el cual consta de dos equipos. El equipo para realizar el desarrollo es más grande que una PS2 normal, tiene más RAM, un disco duro y ethernet integrados. El equipo de pruebas es igual que la PS2 normal, pero con la diferencia de que puede leer backups, sin la necesidad de ningún sistema de arranque. Este equipo esta pensado para que puedan trabajar un grupo de dos personas a la vez, desarrollando y probando lo que implementan. Este método de desarrollo no esta pensado con la idea de que una pequeña empresa pueda diseñar videojuegos para PS2, ya que necesitaría de una cantidad razonable para la inversión de dichos entornos. Estos entornos cuestan aproximadamente unos 20.000$ cada kit. Debido a esto y a razones legales ningún usuario sencillo puede diseñar con dicho entorno, para desarrollar sus aplicaciones para PS2. 2.4.2. Kit de GNU/Linux para PS2 Otro entorno de desarrollo distribuido por Sony que desde hace unos años se encuentra en el mercado es el kit de desarrollo GNU/Linux basado en Debian GNU/Linux [DEB1997], para que los usuarios de PS2 pudieran desarrollar sus propias aplicaciones para sus consolas. El kit está compuesto de dos discos (Figura 2.1). El primero contiene la documentación de Sony y todo lo necesario para la ejecución del GNU/Linux, mientras que en el segundo viene toda una serie de aplicaciones para poder instalar en él. Este kit también tiene componentes y periféricos para PS2, entre ellos encontramos un teclado y un ratón USB, un adaptador de red, un disco duro de 40 GB y un adaptador VGA para poder conectar la consola al monitor. Sony con la comercialización de este kit intenta ofrecer al usuario la posibilidad de desarrollar sus propias aplicaciones para PS2, el problema de este entorno de desarrollo es que tiene un par limitaciones bastante importantes a la hora de decidirse desarrollar en él.
2.4. ENTORNOS DE DESARROLLO PARA PS2 15 Figura 2.1: Kit ocial de GNU/Linux para PS2 La primera limitación es que Sony ofrece al usuario tan solo los archivos binarios de los driver de entrada y salida, y la segunda es que todo lo que se desarrolle con este entorno, solo servirá en otras PS2 que tengan también el kit de GNU/Linux instalado. Aun así en el momento de investigar los diversos entornos de desarrollo para PS2, una opción interesante resulta tener la posibilidad de instalar una distribución GNU/Linux en la PS2 para directamente desarrollar desde ella. Además del kit ocial de Linux que distribuye Sony, existe una distribución de Linux llamada BlackRhino basada en Debian. A continuación analizamos la instalación de la distribución BlackRhino la cual realizamos a partir de un manual que encontramos en internet [URL.11]. Es necesario para poder instalar BlackRhino que tengamos algún método que nos ofrezca la posibilidad de arrancar la PS2 en modo Dev1, ver sección Modchips de este mismo capítulo. En el manual utilizan el primer disco del kit de Linux para arrancar en Dev1. Para poder copiar la imagen de BlackRhino que ocupa 21MB, es necesario trocear la imagen ya que las tarjetas de memoria son de 8Mb. Los trozos no pueden superar los 3Mb porque aparte de el trozo de la imagen también es necesario añadir a la tarjeta un kernel para que arranque un Linux y así poder montar la tarjeta para copiar el trozo de BlackRhino al disco. El proceso no es complicado pero si es lento, como disponemos de dos tarjetas de memoria, el proceso se agiliza ya que podemos copiar tres trozos (uno de la primera tarjeta y dos trozos de la segunda). Cosas importantes que hay que tener en cuenta ante todo, lo más importante es que a la hora de trocear la imagen la aplicación que usemos no añada nada de código a los trozos. Otra cosa importante a tener en cuenta es que antes de empezar copiemos al PC todas las partidas guardadas que tengamos en la memory card, ya que si no corremos el riesgo de perderlas. Una vez copiados todos los trozos en el disco duro de la PS2 queda volver a unirlos y descomprimir, el BlackRhino. En el manual podremos ver más detallado cada uno de los pasos que explicamos. El único error que encontramos en este manual está en el link que hace referencia a la página donde podemos descargar la imagen del BlackRhino, el cual es erróneo. La dirección correcta donde encontrar todo lo referente la podemos ver aquí [URL.12].
22 CAPÍTULO 3. ENTORNO DE DESARROLLO PARA LA PS2 Para instalar estas librerías, siendo usuario root , escribimos los siguientes comandos: apt-get install binutils apt-get install libc-dev apt-get install build-essential Después de instalar el compilador y estas tres librerías ya tenemos preparado el sistema operativo y las herramientas necesarias para instalar el entorno de programación RAW (PS2DEV). 3.3. Entorno de programación RAW (PS2DEV) El entorno de programación RAW más completo que encontramos es el PS2DEV. Además este entorno ofrece una instalación muy práctica mediante el uso de las herramientas toolchain de GNU (colección de herramientas desarrolladas por GNU para facilitar el desarrollo de aplicaciones) [URL.21]. El primer paso que debemos realizar es obtener las fuentes del PS2DEV. Para obtener una copia de las fuentes del PS2DEV, podemos descargarlas de su repositorio ocial, ver [URL.13]. Con el siguiente comando descargamos una copia del PS2DEV: svn co svn:/svn.ps2dev.org/ps2/trunk/ Otra cosa necesaria para la instalación del PS2DEV es declarar las variables de sesión PS2DEV, PS2SDK y modicar la variable PATH . Como estas variables también las utilizaremos para los experimentos, para no tener que declararlas cada vez que iniciemos una sesión, las añadiremos a los archivos .bashrc del usuario con permisos root que utilizamos. Para declarar las variables tan solo es necesario añadir las siguientes líneas al nal del chero: export PS2DEV=/usr/local/ps2dev export PATH=$PATH:$PS2DEV/bin export PATH=$PATH:$PS2DEV/ee/bin export PATH=$PATH:$PS2DEV/iop/bin export PATH=$PATH:$PS2DEV/dvp/bin export PS2SDK=$PS2DEV/ps2sdk export PATH=$PATH:$PS2SDK/bin Si el usuario que vamos a utilizar no tiene permisos de root deberemos cambiar el path de la variable PS2DEV por una dirección en la que tengamos permisos totales.
3.4. LIBRERÍAS SDL 23 Ahora el siguiente paso que debemos hacer es ejecutar las toolchain, para ello primero debemos darle permiso de ejecución al chero toolchain.sh , mediante el comando chmod. cd trunk/ps2toolchain/ chmod 777 toolchain.sh Y una vez tiene permisos de ejecución tan solo queda ejecutar el script para la instalación. ./toolchain El proceso de instalación del PS2DEV tarda aproximadamente veinte minutos dependiendo del PC. 3.4. Librerías SDL Para la portabilidad que vamos a realizar es necesario también la instalación del port las librerías SDL. Para la instalación del port de SDL de PS2 debemos primero instalar las librerías libti y gsKit , estas librerías básicas sirven para el tratamiento de imágenes. Disponemos de las fuentes de estas librerías dentro del propio PS2DEV. Instalación de la libti Para que no genere un mensaje de error de compilación al intentar instalar esta librería es necesario editar el archivo Makele y añadir la siguiente línea, que encontramos que faltaba. LIBTIFF = . También por comodidad y para que sea un proceso más automatizado la instalación de estas librerías, podemos añadir al chero Makele también las siguientes líneas. install: cp \*.a $(PS2DEV)/ee/lib cp \*.h $(PS2DEV)/ee/include Con estas líneas en el momento de hacer make install ya make copiará cada cosa en el lugar que le toca. Una vez modicado el Makele tan solo hay que ejecutar. make make install
24 CAPÍTULO 3. ENTORNO DE DESARROLLO PARA LA PS2 Instalación de la gsKit Para instalar esta librería, antes de nada tenemos que modicar el chero Make- le.pref y comentar la línea que declara la variable PS2DEV, ya que el comando make sustituiría nuestra variable de sesión PS2DEV que tenemos declarada correctamente por esta que no tiene porque estar apuntando al path correspondiente del entorno. Después igual que la libti solo hay que ejecutar. make make install Después de haber instalado estas dos librerías ya podemos instalar la API de SDL, la cual se encuentra dentro del directorio ps2sdk-ports . cd trunk/ps2sdk-ports/sdl/ make make install Llegados a este punto tenemos congurado el entorno de desarrollo de PS2 para poder programar aplicaciones en SDL. Es importante saber que dentro del directorio ps2sdk-ports también están disponibles todas las librerías de SDL que comentamos en el capítulo anterior en la sección dedicada a las Simple DirectMedia Layer (SDL). 3.5. El método de carga de software NO ocial Por último para ejecutar todos los test que realizamos es necesario un método de carga de software NO ocial, ver sección Carga de software NO ocial para más información. Escogemos como método de carga un loader ethernet ya que encontramos que es el más práctico a la hora de trabajar, una vez lo tenemos congurado. El software cliente que escogemos para Linux es el Pukklink Shell (pksh) [URL.17]. El pksh es una aplicación que se conecta de manera remota a una aplicación servidor que este arrancada en la PS2. Para la instalación del pksh primero debemos instalar la librería libreadline . Y una vez cubrimos esa dependencia ya podemos instalarlo. apt-get install libreadline cd trunk/pksh make pksh
3.5. EL MÉTODO DE CARGA DE SOFTWARE NO OFICIAL 25 Ahora ya tenemos instalado el loader cliente en Linux, pero también necesitamos un loader servidor que correrá del lado de la PS2. Escogemos el ps2link v1.46 [URL.18] como aplicación servidor para la conexión por parte de la PS2. Como tenemos un método para poder cargar backups de CD/DVD no rmados por Sony, decidimos grabar el ps2link en un CD para arrancarlo desde ese dispositivo. Para realizar la creación del backup seguimos el manual creado por el miembro Suloku y titulado con Mini tutorial: Crear un boot cd [URL.20], que encontramos en el foro de la página web ElOtroLado.net [URL.19]. En este manual ya explican como crear la imagen ISO para después grabarla al CD. Pero explicaremos que cheros son necesarios para grabar el ps2link y la estructura básica que debe de tener la ISO. system.cnf Es el chero autorun del cd, esto quiere decir que editando este chero podemos elegir entre otras cosas qué aplicación de las que tiene el cd, será la que queremos que arranque en el momento que la PS2 cargue el disco. El chero system.cnf internamente tiene que cumplir el siguiente formato. BOOT2= cdrom0:PS2LINK.ELF; 1 VER= 1.0 VMODE= PAL Con la línea BOOT2 indicamos que la aplicación que queremos que autoarranque se llama ps2link.elf y que se encuentra dentro del CD-ROM. Es muy importante que el nombre del ejecutable este completamente en mayúsculas en el chero system.cnf, aunque en el CD-ROM no este en mayúsculas. La línea que pone VER, es para indicar el número de la versión del CD-ROM grabado. Y la línea de VMODE es la que se encarga de indicar el formato de vídeo en el que queremos ejecutar la aplicación, el otro formato que podemos escoger es el NTSC declarar estos formatos tan solo son necesarios para decir la región. *.ELF Estos archivos son los ejecutables para la PS2. Entre ellos debe de encontrarse el ps2link.elf, que ejecutará la PS2 en el momento que arranque desde el cd. El nombre de los programas ejecutables no pueden superar el 8+3 número de caracteres, porque sino la PS2 no los reconocerá, ver [URL.19]. En un mismo CD puede haber más de un ejecutable, pero solo se ejecutará el que esté en el system.cnf, y los otros podemos ejecutarlos después por nuestra cuenta ya que los tenemos en el CD-ROM también. DUMMY Este chero resulta indiferente lo que contenga, pero lo que si que importa es que lo incorporemos en nuestra ISO del boot cd. El chero DUMMY puede ser cualquier
26 CAPÍTULO 3. ENTORNO DE DESARROLLO PARA LA PS2 chero que tengáis de más de 100Mb, renombrado por supuesto. Su uso es para rellenar el cd, para que este pese más de lo que pesaría con el ps2link u otras aplicaciones de tan pequeño tamaño. Si el CD-ROM no alcanza un peso igual o superior a 100Mb, la PS2 puede no ser capaz de ejecutarlo. En el caso de la grabación de ps2link además de estos cheros comunes también es necesario añadir el chero de conguración de red IPCONFIG.DAT ya que con este chero le indicamos los parámetros de conguración para congurar la tarjeta de ethernet. También será necesario añadir unas librerías especicas para PS2 las cuales requiere ps2link para su funcionamiento, entre ellas se encuentran: PS2IP.IRX, PS2LINK.IRX, IOMANX.IRX y PS2DEV9.IRX . La estructura que tiene el chero de conguración IPCONFIG.DAT es muy simple y necesita que le indiquemos la dirección ip, la mascara de red y la puerta de enlace, de la siguiente manera: 192.168.0.11 255.255.255.0 192.168.0.1 Una vez ya tenemos grabado el ps2link en un CD tan solo nos queda congurar la red de GNU/Linux por ejemplo con las siguientes direcciones: Dirección ip: 192.168.0.12 Mascara de subred: 255.255.255.0 Puerta de enlace: 192.168.0.1 Y ahora tan solo arrancando la PS2 con el CD grabado del ps2link y ejecutamos el pksh en el Linux, ya tendremos la PS2 y el PC conectados. El pksh dispone de una serie de comandos, pero principalmente el más utilizado es eeexec <le> , con este comando ejecutamos remotamente en la PS2 las pruebas .ELF que realicemos.
Capítulo 4 Portando un juego a la PS2 En este capítulo explicamos los distintos experimentos realizados durante el estudio realizado para portar una aplicación desde un PC, con Ubuntu 7.04, a una PS2. Para realizar la portabilidad utilizamos la metodología de la Compilación Cruzada, la cual ya explicamos en que consistía en la sección Compilación cruzada del capítulo de Análisis. A lo largo de este capítulo mostramos todos los experimentos realizados, explicamos el objetivo deseado de cada uno de ellos y analizamos a que conclusiones llegamos después de su ejecución. Todos los experimentos que realizamos los agrupamos por secciones. En cada sección, estos experimentos tienen en común que están probando la misma funcionalidad. Dentro de cada sección los presentamos en orden de menor a mayor dicultad. Para realizar todos estos experimentos, lo primero que tenemos que hacer es congurar todo el entorno de desarrollo como hemos explicado en el capítulo Entorno de desarrollo para la PS2. 4.1. Tests básicos del entorno PS2DEV Para comprobar el entorno de programación RAW (PS2DEV) que instalamos y los distintos dispositivos de PS2 con los que podemos interactuar, realizamos unos test básicos que se encuentran disponibles en las fuentes del PS2DEV. Entre estas aplicaciones encontramos testtimer, testcdrom, testendia, testerror, testjoystick, testver, checkkeys y un archivo Makele encargado de compilar todos estos test. Todos estos test no están preparados para ser compilados con las autotools. Una vez ejecutamos make comprobamos que todos estos test compilan. El siguiente paso es ejecutar cada uno de ellos contra la PS2 utilizando el pksh, para ver el resultado que obtenemos. Después de probar cada uno los test, observamos que funcionan todos correctamente exceptuando el test checkkeys . Este ejemplo captura las pulsaciones del teclado y el ratón que tenemos conectado a la PS2, pero al ejecutarlo en la PS2 no captura ninguna acción que realizemos. Para asegurar que el código fuente de checkkeys es correcto, compilamos checkkeys en el GNU/Linux y al ejecutarlo comprobamos que en Linux funciona correctamente. La conclusión que obtenemos de la ejecución de estos test es que la entrada por teclado y ratón 27
28 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 no las controla bien el entorno de desarrollo, igualmente decidimos seguir adelante porque el DualShock si que lo detecta correctamente para capturar datos de entrada a través de él. También decidimos que a partir de estos experimentos básicos, vamos a diseñar una estructura de directorios y de archivos Makele que agilicen los próximos experimentos que realicemos. El Makele genérico que diseñamos a partir del Makele de los test básicos tiene el siguiente formato: BINS = cuadrado.elf OBJS = EE_INCS = -I../include EE_LIBS = -L. -lc -L$(PS2DEV)/gsKit/lib -L../lib -lsdl -lcdvd all: $(BINS) install: %.elf : %.o $(PS2SDK)/ee/startup/crt0.o $(EE_CC) -mno-crt0 -T$(PS2SDK)/ee/startup/linkfile $(EE_LDFLAGS) \ -o $@ $(PS2SDK)/ee/startup/crt0.o $< $(EE_LIBS) clean: rm -f $(BINS) $(OBJS) include ../../Makefile.pref include ../../Makefile.eeglobal En este Makele tan solo tenemos que cambiar el nombre del binario que vamos a compilar (el archivo .elf de la variable BINS). Y también tenemos que indicarle las librerías e includes que necesite el propio ejemplo a compilar, mediante las variables EE_INCS y EE_LIBS. Tenemos que tener también en cuenta que los dos últimos includes del nal, siempre deben de tener la ruta adecuada según cada ejemplo, para que make los incluya sin problemas, ya que estos tienen todo el resto de librerías genéricas y los diversos ags que necesita make para compilar los ejemplos. Además del Makele que creamos también realizamos una copia de los archivos Makele.pref y Makele.eeglobal a la raíz del directorio de pruebas. También es necesario al chero Make- le.eeglobal indicarle donde están las librerías y los archivos de cabecera del entorno de desarrollo. Para ello lo modicamos cambiando las siguientes líneas: # Include directories EE_INCS := -I$(PS2SDK)/ee/include -I$(PS2SDK)/common/include -I. \ $(EE_INCS) por:
4.2. TEST DEL PORT DE SDL CON UN PROYECTO PS2 EN SDL 29 # Include directories EE_INCS := -I$(PS2SDK)/ee/include -I$(PS2SDK)/common/include -I. \ $(EE_INCS) -I$(PS2SDK)/ports/include/SDL Y también: # Linker flags EE_LDFLAGS := -L$(PS2SDK)/ee/lib $(EE_LDFLAGS) por: # Linker flags EE_LDFLAGS := -L$(PS2SDK)/ee/lib -L$(PS2SDK)/ports/lib $(EE_LDFLAGS) Después de estos pasos denenmos la siguiente estructura: tests_PS2 Makefile.pref Makefile.eeglobal (modificado con para el entorno) tests_basicos checkkeys.c testerrors.c ... (el resto de test básicos) Makefile (el genérico con solo los BINS a compilar) tests_portabilidad cuadrado.c Makefile (el genérico indicando el BIN a compilar) A partir de este momento todos los test que realizamos los adaptamos a este estructura de Makeles. 4.2. Test del port de SDL con un proyecto PS2 en SDL Este test también lo realizamos para probar aspectos de la conguración, pero éste prueba el port de SDL para PS2.
30 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 Buscando por la red conseguimos encontrar el Super Mario Wars(SMW) [SMW2006] un juego hecho en SDL del famoso fontanero de la Nintendo [NIN1889]. Si nos jamos en los requisitos de este videojuego vemos que son necesarias tener instaladas la SDL_image y la SDL_mixer, estas librerías las tenemos en el mismo directorio donde se encuentran las fuentes del port de las SDL. Así que para poder compilar el SMW primero instalaremos estas librerías. Instalación de las SDL_image Para poder instalar esta librería primero es necesario instalar las libjpeg y las libpng, las libpng a su vez requieren de las zlib. Una vez instadas todas estas librerías, ya podemos instalar las librerías SDL_image. cd ../libjpeg/ make make install cd ../zlib/ make make install cd ../libpng/ make make install cd ../sdlimage/ make make install Con esta serie de comandos ejecutados desde el directorio ./trunk/ps2sdk-ports/sdl ya tenemos instaladas la SDL_image y todas sus dependencias. Instalación de las SDL_mixer Esta librería no dependen de otras libs, así que solamente tenemos que ejecutar: cd ../sdlmixer/ make
4.3. TEST DE PORTABILIDAD BÁSICOS 31 make install Después de estos pasos ya tenemos en el entorno congurado con estas dos librerías que necesitamos para compilar el SMW. Ahora ya podemos proceder a la instalación del SMW pero antes hay que corregir unos errores léxicos. En el archivo music_player.h hay un problema de mayúsculas y minúsculas, error debido seguramente por programar en una plataforma que no es sensible a las mayúsculas y minúsculas. La solución se remite a substituir la siguientes líneas. #include <SDL_Mixer.h> por: #include <SDL_mixer.h> El otro error que encontramos esta en el archivo Makele , este incluye una librería que el compilador dice que no existe, debido a que está mal escrita. EE_LIBS += -L$(PS2SDK)/ports/lib -lsdlmain -lSDL_image -lsdlmixer \ -lsdl -ljpg -lmc -ldebug La solución es substituir -ljpg por -ljpeg . Una vez corregidos estos pequeños errores tan solo quedaba compilar ejecutando make . Éste genera un archivo llamado smw.elf el cual es el ejecutable resultante de la compilación. Finalmente podemos comprobar a través del pksh, que funciona el SMW en la PS2 sin problema alguno. Después de la ejecución de este test tenemos una ligera seguridad de que el entorno esta bien congurado, al menos para este ejemplo ha funcionado sin problemas. 4.3. Test de portabilidad básicos Una vez testeado el funcionamiento de las SDL en PS2 los siguientes test que ejecutamos se basan en una serie de ejemplos sencillos de portabilidad de SDL, que testean básicamente la librería SDL_image. 4.4. Cuadrado Este experimento dibuja un cuadrado pintado píxel por píxel por la pantalla. Con este experimento comprobamos el funcionamiento de la librería SDL_image. También servirá para comprobar que la estructura de Makeles que tenemos diseñada funcionaba correctamente.
38 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 config.h.in config.sub configure configure.ac Makefile.am Makefile.in Como podemos observar entre estos archivos se encuentran todas las macros y los scripts necesarios para poder generar el archivo Makele mediante el uso de las autotools. La idea es, si podemos realizar la portabilidad con la ayuda de las autotools, entonces nos centraremos más en realizar el estudio sobre hasta donde están portadas las librerías de SDL de la PS2 y hasta donde podemos llegar con éstas. Una vez comprobado que tenemos todos los archivos necesarios para poder generar el archivo Makele con las autotools tan solo debemos ejecutar el siguiente comando: >./configure Al ejecutar congure las autotools, a partir de las macros y los scripts, testea el sistema para comprobar que tenemos todo lo necesario para compilar Pongix y además congura el archivo Makele de manera que este conozca todos los path necesarios donde encontrar los cheros necesarios para poder realizar dicha compilación. Tras obtener el archivo Makele, compilamos Pongix y podemos comprobar que este funcionaba correctamente. 4.13.1. Autotools y compilación cruzada Comprobadas las fuentes, el siguiente paso es estudiar que soporte o facilidades ofrece las autotools para realizar compilación cruzada. Comentamos en la sección dedicada a las Autotools en el capítulo de Análisis, que en la documentación de las autotools (en el autobook [URL.14]), existe un capítulo que hace referencia a la compilación cruzada. El método que explican en este capítulo, que consiste en indicar a las autotools qué compilador es el escogido para compilar las herramientas propias de GNU/Linux y cual es el compilador que usamos para compilar todo lo que es propio de la plataforma a la que vamos a portar. Aparte de los compiladores también es necesario indicarle donde se encuentran las librerías y los archivos de cabeceras del entorno de desarrollo, para poder indicarle a las autotools donde encontrar estos archivos, las autotools facilitan el uso de los ags LDLIBS y LDFLAGS. Dicho esto la primera prueba que lanzamos para probar las autotools corresponde a la siguiente línea de comandos.
4.13. TEST DE PORTABILIDAD DE UN PROYECTO SDL QUE UTILIZA AUTOTOOLS 39 ./configure --build=$(./config.guess) --host=ee LDFLAGS="-mno-crt0 \ -L$PS2SDK/ports/lib" LIBS="-lSDL_image -lsdl" 2>&1 | less Con el parámetro --host le indicamos cual es el prejo que tiene todas las herramientas que necesita el compilador y con los ags LDFLAGS y LIBS le indicamos que librerías debe incorporar al archivo Makele que vamos a crear. Para poder ver mejor los resultados que nos devuelve la ejecución del comando congure decidimos redirigir con el comando less la salida estándar. Según lo que leímos en el autobook [URL.14] referente a las autotools si tenemos bien declarados estos parámetros y si el entorno esta congurado correctamente, las autotools genera un archivo Makele con el cual podemos compilar Pongix para la PS2. Pero tras ejecutar esta primera prueba obtenemos el siguiente mensaje: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking for ee-strip... ee-strip checking for ee-gcc... ee-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... yes checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether ee-gcc accepts -g... yes checking for ee-gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of ee-gcc... gcc3 checking for SDL_Init in -lSDL... no configure: error: * Can't find SDL library: http://www.libsdl.org Como podemos observar en la salida del less el compilador y las diversas herramientas de nuestro entorno las encuentra sin problema alguno, pero sin embargo tiene un conicto con la librería de SDL ya que el mensaje que devuelve dice que no la encuentra. Este tipo de error principalmente podía ser debido a que congure no encuentra la librería. El mensaje que devuelve el congure es un mensaje genérico que se declaraba en una de las macros del autotools y este mensaje lo devuelve siempre que hay cualquier tipo de problema respecto a esas librerías. Para averiguar la causa del problema que estaba devolviendo el congure, primero miramos que decía el archivo cong.log, ya que en este archivo se encuentra todo el log de lo que ha realizado el comando congure. En el chero de log las líneas que interesan principalmente son las que contiene este fragmento:
40 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 configure:2827: ee-gcc -o conftest -g -O2 -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile -L/usr /local/ps2dev/ps2sdk/ee/lib -L/usr/local/ps2dev/ps2sdk /ee/startup/crt0.o conftest.c -lSDL >&5 /usr/local/ps2dev/ee/lib/gcc-lib/ee/3.2.2/../../../.. /ee/bin/ld: cannot find -lSDL collect2: ld returned 1 exit status configure:2833: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "pongix" | #define PACKAGE_TARNAME "pongix" | #define PACKAGE_VERSION "0.3" | #define PACKAGE_STRING "pongix 0.3" | #define PACKAGE_BUGREPORT "" | #define PACKAGE "pongix" | #define VERSION "0.3" | /* end confdefs.h. */ | | /* Override any gcc2 internal prototype to avoid an error. */ | #ifdef __cplusplus | extern "C" | #endif | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char SDL_Init (); | int | main () | { | SDL_Init (); | ; | return 0; | } configure:2858: result: no configure:2869: error: * Can't find SDL library: http://www.libsdl.org Como podemos observar en estas líneas, congure no es capaz de compilar el test de la librería de SDL, porque no la encuentra. Debido a este problema inicialmente decidimos ir añadiendo rutas al LDFLAGS, pero con esto solo complicamos más el comando y no corregimos el problema que tenemos. Entonces lo que hacemos es extraer el código que el congure intenta ejecutar y lo copiamos en un archivo que decidimos llamarlo test1.c, el código que contiene este archivo es el siguiente:
4.13. TEST DE PORTABILIDAD DE UN PROYECTO SDL QUE UTILIZA AUTOTOOLS 41 #include <stdio.h> #include "SDL.h" #ifdef __cplusplus extern "C" #endif char SDL_Init (); int main () {SDL_Init (); ; return 0; } Ahora la idea es copiar el archivo test1.c en el directorio de los test básicos y modicamos el archivo Makele para indicarle que también compile el archivo test1.c: BINS = \testtimer.elf \ testcdrom.elf \ testendian.elf \ testerror.elf \ testjoystick.elf \ testver.elf \ checkkeys.elf\ test1.elf Al ejecutar make observamos el siguiente error: ee-gcc -D_EE -O2 -G0 -Wall -I/usr/local/ps2dev/ps2sdk/ee/include \ -I/usr/local/ps2dev/ps2sdk/common/include -I. -I../include \ -I/usr/local/ps2dev/ps2sdk/ports/include/SDL -c test1.c -o test1.o ee-gcc -mno-crt0 -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile \ -L/usr/local/ps2dev/ps2sdk/ee/lib -L/usr/local/ps2dev/ps2sdk/ports/lib \ -o test1.elf /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o test1.o \ -L. -lc -L/usr/local/ps2dev/gsKit/lib -L../lib -lsdl -lcdvd -lc -lsyscall \ -lkernel **/usr/local/ps2dev/ps2sdk/ports/lib/libsdl.a(sdl_main.o)(.text+0x8): In function `main':main/ps2sdk/sdl_main.c: definiciones múltiples de `main' test1.o(.text+0x0):test1.c: primero se definió aquí /usr/local/ps2dev/ps2sdk/ports/lib/libsdl.a(sdl_main.o)(.text+0x44): In function `main':main/ps2sdk/sdl_main.c: referencia a `SDL_main' sin definir** collect2: ld devolvió el estado de salida 1 make: *** [test1.elf] Error 1 Como podíamos observar el test1 monta bien pero en el momento de compilar devuelve el mensaje de error de múltiple denición de main, este error se debe a que la librería SDL contiene
42 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 una función main y en el momento que nosotros intentamos compilar el test, el compilador encuentra un segundo main y por esta razón genera este error. Como no entendemos para que han añadido un main a las librerías de SDL del port buscamos información por los foros de PS2 para ver si alguien comenta como solucionar este problema. La solución es reescribir la denición del main pasándole los parámetros argc y argv para que las SDL.h del port no redenen la función main. Esto supone un problema, ya que a los test del congure no podemos redenirle la cabecera, porque el código de los test se generan de manera automática. Tampoco investigamos mucho porque aunque consigamos que congure compile el test de las SDL, después congure devolverá un error en el momento que intente ejecutarlo ya que estamos desarrollando en una plataforma distinta a la que va destinado el test. Las dos soluciones que encontramos son: intentar obtener un Makele apto para compilar Pongix, portado a partir del Makele generado por las autotools para Linux o quitar los test que congure realiza a la librería de SDL en el momento de generar el Makele, para que así congure pueda seguir su proceso hasta el nal. La primera opción que decidimos probar es quitar los test de las librerías y ver que resultado obtenemos a partir de este experimento, para poder realizar esta prueba necesitamos tener instalados en Linux las libtool, el autoconf y el automake: sudo su apt-get install libtool sudo su apt-get install autoconf sudo su apt-get install automake Una vez tenemos instaladas estas aplicaciones lo primero que debemos hacer para que el con- gure no realice los test de las librerías es borrar del archivo congure.ac, las siguientes lineas: AC_CHECK_LIB(SDL, SDL_Init, , \ AC_MSG_ERROR([* Can't find SDL library: http://www.libsdl.org])) AC_CHECK_LIB(SDL_image, IMG_Load, , \ AC_MSG_ERROR([* Can't find SDL_image library: \ http://www.libsdl.org])) Estas líneas son las encargadas de comprobar si existen en el sistema las librerías que necesitaremos para poder compilar la aplicación, así que borrándolas el congure no testea ambas librerías. Una vez modicamos el archivo y guardado, tan solo tenemos que ejecutar los comandos necesarios para volver a generar el congure con los nuevos cambios realizados, para regenerar el congure ejecutamos los siguiente comandos en el orden establecido, ya que cada comando va generando archivos que el siguiente comando necesita. El primer comando que debemos ejecutar es aclocal este genera de nuevo el chero aclocal.m4 que contiene algunas deniciones básicas para así después poder ejecutar el autoconf.
4.13. TEST DE PORTABILIDAD DE UN PROYECTO SDL QUE UTILIZA AUTOTOOLS 43 aclocal Después tenemos que ejecutar el automake el cual genera los archivos que necesita tanto el autoconf como el mismo automake, para ejecutar este comando usamos la siguiente instrucción: automake --add-missing Y por último tan solo falta ejecutar el autoconf para que vuelva a generar el archivo congure con las nuevas opciones añadidas: autoconf Siguiendo estos pasos ya tenemos en el directorio de Pongix el congure nuevo que generamos, este no realiza los test que impiden que podamos generar el Makele. Así que el siguiente paso que decidimos seguir es ejecutar la línea de comando del congure que hemos ejecutado antes y el resultado que obtuvimos ahora es un archivo Makele generado con el nuevo congure, pero este Makele no garantiza que Pongix compile sin problema alguno. ./configure --build=$(./config.guess) --host=ee LDFLAGS="-mno-crt0 \ -L$PS2SDK/ports/lib" LIBS="-lSDL_image -lsdl" 2>&1 | less Ejecutamos el comando make y como resultado obtenemos el siguiente error: cd . && autoheader cd . \ && CONFIG_FILES= CONFIG_HEADERS=config.h \ /bin/bash ./config.status config.status: creating config.h config.status: executing default-1 commands make all-recursive make[1]: se ingresa al directorio `/home/rul/PFC/pruebas/sdl_ps2 /pongix-0.3' Making all in src make[2]: se ingresa al directorio `/home/rul/PFC/pruebas/sdl_ps2 /pongix-0.3/src' ee-gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDATADIR=\""/usr/local/share /pongix/"\" -g -O2 -c pongix.c En el fichero incluído de mundo.h:22, de pongix.c:19: **util.h:22:21: SDL/SDL.h: No existe el fichero ó directorio** **util.h:23:27: SDL/SDL_image.h: No existe el fichero ó directorio** En el fichero incluído de mundo.h:22, de pongix.c:19: util.h:29: error de decodificación antes del elemento '*' util.h:29: aviso: la definición de datos no tiene tipo o clase de almacenamiento
44 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 util.h:31: error de decodificación antes del elemento '*' util.h:31: aviso: la definición de datos no tiene tipo o clase de almacenamiento util.h:32: error de decodificación antes del elemento '*' En el fichero incluído de mundo.h:23, de pongix.c:19: dirty.h:27: error de decodificación antes de "SDL_Rect" dirty.h:27: aviso: no hay punto y coma al final del struct o union dirty.h:29: error de decodificación antes del elemento '}' dirty.h:29: aviso: la definición de datos no tiene tipo o clase de almacenamiento dirty.h:32: error de decodificación antes del elemento '*' dirty.h:32: aviso: la definición de datos no tiene tipo o clase de almacenamiento dirty.h:33: error de decodificación antes del elemento '*' dirty.h:34: error de decodificación antes del elemento '*' dirty.h:35: error de decodificación antes del elemento '*' dirty.h:36: error de decodificación antes del elemento '*' dirty.h:37: error de decodificación antes del elemento '*' En el fichero incluído de mundo.h:24, de pongix.c:19: fuente.h:30: error de decodificación antes de "SDL_Rect" fuente.h:30: aviso: no hay punto y coma al final del struct o union fuente.h:32: error de decodificación antes del elemento '*' fuente.h:32: aviso: la definición de datos no tiene tipo o clase de almacenamiento fuente.h:34: error de decodificación antes del elemento '}' fuente.h:34: aviso: la definición de datos no tiene tipo o clase de almacenamiento fuente.h:37: error de decodificación antes del elemento '*' fuente.h:37: aviso: la definición de datos no tiene tipo o clase de almacenamiento fuente.h:38: error de decodificación antes del elemento '*' fuente.h:39: error de decodificación antes del elemento '*' fuente.h:40: error de decodificación antes del elemento '*' fuente.h:41: error de decodificación antes del elemento '*' fuente.h:42: error de decodificación antes del elemento '*' fuente.h:43: error de decodificación antes del elemento '*' En el fichero incluído de pongix.c:19: mundo.h:30: error de decodificación antes de "SDL_Surface" mundo.h:30: aviso: no hay punto y coma al final del struct o union mundo.h:31: aviso: la definición de datos no tiene tipo o clase de almacenamiento mundo.h:34: error de decodificación antes del elemento '*' mundo.h:34: aviso: la definición de datos no tiene tipo o clase de almacenamiento mundo.h:39: error de decodificación antes del elemento '}'
4.13. TEST DE PORTABILIDAD DE UN PROYECTO SDL QUE UTILIZA AUTOTOOLS 45 mundo.h:39: aviso: la definición de datos no tiene tipo o clase de almacenamiento mundo.h:42: error de decodificación antes del elemento '*' mundo.h:42: aviso: la definición de datos no tiene tipo o clase de almacenamiento mundo.h:43: error de decodificación antes del elemento '*' mundo.h:44: error de decodificación antes del elemento '*' mundo.h:45: error de decodificación antes del elemento '*' mundo.h:46: error de decodificación antes del elemento '*' mundo.h:47: error de decodificación antes del elemento '*' mundo.h:48: error de decodificación antes del elemento '*' mundo.h:49: error de decodificación antes del elemento '*' pongix.c: En la función `main': pongix.c:25: operadores inválidos para el binario * pongix.c:29: aviso: asignación de tipo de apuntador incompatible pongix.c:34: apuntador deferenciado a tipo de dato incompleto make[2]: *** [pongix.o] Error 1 make[2]: se sale del directorio `/home/rul/PFC/pruebas/sdl_ps2 /pongix-0.3/src' make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio `/home/rul/PFC/pruebas/sdl_ps2 /pongix-0.3' make: *** [all-recursive-am] Error 2 Este error lo que esta diciendo es que no puede encontrar los archivos de cabecera SDL que le hemos dicho que utilice, para ser exactos los esta buscando en un directorio SDL dentro de la raíz de Pongix, para poder solventar este problema temporalmente decidimos crear un enlace simbólico a las SDL del PS2SDK con el siguiente comando para así poder ver si compila Pongix. >ln -s /usr/local/ps2dev/ps2sdk/ports/include/ SDL Ahora make ya encuentra los archivos de cabecera, pero aún así devuelve el siguiente error: make all-recursive make[1]: se ingresa al directorio `/home/rul/PFC/Ejemplos/pongix' Making all in src make[2]: se ingresa al directorio `/home/rul/PFC/Ejemplos/pongix/src' ee-gcc -g -O2 -mno-crt0 -L/usr/local/ps2dev/ps2sdk/ports/lib -o pongix pongix.o util.o pelota.o dirty.o paleta.o mundo.o menu.o juego.o fuente.o cursor.o -lSDL_image -lsdl /usr/local/ps2dev/ee/bin/../lib/gcc-lib/ee/3.2.2/../../../../ee/bin/ld: aviso: no se puede encontrar el símbolo de entrada _start; usando por defecto 0000000000100040 util.o(.text+0x74): In function `iniciar_sdl': /home/rul/PFC/Ejemplos/pongix/src/util.c:33: undefined reference to `printf' util.o(.text+0x164): In function `cargar_imagen': /home/rul/PFC/Ejemplos/pongix/src/util.c:71: undefined reference to
46 CAPÍTULO 4. PORTANDO UN JUEGO A LA PS2 `memset' util.o(.text+0x170):/home/rul/PFC/Ejemplos/pongix/src/util.c:73: undefined reference to `strcat' util.o(.text+0x1f0):/home/rul/PFC/Ejemplos/pongix/src/util.c:79: undefined reference to `printf' pelota.o(.text+0x1c): In function `dist': /home/rul/PFC/Ejemplos/pongix/src/pelota.c:25: undefined reference to `sqrt' pelota.o(.text+0x4c): In function `pelota_iniciar': /home/rul/PFC/Ejemplos/pongix/src/pelota.c:31: undefined reference to `malloc' ... Como podemos observar de las cosas que se queja es que le falta referencias a librerías, lo cual indica que el Makele que generamos no esta de forma correcta, ya que falta por cubrir dependencias. El siguiente paso que realizamos para intentar afrontar este nuevo inconveniente, es ir añadiendo a los FLAGS de congure las librerías que vayamos necesitando según va pidiendo Pongix, y ir generando de nuevo el Makele con esos FLAGS nuevos. Después de varias pruebas con distintas combinaciones de ags, encontramos los ags adecuados para resolver todas las dependencias de Pongix: >./configure --build=$(./config.guess) --host=ee LDFLAGS="-mno-crt0 \ -T/usr/local/ps2dev/ps2sdk/ee/startup/linkfile \ /usr/local/ps2dev/ps2sdk/ee/startup/crt0.o" LIBS="-L. \ -L/usr/local/ps2dev/ps2sdk/ee/lib -L/usr/local/ps2dev/ps2sdk/ee/lib \ -L/usr/local/ps2dev/gsKit/lib -L../lib \ -L/usr/local/ps2dev/ps2sdk/ports/lib -L/usr/local/ps2dev/ee/lib \ -lSDL_image -lsdl -lsdlmain -ljpeg -lpng -lz -ltiff -lmc -lm -lc \ -lkernel" 2>&1 | less Al ejecutar el comando make con el nuevo chero Makele que obtenemos a partir de esta línea de comando, conseguimos como resultado un chero Pongix dentro del directorio src. Ahora ya tenemos un ejecutable compilado en Linux con las herramientas de compilación de la PS2 que es lo que pretendemos conseguir. Ahora tan solo tenemos que probar en la PS2 este Pongix, para ver si el ejecutable que acabamos de obtener funcionaba correctamente. El siguiente paso es lanzar el loader pksh para conectar con la PS2 y ejecutar el Pongix que acabamos de compilar. Lo primero que debemos ejecutar es el comando pksh y de esta manera entramos en la consola de pksh: >pksh Una vez estamos dentro lo siguiente que hacemos es lanzar Pongix: pksh>cd src (el ejecutable que configure nos ha creado se encuentra dentro del directorio src de la carpeta pongix) pksh>execee pongix
4.13. TEST DE PORTABILIDAD DE UN PROYECTO SDL QUE UTILIZA AUTOTOOLS 47 En la pantalla de PS2 no obtenemos ningún resultado y en la salida de nuestro monitor obtenemos el siguiente mensaje : pksh> execee pongix log: loadelf: fname host:pongix secname all log: loadelf version 3.30 log: Input ELF format filename = host:pongix log: 0 00100000 000c20ac ............. log: Loaded, host:pongix log: start address 0x1000e0 log: gp address 00000000 log: SDL: initializing gsKit in PAL mode log: SDL_SetVideoMode 640 x 480 x 16 log: SDL_Video: local texture allocated at 0x00424180 log: SDL_video: centered surface of (640, 480) onto a screen of (640, 512) at (0, 16) log: SDL_video: ratio of 1:1.000, rastered surface is (640, 480) log: SDL: HW Surface Flipping ! log: open name host:imagenes/fondo_juego.jpg flag 1 data 45a78 log: open fd = 2 log: open name host:imagenes/pelota.bmp flag 1 data 45a78 log: open fd = 2 log: open name host:imagenes/pelota.bmp flag 1 data 45a78 log: open fd = 2 log: open name host:imagenes/paleta.bmp flag 1 data 45a78 log: open fd = 2 log: open name host:imagenes/paleta.bmp flag 1 data 45a78 log: open fd = 2 log: open name host:imagenes/fuente.bmp flag 1 data 45a78 log: open fd = 2 log: Fuente: se encontraron 112 letras log: + cargando: host:imagenes/fuente.bmp log: Reiniciando el men pksh> Llegados a este punto volvemos a encontrar con un nuevo obstáculo para conseguir la portabilidad de Pongix. Decidimos analizar el código de Pongix y vemos que utiliza unos archivos de imagen para el fondo de pantalla y el resto de dibujos que aparecen. Esto supone un inconveniente porque como hemos comprobado en los test anteriores de portabilidad las SDL no son capaces de cargar más de un archivo de imagen. Y después de este experimento llegamos a un par de conclusiones: Es difícil usar autotools pensando en compilación cruzada. Sobretodo porque hay test que las autotool necesita ejecutar en la máquina de destino y no en la de desarrollo El port de SDL para PS2 contiene errores en la implementación de la entrada/salida.
54 CAPÍTULO 6. CONCLUSIONES utilizando reStructuredText ese objetivo lo completamos. El Estudio de la portabilidad de un videojuego de Linux a PS2 , tenemos que decir que Pongix el videojuego que escogimos para portar utilizando el port de SDL del PS2DEV no conseguimos nalmente portarlo y mucho menos utilizando las autotools, por dos motivos: 1. Es difícil usar autotools pensando en la Compilación cruzada. Hay tests de las autotools que deberían ejecutarse en la máquina de destino y no en la de desarrollo. 2. El port de SDL para PS2 contiene errores en la implementación de la entrada y salida. Por otro lado sería importante destacar que durante el estudio de la portabilidad fuimos capaces de portar las aplicaciones cuadrado y circulo , por eso podemos decir que el entorno era capaz de portar aplicaciones entre GNU/Linux y PS2, pero tras numerosos contratiempos vimos que tenían que ser aplicaciones simples que no utilizaran cheros externos. Por falta de tiempo para poder invertir más en la investigación de como portar Pongix, podríamos decir que a partir de esta documentación se podría continuar la investigación en un futuro. Para no perder todo el tiempo que ya le dedicamos nosotros, la futuras tareas que podrían ayudar a la portabilidad serían en un principio dos: 1. Investigar el error que devuelve las librerías a la hora de intentar cargar más de dos cheros de imágenes, ya que disponemos en el repositorio de las fuentes de estas librerías. 2. Usar la librería que implemento el creador de Super Mario Wars, y estudiar cual es el proceso que sigue para gestionar el problema de la carga de cheros de imágenes.
Bibliografía [FSF1996] The free software foundation. The free software denition. 1996. http://www.gnu.org/philosophy/free-sw.html [PS22000] PlayStation 2. Sony PlayStation 2. 2000. http://en.wikipedia.org/wiki/Playstation2 [SON1945] Sony. Sony. 1945. http://en.wikipedia.org/wiki/Sony [GNU1996] The free software foundation. El sistema operativo GNU. 1996. http://www.gnu.org/home.es.html [LIN2002] Linux. Linux. 2002. http://en.wikipedia.org/wiki/Linux [PS2SDK] PS2SDK. http://ps2dev.org/PS2/Projects/ps2sdk [UBU2004] Ubuntu. Ubuntu-es. 2006. http://www.ubuntu-es.org [SDL2006] Simple DirectMedia Layer (SDL). 2006 http://www.libsdl.org/index.php [SMW2006] Playstation 2 version by Evilo and the Froggies. Super Mario Wars. 2006. http://psxdev.info/evilo/smw.html [PGX2006] LosersJuegos (GPL). Pongix (Versión de Pong para Linux). 2006. http://www.losersjuegos.com.ar/juegos/pongix/pongix.php [DSK2004] DualShock. DualShock. 2004. http://en.wikipedia.org/wiki/DualShock [EYE2004] EyeToy. EyeToy. 2004. http://en.wikipedia.org/wiki/EyeToy [SIN2004] SingStar. SingStar. 2004. http://en.wikipedia.org/wiki/SingStar [GUI2005] Guitar Hero. 2005. http://en.wikipedia.org/wiki/Guitar_Hero_%28video_game%29 [DOC.01] ps2dev.ofcode.com by Neofar. Arquitectura y Programación PS2. http://ps2dev.ofcode.com/modules/wordpress/?page_id=37 [URL.01] DMS Technologies. http://www.dms3.com/ [URL.02] ToxicOs. (Enlace perdido). http://www.teamtoxic.com.cn/ [URL.03] Swap Magic 3. http://www.swapmagic3.com/ 55
56 BIBLIOGRAFÍA [URL.04] Manual de Cogswap y carga de backups con Swap Magic. http://www.planetadejuego.com/foros/manual-de-cogswap-y-carga-de-backupscon-swap-magic-1418.html [URL.05] HD Advance. http://www.hdadvance.com/ [URL.06] HDD Dump Tool. http://www.dms3.com/dms4se/downloads.html [URL.07] PCSX2. http://www.pcsx2.net/ [URL.08] Guía de conguración del PCSX2. http://www.pcsx2.net/guide.php?lang=es_ES [URL.09] Volcador de BIOS de PS2. BIOS Dumper. http://www.pcsx2.net/downloads.php?p=tool [URL.10] PS2DEV. Loaders PS2. http://ps2dev.org/ [DEB1997] Debian. Debian GNU/Linux. 1997. http://www.debian.org/index.es.html [URL.11] Tutorial de instalación de una distribución Linux en PS2 (BlackRhino). http://www.xtremett.com/modules.php?name=Content&pa=showpage&pid=5 [URL.12] BlackRhino. http://blackrhino.xrhino.com [URL.13] Repositorio svn de PS2DEV. http://svn.ps2dev.org [AUT2003] Autotools. GNU build system. 2003. http://en.wikipedia.org/wiki/GNU_build_system [URL.14] GNU Autoconf, Automake and Libtool. Cross Compilation with GNU Autotools. http://sourceware.org/autobook/autobook/autobook_258.html [URL.15] SDL. Simple DirectMedia Layer. http://www.libsdl.org/ [URL.16] GCC. The GNU Compiler Collection. http://gcc.gnu.org/ [URL.17] Pukklink shell (pksh). PS2DEV. http://ps2dev.org/ps2/Loaders/PC_side_clients [URL.18] Ps2link v1.46. http://ps2dev.org/PS2/Loaders/PS2_side_boot_loaders/ [URL.19] ElOtroLado.net. http://www.elotrolado.net/ [URL.20] Mini tutorial: Crear un boot cd by Suloku. ElOtroLado.net. http://www.elotrolado.net/hilo_mini-tutorial-crear-un-boot-cd_462421 [URL.21] Toolchain. GNU Toolchain. http://en.wikipedia.org/wiki/GNU_toolchain [RST2006] RestructuredText. Markup Syntax and Parser Component of Docutils. http://docutils.sourceforge.net/rst.html [PON1972] Pong. Atari. 1972. http://en.wikipedia.org/wiki/Pong [URL.22] LosersJuegos. http://www.losersjuegos.com.ar/principal/principal.php [NIN1889] Nintendo. Nintendo. 1989. http://en.wikipedia.org/wiki/Nintendo