PROGRAMACIÓN EN PSP

PROGRAMACIÓN EN PSP
ALBERT PAÑOS
DAVID CUENCA
ANTONI SERRA
PSE
1
INDICE
INTRODUCCIÓN........................................................... 3
HISTORIA PSP ............................................................. 4
Especificaciones técnicas ............................................ 5
XrossMediaBar ............................................................ 9
Desarrollador.......................................................... 9
Legalidad pirateo PSP ................................................. 10
HOMEBREWS ............................................................ 15
PROGRAMACIÓN EN PSP: LUA ..................................... 19
PRÁCTICA: JUEGO EN LUA FUNCIONANDO EN PSP ......... 20
JUEGO EN PSP ........................................................... 29
COMPARATIVA Y CONCLUSIONES ................................ 29
BIBLIOGRAFIA........................................................... 31
2
INTRODUCCIÓN
La industria del videojuego es, a día de hoy, el sector con una facturación mayor
dentro del sector del ocio. En los últimos años ha superado incluso a la
todopoderosa industria discográfica.
Dentro del sector, en el presente la importancia de las consolas de sobremesa ha
disminuido de forma progresiva para dejar paso a las cada vez más crecientes
consolas portátiles. El monopolio de Nintendo con su Game Boy ha tocado a su fin,
y a día de hoy el de las portátiles es la que posee unas mayores perspectivas de
desarrollo a largo plazo. Su capacidad de juego en cualquier parte ha propiciado
que cada vez más usuarios descubran las posibilidades y ventajas que ofrece este
sistema.
Curiosamente, su desarrollo ha evolucionado en paralelo con el desarrollo de
software casero para ellas; por algún motivo, los usuarios tienen mas tendencia a
volcarse en el desarrollo de las portátiles; seguramente debido a que el hecho de
poder usarse en cualquier parte favorece el uso de muchas aplicaciones extra (tales
como lectores de pdf, reproductores de música, o receptores wifi) que no ofrece de
base el fabricante.
Con todo, la complejidad es mayor de lo que podría creerse a priori, pues la
compañía desarrolladora no ofrece ninguna facilidad para ello.
De todas las consolas portátiles en el mercado, la PSP es la que mas grupos de
desarrollo amateurs ha generado a su alrededor: entre otros motivos por ser la
consola más potente y con mas potencial; de hecho es casi un ordenador en
miniatura.
En el siguiente documento ofreceremos una visión del desarrollo de software
“casero” para la consola PSP, desde el punto de vista legal, técnico y de desarrollo,
pues crearemos un minijuego casero que funciona en una consola PSP.
3
HISTORIA PSP
Sony anunció por primera vez el desarrollo de la Playstation Portable en una
conferencia de prensa previa al E3 2003. Aunque no se presentó ningún dato
referente al sistema ni en la conferencia ni en el E3, Sony si mostró una lista con
extensos detalles referentes a la nueva consola.
EN el CEO de Sony Computer Entertainment, Ken kutaragi llamó al dispositivo el
“Walkman del siglo 21” en referencia a las capacidades multimedia de la consola.
Diversas webs de videojuegos quedaron impresionadas por las capacidades de la
consola y estaban expectantes por el potencial que podía tener como plataforma de
videojuegos.
Las primeras imágenes conceptuales de PSP aparecieron en Noviembre de 2003 en
el Sony Corporate Strategy Meeting y mostraron una PSP con botones anchos y sin
stick analógico. Aunque algunos expresaron su preocupación por la falta de stick
analógico, esos miedos se disiparon cuando la PSP fue presentada oficialmente en
la conferencia de prensa de Sony durante el E3 de 2004. Además de anunciar mas
detalles sobre el sistema y sus accesorios, Sony también mostró una lista con 99
compañías desarrolladoras que habían mostrado su apoyo para la nueva consola.
Diversas demos de PSP como el Metal Gear Acid de Konami, y el Wipeout Pure de
SCE Studio Liverpool se mostraron en esa conferencia.
Lanzamiento
El 17 de Octubre de 2004 Sony anunció que la PSP se lanzaría en Japón el 12 de
Diciembre de 2004 a un precio de 19800 yenes (185 euros) para el modelo base, y
24800 yenes (unos 230 euros) para el Sistema “Value”. La consola fue lanzada con
éxito con más de 200,000 unidades vendidas el mismo día.
Sony anunció el 3 de Febrero de 2005 que la PSP saldría a la venta en
Norteamérica el 24 de Marzo de 2005 en una configuración a un precio
recomendado de 249$. Algunos expresaron su preocupación debido al alto precio,
que era casi 20 dólares mas alto que el precio en Japón, y mas de 100$ de
diferencia con la Nintendo DS. A pesar de ello, el lanzamiento americano de PSP fue
un éxito, aunque dos semanas después hubo noticias de que el sistema no se
estaba vendiendo tan bien como se esperaba a pesar de las declaraciones de Sony
de que se habían vendido 500,000 unidades en los dos primeros días.
4
PSP debía haber sido lanzada el mismo día en las regiones PAL (como Europa) y en
Norteamérica, pero el 15 de Marzo de 2005, Sony anunció que el lanzamiento en
las regiones PAL se retrasaría debido a la alta demanda de la consola en
Norteamérica en Japón. Un mes después, el 25 de Abril de 2005, Sony anunció que
PSP se lanzaría en la región PAL el 1 de Septiembre de 2005 por 249€. Sony
defendió que el alto precio, que era cerca de 100$ mayor que en Norteamérica,
argumentando que los consumidores norteamericanos tenían que pagar tasas
locales y que el IVA era mayor en el Reino Unido que en USA. A pesar del alto
precio, las consolas de la región PAL fue un rotundo éxito, vendiendo mas de
185,000 unidades en el Reino Unido solamente, mas del doble que las ventas del
1er día de Nintendo DS (87,000). El sistema también disfrutó de un gran éxito en
otras regiones PAL con más de 25,000 unidades reservadas en Australia y cerca de
un millón por toda Europa en la primera semana
Especificaciones técnicas
¾
Unidad de Procesamiento Central: Custom CPU multipropósito Sony
"Allegrex" basado en MIPS de velocidad configurable en 1/333 MHz, incluye un
CPU basado en MIPS32 Rk-4 de 32 bits, un FPU (Unidad de Coma Flotante) y un
VFPU de cálculo vectorial. También incluye un procesador conocido como "Media
Engine"; siendo también un CPU basado en MIPS32 Rk-4 de 32 bits dedicado al
manejo de audio/video por hardware y un DSP (Procesador digital de señal)
programable "Virtual Mobile Engine". El "Media Engine" tiene funcionalidades
similares al CPU principal y sirve como equivalente ante la falta de VPU.
¾
Memoria: 32 MB RAM de memoria principal (64 MiB en PSP Slim & Lite) y 4 MiB
DRAM embedida; los 4 MiB corresponden a 2 MiB para el chip gráfico y a 2 MiB
del "Media Engine", ambos CPUs contienen 16KB de caché de instrucciones y
caché de datos y 16KB de scratchpad, además de 32 MiB de memoria Flash
NAND (usada para guardar configuraciones y archivos del sistema).
5
¾
Chip gráfico: Custom GPU de velocidad configurable en 1/166 MHz con 2 MiB
de memoria interna e interfaz de 512 bits soportando renderizado de polígonos
y NURBS, iluminación direccional por hardware, environment projection y
texture mapping, compresión de texturas y mosaicos, niebla, alpha blending,
depth and stencil test, vertex blending para efectos de morphing y dithering;
todo en 16 o 24 bits de profundidad de color. El Chip gráfico también maneja la
salida de vídeo. El sistema es capaz de mover unos 33 millones de polígonos
iluminados y tratados, con un ratio de 664 millones de píxeles por segundo.
¾
Chip de Sonido: Custom DSP configurable Sony "Virtual Mobile Engine" Sonido
3D, Multi-Canal 7.1ch.
¾
Pantalla: 4,3 pulgadas, 16:9 widescreen TFT LCD 480 x 272 píxeles (16.77
millones de colores)
¾
Códecs: ATRAC3 plus, AAC, MP3, WMA, AVC/@MP for Picture / Movi, H.264
(MPEG-4 Part 10). Soporte de imágenes en formato JPEG, GIF, TIFF, BMP y
PNG.
¾
Media: Lectura de datos desde sistema de discos ópticos UMD (Universal Media
Disk) y Memory Stick PRO DUO, conexión y manejo remoto del sistema
PlayStation 3. (Salida de TV en PSP Slim & Lite)
¾
WIFI: Wi-Fi IEEE 802.11b permite conexión Ad-HOC e Infraestructura con otras
PSP y con Internet con jugabilidad para 2/16 jugadores simultáneamente. El
software de sistema incluye un Navegador Web basado en Access NetFront.
¾
Gamesharing: Algunos títulos del sistema PSP soportan la transferencia de
juego en modo multijugador con otras consolas que no cuenten con el juego en
cuestión, esto se logra enviando los datos a través de conexión Ad-Hoc y
cargándolos sobre la memoria RAM. El soporte de esta opción está limitado a los
juegos que hacen uso de ella.
¾
Accesorios: Cámara de video de 1.2 mega píxeles "Chotto Shot", receptor de
señal GPS, receptor de TV digital y PSP Headset (incluido con ciertos títulos)
¾
Interfaz: XMB "XrossMediaBar" desarrollada por Sony y presente en sus
nuevos televisores así como en el sistema PlayStation 3.
¾
Medidas: 190 mm de anchura (110 de pantalla TFT) y 74 mm de altura.
¾
Peso: 260 g sin incluir batería (320 gramos con batería).
¾
Diseño: Shin'ichi Ogasawara para Sony Computer Entertainment (subsidiaria
de Sony Corporation)
6
PSP Desmontada, vemos la placa base y la tarjeta WIFI
(parte inferior)
Diagrama de bloques del sistema PSP
7
Especificaciones del disco UMD
Imagen del disco UMD
Sony originalmente desarrolló el UMD como un medio de almacenamiento
multimedia en tres versiones diferentes: PSP Game, UMD Video y UMD Audio.
Existe la posibilidad de usarse en un futuro para almacenar datos; es el caso del
HI-MD. En el momento de la salida de la Playstation Portable, el formato PSP Game
obtiene un soporte muy amplio pero en el caso de UMD Video no consigue el
soporte internacional que se esperaba debido a la fortaleza del DVD Video. En
cuanto al UMD Audio su soporte inicial fue nulo debido sobre todo a la fuerte
competencia de soportes mundialmente aceptados como el Compact Disc u otros
soportes como el Minidisc, DVD Audio y SACD.
Dimensiones: Aprox. 65×64x4.2 (mm)
Peso: Aprox. 10g
Diámetro: 60 mm
Capacidad máxima: 1.8GB
Longitud de onda del láser: 660nm (Láser rojo)
Encriptación: AES 128bit
Utilidades: Juego de PSP, Audio UMD (codec ATRAC3plus, PCM, (MPEG4 AVC),
UMD Video (codec MPEG4 AVC, ATRAC3plus, Caption PNG)
8
XrossMediaBar
XMB en PSP
PSX XMB en una Sony BRAVIA TV
El XrossMediaBar (XMB) es la interfaz de usuario gráfica de Sony para PSP y PS3
La interfaz incluye iconos que se esparcen horizontalmente a través de la pantalla.
La navegación mueve los iconos en vez del cursor. Estos iconos se usan como
categorías para organizar las opciones disponibles para el usuario. Cuando un icono
es seleccionado en la barra horizontal, diversas opciones mas aparecen en la
vertical, encima y debajo de él (seleccionable con el pad)
Usado originalmente en la PSX, el XroosMediaBar se usa como interfaz estándar
tanto en PSP como en PS3. Desde 2006 también se utiliza en los televisores WEGA,
BRAVIA desde la 3000 (solo en las series S y superior) y en el receptor de alta
salida STR-DA 5200ES AV. Los menús de los Sony Ericsson K859 i W910 también
son una versión del XMB, dando a entender que el XMB será lo próximo que se
implemente en los teléfonos Sony Ericsson. También se ha confirmado para la
próxima generación de las televisiones BRAVIA
Desarrollador
Q-Games Ltd, una pequeña compañía de desarrollo con sede en Kyoto, Japón
desarrolló la tecnología gráfica que hay tras el XMB, su estilizado fondo i los
visualizadores. La versión para PS3 usa una versión del explorador NetFront de
AccessCo. Como su explorador web interno. Es el mismo que en la PSP (SonyBranded NetFront 2.81) con las misma interface, menús y teclado virtual. Sony
también ha colaborado con la Universidad de Stanford para traer el proyecto
Folding@home a la PS3. Una vez descargado, el programa puede ser configurado
para funcionar cuando el sistema esta sin hacer nada o ejecutado manualmente
desde el XMB
9
Legalidad pirateo PSP
Actualmente se ha declarado una sentencia en el Tribunal de Valencia sobre la
legalidad de piratear la PSP. La sentencia fue la siguiente:
Conforme al Art. 270-3 del Código Penal, se castiga a “quien fabrique, importe,
ponga en circulación o tenga cualquier medio específicamente destinado a facilitar
la supresión no autorizada o la neutralización de cualquier dispositivo técnico que
se haya utilizado para proteger programas de ordenador o cualquiera de las otras
obras, interpretaciones o ejecuciones en los términos previstos en el apartado 1 de
este artículo.” Atendiendo a la literal dicción del referido artículo, y examinadas las
actuaciones, se impone la confirmación de la resolución recurrida, en la que la
Magistrado a quo, a petición del Ministerio Fiscal, acuerda el sobreseimiento
provisional de la causa al amparo del Art. 641-1 de la Ley de Enjuiciamiento
Criminal., por ser racional y ajustado a derecho su razonamiento de haberse
acreditado, por la prueba pericial practicada, que los chips que se instalan o se
pueden instalar en las videoconsolas de autos, pueden servir, desde luego, como
dispositivo tendente a desprotegerlas para permitir utilizar juegos no originales,
pero también, para permitir la ejecución de juegos originales de otras zonas y para
convertir la consola en un ordenador personal apto para realizar múltiples tareas
absolutamente lícitas, como pueda ser el manejo de fotografías, ejecutar juegos de
libre distribución no diseñados para consola, escuchar música, etc. No se cumpliría,
por tanto, el requisito de la exclusiva o específica destinación a la supresión o
neutralización de dispositivos de protección de las consolas, y en este sentido el
razonamiento de la instructora no resulta desacertado para este Tribunal.
Proceso de Downgrade
La consola de Sony está oficialmente vetada para ejecutar software de usuario.
Como hemos visto, actualmente es perfectamente lícito, pero la empresa no tiene
porqué proporcionar los medios para ello; así que los usuarios se ven obligados a
buscar errores de programación o “bugs” en el sistema para intentar buscar la
forma de acceder a todas las propiedades que ofrece el sistema. La idea es ejecutar
un “Exploit” o programa malicioso cuyo objetivo es romper las protecciones de
seguridad del sistema.
En si, toda la vida de PSP ha sido una lucha entre los programadores y Sony;
Llegando al punto de sacar actualizaciones periódicas solo para evitar la última
forma de pirateo.
10
El Exploit más común consiste en lo que llamamos “Downgrade”.
DOWNGRADE
En las versiones del firmware (esto es, la versión del software de la consola) 1.00
a 1.50 la ejecución de código casero era posible sin necesidad de ningún tipo de
exploit. Inmediatamente, Sony saco la versión 1.51 que corregía ese error. Desde
ese momento, el objetivo de todos los exploits mas populares de la red han sido el
“downgrade”, es decir, el volver a las versiones anteriores (normalmente la 1,5 por
ser la última) dónde si eran posible este tipo de acciones de forma sencilla.
Hay líneas de desarrollo que han intentado la ejecución de código casero en las
versiones posteriores directamente, pero esto no suele ser lo más óptimo: primero
porque suele ocurrir que la libertad de acción en estos casos es mucho menor y
solo permite código de tamaño pequeño o de acciones limitadas; y segundo porque
cada nueva versión tiene que buscar su propio exploit lo cuál es una tarea de
meses.
En este documento centraremos el estudio en describir un tipo de downgrade
estándar para mostrar cómo actúa sin entrar en detalles específicos.
Para empezar a describir lo necesario para realizar un Downgrade en la consola,
empezaremos por recalcar las características de la misma, necesarias para
entender el proceso:
Cada consola tiene un tipo de placa y, además, un tipo de consola.
Respecto al tipo de placa, hay que saber que ciertas placas no son compatibles con
la función de Downgrade. Hasta hace poco por lo menos, había un tipo de placa que
la hacia incompatible debido a sus altas probabilidades de “brickeo” (Apagado
definitivo de la consola sin probabilidad de iniciarla de nuevo. Del inglés brick,
ladrillo, porque es poco más que en lo que se convierte la consola después de que
ocurra).
11
Una vez confirmado que nuestra consola
está lista por hardware para el downgrade
se comprueba el software. El tipo de
consola indica la actualización por defecto
que
incluye,
firmware
y
esto
se
es,
indica
la
con
versión
una
del
letra
mayúscula asociada a una versión (A, B...
por ejemplo el G es la 2.01)
Cada versión del firmware tiene su propio
Comprobación de tipo de placa
exploit. Para el usuario medio saber que
exploit actúa y cómo lo hace no es importante, en la mayoría de casos los archivos
necesarios para el downgrade se presentan para que sea hecho de forma más o
menos intuitiva.
A modo de ejemplo se presentará la explicación técnica de dos casos de exploit
usados para el downgrade.
Buffer Overflow
El método mas conocido de exploit es el conocido como de “Buffer Overflow”.
Las variables locales de una rutina se guardan en la pila, que es una zona de la
memoria apuntada por un registro hardware (SP). Cuando se entra en la rutina,
hace falta guardar la dirección donde estaba para volver más tarde donde estaba
para seguir con la ejecución del programa. La PSP (procesador mips) guarda dicha
dirección en un registro llamado RA (return address). Si durante la rutina se llama
a otra rutina, dicho registro perdería su valor, por eso es necesario guardarlo en
memoria para poder restaurar su valor mas adelante. Esa información se guarda en
la pila.
Un buffer overflow (desbordamiento del buffer) es una condición anómala que se
produce en un programa al exceder un buffer en memoria (por ejemplo, se excede
la capacidad de un array). Suelen ser consecuencia de un fallo en la programación
(lo que se conoce como bug).
12
En este caso, se uso una imagen específicamente diseñada, para que al ser abierta
por el visor de imágenes desbordara la capacidad del buffer, sobrescribiendo
también la pila hasta el punto de perder el índice de retorno del programa.
Cuando el error ocurre y el punto de ejecución es movido al lugar sobrescrito por el
overflow se consigue un puntero para la ejecución de algún código sin pasar por los
sistemas de seguridad.
Este fallo fue explotado hasta poder hacer funcionar un programa que permitía
instalar una versión anterior del firmware, sobrescribiendo la existente. Como se
había saltado los sistemas de seguridad que permitían comprobar que la versión
instalada era más reciente, sencillamente borraba la actual y escribía la antigua
volviendo al firmware con el bug para poder hacer funcionar código casero.
El exploit 1.50
En el firmware 1.00 la ejecución de código casero era libre, es decir, nadie se
planteó que alguien pudiera hacer un cargador de código casero (eboot). Con la
versión 1.50, se solucionó eso.
Para contrarrestar eso, salió un exploit llamado “swaploit”, era un método que
aprovechaba un fallo en la lectura de la tarjeta de memoria que permitía cargar
código casero. No obstante, era un método que requería tener dos tarjetas de
memoria (memory sticks) e intercambiarlas en el momento justo, cosa que si no se
hacía bien, podía dañar la consola.
Poco tiempo después salió el Kxploit, un método mucho mas seguro que solo
requería de una tarjeta para funcionar.
El método era el siguiente:
El bootloader (cargador de programas, por así decirlo) de la PSP comprueba la
carpeta de la tarjeta de memoria (en formato FAT) que el código sea legal o
registrado (signed). Si encuentra código no legal, se niega a iniciar el programa.
Sin embargo, el sistema operativo (OS) de la PSP no comprueba eso. Asume
sencillamente que el bootloader ha filtrado cualquier código no válido y ejecuta el
código que encuentra.
Pero da la casualidad que el bootloader y el OS de la PSP no funcionan de la misma
manera. Se descubrió que el bootloader ignoraba el símbolo “%” pero el OS no. La
13
solución fue poner dos carpetas con el mismo nombre. La primera estaría vacía,
pero la segunda, que contendría el programa, tendría el mismo nombre pero con el
símbolo “%”. De esta forma el bootloader leería “nombre%” como “nombre” y daría
el acceso, y el OS cargaría el programa.
Esta es la idea básica detrás de la ejecución de código casero en PSP.
Reacción y contra reacción: Custom Firmware
El mayor handicap a la hora de jugar con la versión 1.50 es que eso implica
renunciar a las actualizaciones de Sony en materia de novedades en aplicaciones y
funcionalidades (por ejemplo, en la 1.50 no había navegador web con lo que no era
posible el acceso a Internet de ese modo).
Actualmente, la política de Sony respecto al pirateo le deja con las manos más
atadas, así que su solución es hacer que los juegos nuevos solo funcionen con
versiones de Firmware superiores a una concreta, obligando a los usuarios a
actualizar a un firmware con menos bugs para poder jugar a los juegos.
Para solucionarlo, el grupo de desarrolladores ha creado lo que se llama: Custom
Firmware, o emuladores de firmware. Para ello, el eboot carga un programa que te
deja elegir una versión de firmware para emular, así, de cara al exterior y a la
consola la versión que ejecuta es la del firmware seleccionado (emulando todas sus
funcionalidades y añadidos) pero corriendo en realidad sobre la 1.50, lo cual
permite la ejecución de código casero.
Actualmente, las últimas versiones cuentan con sistemas de menús dentro del
propio menú para seleccionar extras y cargar programas sin tener que reiniciar la
consola
Figura : Programa DevHook para ejecución
Figura: Botón de carga de DevHook en el
de custom firmware
menu de PSP
14
HOMEBREWS
Se suele denominar homebrew a las aplicaciones informáticas realizadas por
aficionados para plataformas de videojuegos propietarias. En otras palabras,
plataformas de videojuegos que no son típicamente programables por usuarios o
usan sistemas de almacenamiento propietarios.
Podemos encontrar diferentes tipos de homebrews dependiendo de la finalidad que
tenga. Así pues podemos tener:
Aplicaciones generales
Ad Hoc Messenger 2.0: recibir y enviar mensajes
sin Internet Wi-Fi, solo mediante Ad-Hoc.
HM Lua Player 5.0: permite
ejecutar juegos en
lua.
PspSpoof 1.1: permite ejecutar aplicaciones o juegos homebrew que necesiten un
Firmware superior sin necesidad de actualizarlo.
PSP-Maps v0.6: muy parecido a google maps que
permite ver mapas de todo el mundo.
PspDos 0.1: permite traer ms-dos de Windows a la consola para poder ejecutar
juegos o programas de MSDOS.
15
Windows Vista Lua v2: una Shell para psp con el
aspecto de Windows vista, permite explorar la
Memory Stick, activar el USB, jugar a juegos, etc.
Emulación
PSPUAE 0.71: emulador de Commodore Amiga.
RacePSP: emulador de los sistemas portátiles de
SNK NeoGeo Pocket y NeoGeo Pocket Color.
PSPTHOM
v1.2.0:
emulador
computadora
“Thomson T07”.
Juegos: CSPortable 0.75, Luigi World v.1, space 0.1, Mario Kart PSP v1.0, Kitten
Canon, Zelda Alpha 2, etc.
Aplicaciones multimedia
16
VisMP3 v0.1.2: permite reproducir MP3 y a la vez
pone
a
nuestro
alcance
un
entorno
gráfico
agradable.
DIR to XML Tool v.1.0.2: pasar nuestros archivos MP3 a RSS/XML, lo que
posibilita escuchar nuestras canciones del PC en nuestra PSP a través del sistema
WiFi.
PSPRadio v0.37: cliente de streaming de radio por
Internet.
Time Baby v12h: realiza la función de despertador,
que dispone de soporte MP3.
Aplicaciones customizables
NervOS v1.6: sustituye al XMB original.
Wallpaper Changer v1.20: permite a los usuarios
fijar un fondo de pantalla para determinadas fechas
y
variar
aleatoriamente
algunos
recursos
sin
necesidad de escribir la Flash.
17
Firmwares
RS
PsarDumper
v3.2:
permite
poder
desencriptar y descomprimir directamente los
archivos del firmware.
Time
Machine
Configurator
v2:
permite
configurar la Time Machine desde la PSP sin usar
el PC.
18
PROGRAMACIÓN EN PSP: LUA
Descripción
Lua
fue
creado
en
1993
por
Roberto
Ierusalimschy, Luiz Henrique de Figueiredo, I
Waldemar Celes.
-
de peso ligero: usa poca memoria, es fácil de implementar con una
estructura simple
-
reflexivo: permite analizar ,observar y modificar su estructura de alto nivel
-
imperativo: como casi todos los lenguajes actuales, declara una serie de
acciones que el programa debe ejecutar por orden paso a paso
-
Lenguaje script: lenguaje que puede ser escrito en un bloc de notas, no
requiere de compilación y normalmente ejecuta una programa o aplicación
de software simple
CARACTERÍSTICAS
Las variables no tienen tipo, solo los datos, q pueden ser: lógicos, enteros, coma
flotante, o cadenas de caracteres.
Lua solo posee una única estructura de datos: la tabla
La principal característica de Lua es que no ahonda dentro de un tipo concreto de
paradigma (Ej.: orientado a objetos) sino que se compone de una serie de
características generales muy poco restrictivas que permiten la implementación de
funciones, herencias, clases etc de forma relativamente simple mediante el uso de
las meta tablas.
19
Es un lenguaje ligero, pensado para ser simple y, al mismo tiempo y debido a eso,
muy flexible y capaz de extenderse mucho más de lo que podría parecer en una
primera aproximación.
Su propósito de uso es como extensión de otro programa, o como script, y es
suficientemente pequeño para caber en una amplia variedad de aplicaciones
Es bastante utilizado en juegos por su flexibilidad para añadir pequeños scripts de
apoyo o de extras a un juego concreto; o como en este caso, para crear
videojuegos.
PRÁCTICA: JUEGO EN LUA FUNCIONANDO EN PSP
A continuación describiremos el código de nuestro juego que ejecutamos en PSP. El
juego se trata de esquivar bloques enemigos que se dedican a rebotar por la
pantalla, aguantando el mayor tiempo posible.
Figura : Captura del joc en moviment
Figura: Captura de la pantalla de final de joc
Para empezar el lenguaje LUA no requiere el uso (de base) de librerías adicionales,
así que empezamos directamente a escribir el código.
azul = Color.new(0,0,255)
verde = Color.new(0,255,0)
blanco = Color.new(255,255,255)
Definimos tres colores que usaremos para el bloque del jugador, los bloques
enemigos y el texto.
player = Image.createEmpty(32,32)
20
player:clear(azul)
block = Image.createEmpty(32,32)
block:clear(verde)
Definimos el jugador como una imagen vacía de 32x32 y la vaciamos pintándola de
azul. Lo mismo para los bloques enemigos en verde
Player = { x=30, y=100}
playerHeight = 32
playerWidth = 32
Aquí podemos observar una de las características mas curiosas de LUA: definimos
una variable Player y le asignamos propiedades de estructura: de esta forma dentro
de Player tenemos “x” e “y” que nos definen la posición del jugador. Esta estructura
no necesita indicar el tipo de variable que contiene, puede tener tanto valores como
texto y la cantidad que deseemos, solo hace falta ir añadiéndolos a continuación y
el lenguaje lo interpreta automáticamente. Definimos altura y anchura del jugador
para poder referenciarla luego.
Block = {}
Block[1]=
{x=100,y=80,
height=block:height(),
width
=
block:width(),k=3,h=-2 }
Block[2]= {x=300,y=30, height=block:height(), width = block:width(),k=1,h=-2 }
Block[3]= {x=200,y=58, height=block:height(), width = block:width(),k=2,h=2 }
Aquí definimos un vector de estructuras. La cantidad de elementos la vamos
actualizando según nos interesa añadir mas. Creamos los bloques enemigos de un
modo distinto a como hemos creado Player pero en esencia contiene la misma
información. Las variables “k” i “h” indicaran la velocidad horizontal y vertical
respectivamente de cada bloque.
function movePlayer()
21
pad=Controls.read()
if pad:left() then
Player.x = Player.x -2
end
if pad:right() then
Player.x = Player.x +2
end
if pad:up() then
Player.y = Player.y -2
end
if pad:down() then
Player.y = Player.y +2
end
end
Después de definir las variables definiremos las funciones del programa. Como LUA
carece de programa principal (main) en realidad no importa el orden en que se
escriba el programa, pero eso si, es importante haber definido las funciones antes
de llamarlas claro. En nuestro programa incluimos funciones para comprobar
colisiones y mover los bloques tanto del jugador como de los bloques enemigos.
La función movePlayer controla el movimiento del bloque del jugador. Esta pensado
para leer la entrada del teclado (o de la psp) y reaccionar en consecuencia. La
velocidad de desplazamiento se ha ajustado para que sea competitivo. Vemos que
la función no contiene corchetes que la delimiten, sino solamente la palabra
reservada “end” que indica el fin de la función. Eso ocurre también con la condición
“if” cuya estructura se asemeja a la de Visual Basic con la combinación “if X then”.
La relación entre la función pad y el input la hace el programa que lo ejecuta (en
nuestro caso, el luaplayer)
22
function moveBlock (bloc)
bloc.x = bloc.x + bloc.k
bloc.y = bloc.y + bloc.h
end
La función moveBlock sencillamente desplaza los bloques enemigos una distancia
igual a su velocidad. Vemos como actualiza la variable posición.
function collisionWallsBlockCheck (obj)
if(obj.x + playerWidth < 35) or
(obj.x + playerWidth > 475) then
obj.k= -(obj.k)
end
if(obj.y + playerHeight < 35) or
(obj.y + playerHeight > 268)
then
obj.h= -(obj.h)
end
end
La función collisionWallsBlockCheck comprueba si los bloques enemigos llegan al
final de la pantalla y, en ese caso, les hace rebotar en la dirección opuesta. Los
limites de la pantalla se han descubierto por el método del prueba-error, aunque
nos consta que existen librerías que tienen implementada una función de
identificación de estos.
function collisionWallsCheck (obj)
if(obj.x + playerWidth < 35) or
23
(obj.x + playerWidth > 475) or
(obj.y + playerHeight < 35) or
(obj.y + playerHeight > 268)
then
obj.x=oldx
obj.y=oldy
end
end
Esta es la misma función para el caso del jugador. Sencillamente actualiza la
posición con la misma que tenia lo que consigue que se mantenga estático.
function collisionCheck(object1,object)
if(object1.x + playerWidth > object.x) and (Player.x <
object.x +
playerWidth) and
(object1.y + playerHeight > object.y) and (Player.y <
object.y +
playerHeight) then
return -1
else
return 0
end
end
Esta función comprueba si el jugador colisiona con alguno de los otros bloques. Vale
la pena destacar que como LUA no define tipo de función, la posibilidad de retornar
un valor a la salida es opcional y no hace falta declararlo. En este caso comprueba
24
los cuatro lados del jugador con el bloque pasado por referencia y devuelve –1 en
caso de colisión lo que nos marcaría el final de la partida.
function collisionBlockCheck(object1,object2)
if(object1.x + object1.width > object2.x) and (object1.x <
object2.x +
object2.width) and
(object1.y + object1.height > object2.y) and (object1.y <
object2.y +
object2.height) then
object1.h = -(object1.h)
object1.k = -(object1.k)
object2.k = -(object2.k)
object2.h = -(object2.h)
end
end
Finalmente, la función que controlará la colisión entre bloques enemigos que hará
que reboten en la dirección opuesta a la que iban. Destacar que los objetos pasados
por referencia no se indican, con lo que no se comprueba que realmente se esté
pasando algo con lo que se pueda trabajar. Dado que LUA carece de compilador el
programa sencillamente funcionará o no funcionará, pero siempre podrá ser
ejecutable. El luaplayer nos indica en una línea de texto de MS-DOS el error y la
línea donde se ha producido.
counter = Timer.new()
counter:start()
25
tiempo =0
result=true
Timer es una función que cuenta el tiempo en milisegundos que ha pasado desde el
inicio del programa. Lo que hacemos es mostrar ese tiempo por pantalla a modo de
puntuación.
while (result==true) do
currentTime=counter:time()
oldx = Player.x
oldy = Player.y
screen:clear()
screen:print(10,10,"Tiempo de juego: "..currentTime,blanco)
Empieza el bucle de juego del programa. Este bucle ejecuta lo que es propiamente
el juego y se repite hasta que se cumplen las condiciones de derrota. Para empezar
se guarda el valor de la posición actual del jugador y se limpia la pantalla con la
propiedad “clear”. Luego lo primero que hacemos es actualizar el tiempo de juego
mostrándolo por pantalla.
moveBlock(Block[1])
moveBlock(Block[2])
moveBlock(Block[3])
movePlayer()
Desplaza los bloques y comprueba si el jugador esta presionando el pad.
26
collisionWallsCheck(Player)
collisionWallsBlockCheck(Block[1])
collisionWallsBlockCheck(Block[2])
collisionWallsBlockCheck(Block[3])
Comprueba las colisiones de cada bloque con las paredes.
if(collisionCheck(Player,Block[1]) <= -1)or
(collisionCheck(Player,Block[2]) <= -1) or
(collisionCheck(Player,Block[3]) <=-1)then
result=false
end
Comprueba si el jugador está en colisión con alguno de los tres bloques, en cuyo
caso cambia “result” que es la variable que comprueba el bucle para decidir cuando
sale de él y finaliza el juego.
collisionBlockCheck(Block[1],Block[2])
collisionBlockCheck(Block[1],Block[3])
collisionBlockCheck(Block[2],Block[3])
Comprueba la colisiones entre cada uno de los bloques.
screen:blit(Player.x, Player.y, player)
for a = 1,3 do
screen:blit(Block[a].x, Block[a].y,block)
end
La función screen:blit pinta los elementos por pantalla. Vemos que usamos una
iteración “for” para mostrar los bloques dado que los tenemos en un vector.
27
screen.waitVblankStart()
screen.flip()
end
La primera función hace una pausa. La segunda muestra por pantalla las acciones
realizadas anteriormente, y por tanto actualiza cada bucle la imagen para crear el
movimiento. Con esto termina el bucle principal.
counter:stop()
while true do
screen:clear()
screen:print(200,100,"FIN DE LA PARTIDA",blanco)
screen: print(200, 120, "Puntuacion:"..currentTime,blanco)
screen.waitVblankStart()
screen.flip()
pad=Controls.read()
if pad:start() then break end
end
Esta es la parte final del programa al que solo se accede saliendo del bucle
principal, esto es, cuando pierdes. Detiene el contador, vacía la pantalla y muestra
la frase “FIN DE LA PARTIDA” junto con tu puntuación o tiempo. Esa pantalla esta
dentro de un bucle porque se mantiene hasta que el jugador presiona la tecla
“start” de la PSP.
28
JUEGO EN PSP
El juego requiere de un programa para ejecutarlo llamado “LUA player”.
Evidentemente como programa que es, solo es ejecutable en las versiones del
firmware que lo permitan. El programa contiene una lista de todos los elementos
que reconoce como archivos ejecutables (extensión *.lua)
Figura X: Dos capturas del LUA player en funcionamiento en la PSP
Captura del juego funcionando en PSP
29
COMPARATIVA Y CONCLUSIONES
Aun con todo lo que se ha conseguido, las capacidades que puede ofrecer la
ejecución “no legal” de código casero son todavía muy limitadas. Las capacidades
gráficas y de rendimiento de un sistema ejecutado desde UMD o desde memory
stick legalmente.
La diferencia principal es que el sistema “signed” trabaja en Kernel mode, esto es,
utilizando todas las capacidades que ofrece la consola; mientras que muchos de los
sistemas caseros no, con lo que cuentan con unas capacidades más limitadas.
El mayor problema a la hora de hacer software para la PSP, es la gran diversidad
de público con gran diversidad de firmwares y tipos de exploit. Como cada grupo de
desarrollo ha trabajado por su cuenta, existen muchas combinaciones de
firmwares-exploit: hay quien la tiene en la 1.50 con el downgrade, pero si algo falla
la consola puede brickearse, y eso asusta a muchos usuarios. Hay quien la posee en versiones posteriores usando solo una capacidad menor
debido a las limitadas capacidades del exploit encontrado; además Sony trabaja
rápido para tapar todos los posibles parches sacando actualizaciones, con lo que el
tipo de usuario cada vez se va diversificando más.
El objetivo del desarrollador de software es que llegue al mayor número de usuarios
posible, y eso a veces, le obliga a limitar las funcionalidades de su código.
La realidad por eso, es que la PSP como centro multimedia esta muy limitada por
las protecciones que impone Sony. Hoy en día es difícil imaginarse que alguien
desaproveche todas las opciones que podría ofrecerle su sistema limitándose a lo
que la compañía decide ofrecer.
No obstante, existe una cara negativa de todo eso, y es que la capacidad para
acceder al modo Kernel, permite ejecutar código de mayor capacidad de memoria.
Actualmente la venta de juegos de PSP ha disminuido en gran medida, y Sony sabe
que la mayor parte de usuarios aprovecha el filón de ejecutar código para ejecutar
“copias de seguridad” o mejor dicho “copias pirata”. Es una tentación muy fuerte
sobretodo si tenemos en cuenta el precio que alcanza un videojuego en el mercado.
30
BIBLIOGRAFIA
Conseguido kernel mode en PSP : http://tec.fresqui.com/kernel-mode-en-psp2-50-y-2-60
Exploits:
http://es.wikipedia.org/wiki/Exploit
Swaploit info:
http://www.afterdawn.com/glossary/terms/swaploit.cfm
Kxploit info: http://www.afterdawn.com/glossary/terms/kxploit.cfm
Firmware exploits:
http://wiki.scummvm.org/index.php/PlayStation_Portable
Buffer overflow:
http://www.pspain.com/foro/showthread.php?t=8584
http://www.elotrolado.net/hilo_descubierto-exploit-para-el-firmware-2-0-de-lapsp-re-actualizado_455619
Downgrade info:
http://www.todopsp.com/foros/showthread.php?t=48813
Custom firmware info:
http://www.todopsp.com/foros/showthread.php?t=34159
31