Os dejo un cutre-tutorial que he empezado sobre scripting linux practico para GP2x, para los que les de repelus meterse en ello. Mas que nada porque creo k algun programa k nos de problemas comentados en el tutorial pueden solventarse por uno mismo
Lo ire ampliando poco a poco
EDIT: tenia aun sin arrglar lo de los exec :rolleyes: y a ver si saco un poco de tiempo para ampliarlo con alguna "magia" pa la GP2x :D
TUTORIAL BASICO SCRIPTING PRACTICO para Linux GP2x
Bueno, a ver si esto le resulta util a alguien. Sobretodo esta orientado a los no-linuxeros, o los poco-linuxeros ;)
Os presento un pequeño tutorial para poder "interactuar" un poco mas con la GP2x, se trata de como realizar "scripts" que nos faciliten un poco la vida con la consola, incluso solucionar "problemas" con algunos programas y/o juegos. Los "scripts" son ficheros de texto con ordenes para procesar automaticamente, como si los teclearamos nosotros. Efectivamente, es la version Unix de los ficheros .BAT del DOS...
A nivel de ejecutables, la consola conoce .GPE (ejecutable de juego) y .GPU (utilidad) accesibles cada uno desde su menu correspondiente. Ambos son igual de ejecutables, sean binario o script. La diferencia es que con esto los separamos en dos "clases" y la consola solo ve el adecuado a cada menu. Por tanto, navegando con el lanzador de juegos, solo veremos .GPE, y por el de utilidades, solo veremos .GPU. A nivel practico, podrian ser todos GPE o GPU que los podriamos lanzar siempre desde el menu correspondiente de la consola.
Me voy a abstraer de todo el rollo de los permisos de Linux de ejecucion, propietarios, etc que no viene al caso...
1-Scripts y binarios: Matrimonio de conveniencia
Que diferencia hay entre un ejecutable binario y un ejecutable script? Lo mas evidente, es sobretodo y por regla general, el tamaño... Si habeis mirado el 2xQuake, habreis visto un QUAKEBIN.GPE y un QLAUNCH.GPE, el primero mega y pico y el segundo apenas 1 kilobyte... Si, el QLAUNCH.GPE es un script que lanza el QUAKEBIN.GPE y despues nos devuelve al menu... Podeis abrirlo con el editor de texto que mas rabia os de para verlo (Pero para editarlo, ojo!!! vereis algo mas abajo)
Porque complicarnos tanto? Porque el ejecutable del QUAKE no puede relanzar el menu de la GP2x por si solo, no es "GP2x friendly". Con esto digo que un ejecutable pensado totalmente para GP2x, deberia ser capaz de relanzar el menu de la consola, cosa que un port directo o un proyecto a medio desarrollar, no hara por si solo nunca si no lo preparamos para ello, sea a nivel de codigo fuente, o con ayuda de un script.
No "adaptar" supondra que al salir del programa, se queda la consola "frita" y tendremos que apagar y encenderla. Para haceros una idea, es como si sales de un juego en MS-DOS, no tienes teclado y se queda el sistema esperando que le teclees ordenes... Tambien mencionar que si se queda el ultimo frame del juego, es porque ha petado y/o no se ha limpiado el frame buffer (pontalla grafica) y por tanto no hay proceso que toque la matriz de la pantalla, nos da la sensacion de que se ha "colgado" cuando realmente hay un sistema operativo por debajo esperando que le metamos ordenes por un teclado (ejem).
Aqui es donde nos ayudan los scripts... ejecutando el menu segun la aplicacion (juego, utilidad) se cierre, casque, muera, o salga.
0.1-Posible editor para Windows:
Para editar los scripts, desde Linux o MacOsX no tendreis problema, ya que son Unix ambos a la hora de tratar ficheros de texto ASCII, pero en PC tenemos un problema... Los saltos de linea son distintos... Solucion, os adjunto en ZIP el pico, un editor intuitivo de Unix, compilado para consola Windows. Es facilito, podeis asociar las extensiones GPE y GPU al pico en windows, o sino ejecutarlo y dentro pulsais CONTROL+R (abajo en la ayuda pone READ FILE) y CONTROL+T para navegar por los ficheros (El ".." es ir un directorio hacia arriba) e ir a la SD directamente. Una vez seleccionado el fichero, lo editais tan campantes, cuando habeis acabado pulsais CTRL+X y dais a Y para grabar los cambios. CONTROL+K corta una linea (o varias seguidas si dais repetidamente a CTRL+K) y CTRL+U pega la/las linea/lineas. Espero que os funcione bien. Linux puede usar este u otros editores, y el terminal de MacOSx tiene tambien el pico ^^
1.0-Scripts basicos:
1.1-Caso sencillo: Ejecutar aplicacion, volver al menu...
Tenemos por ejemplo el Pong de Andrew Williams, un ejecutable binario llamado PONG.GPE que al darle al start para salir, "cuelga" la consola.
Si os fijais, hay un ejecutable script PONGLAUNCHER.GPU (si, tendreis que lanzarlo desde el menu de Utilidades) que lanza el juego y al dar a start sale al menu... Veamos como funciona esa "magia"
-----------------
#!/bin/sh
#
# Change the parameter below for a harder or easier game
# 1=very easy; 8=very hard
#
./pong.gpe 5
#
#Re-load the GP2X menu on exit
cd /usr/gp2x
./gp2xmenu
-----------------
Asusta??? Vamos a resumirlo al caso que nos ocupa: lanzar y volver al menu:
-----------------
#!/bin/sh
#
./pong.gpe
#Re-load the GP2X menu on exit
cd /usr/gp2x
./gp2xmenu
-----------------
Que tambien funcionara sin problemas. Veamos que hace:
Las lineas que empiezan por # son comentarios, son ignorados, podemos prescindir de ellas, si bien la primera, #!/bin/sh, suele decir al sistema con que shell hay que ejecutarla (Si, en MS-DOS, de serie solo teniais el COMMAND.COM... En Linux/Unix hay muchas shells: sh, bash csh etc..., cada una con su propia sintaxis)
El ./pong.gpe lanza el ejecutable binario, el ./ es porque el "." significa "el propio directorio/carpeta en el que estas" por tanto ./pong.gpe es "ejecuta el binario pong.gpe en el mismo directorio/carpeta en el que estas ahora". Siempre se asume el directorio local, el mismo donde se aloja el script.
El cd /usr/gp2x es un cambiar directorio/carpeta (Usare directorio a partir de ahora) a donde estan los ejecutables de los menus de la consola (Si, eso esta en la memoria NAND)
El ./gp2xmenu es para lanzar el menu de la consola (Volvemos a nuestro menu, oeeee oeeeee!!!)
Veis que la cosa entonces se resume a:
./pong.gpe Lanza el ejecutable en el mismo directorio del script
cd /usr/gp2x Nos desplaza al directorio de los menus de la consola
exec ./gp2xmenu Lanza el menu
Facil? Espero que si ^^
1.2-Caso especial 1: Paso de parametros,
(lo que no puedes hacer desde el JoyPad de tu GP2x)
En el anterior habeis visto que se lanza un ejecutable, y para volver al menu lo relanzamos desde el script al salir del programa. Pero hemos trabajado sobre el script original simplificado... Al principio os habia puesto el original donde se pasa un numero para ajustar la velocidad del juego:
# Change the parameter below for a harder or easier game
# 1=very easy; 8=very hard
./pong.gpe 5
Por tanto, poniendo un numerito al final, del 1 al 8, cambiais la velocidad... es un parametro.
Cojamos otro de los proyectos existentes para verlo mas claro: El emulador de Sega Master System (Gracias Efegea por el trabajo que te has tomado)
Tenemos estos ficheros en el directorio (carpeta?) del emulador en la SD:
sms_dll : Ejecutable binario SIN la extension (no aparece en el lanzador de ejecutables)
smsplus2x.gpe: Script de lanzamiento del emulador
rom.sms: Una rom cualquiera del sistema emulado.
smsplus2x.gpe tiene este contenido:
-----------------
./sms_sdl rom.sms
cd /usr/gp2x/
/usr/gp2x/gp2xmenu
-----------------
Aqui se lanza el emulador sms_sdl y se le pasa de parametro la ROM del juego correspondiente. Despues hace el clasico ejecutado de vuelta del menu...
Por tanto, podeis duplicar el smsplus2x.gpe con distitos nombres, y poner en cada uno una ROM distinta, y tener varios lanzadores para cada ROM...
Asi podeis tener:
juego1.gpe
juego2,gpe
juego3.gpe, cambiando en cada gpe, el rom.sms con el juegox.sms correspondiente
Es una chapuza pero es la forma de tener mas de 1 rom sin tener que renombrarlas desde el PC...
Por ciero... os habeis dado cuenta??? sms_sdl .... falta algo... NO TIENE EXTENSION .GPE . Por tanto... No es visible en el lanzador de juegos ni utilidades de la consola, pero sigue siendo ejecutable desde los scripts
Es un buen sistema para ocultar los ejecutables que NECESITAN parametros (En este caso una ROM) o los que no vuelven al menu por si solo, dejando solo visible el script, anulando la posibilidad de lanzar el binario por accidente y bloquear la consola (y ahorrarnos el apagar y encender)
1.3-Caso especial 2: Rutas absolutas
En algunos casos podemos encontrarnos que por el motivo que sea, no se usa la forma de ejecutar "en el mismo directorio que el script", o que el script nos fuerce a instalar el programa en una ubicacion determinada (Raiz de la SD, dentro de una carpeta en la raiz que se debe llamar FULANITO y no otra cosa, etc...). Esto es porque esta hecho con rutas absolutas...
Ejemplo: 2xQuake1
Script: QLAUNCH.GPE (Script resumido, luego os explicare porque)
-----------------
cd /mnt/sd/quake/
/mnt/sd/quake/quake.gpe
cd /usr/gp2x/
exec /usr/gp2x/gp2xmenu
-----------------
Por partes... Linux no tiene "letras de unidad", tiene un sistema de archivos unico llamado "/" y de hay cuelga todo lo demas... Cualquier otra particion/disco, se cuelga de un subdirectorio. Por conveniencia es en /mnt donde van a estar esos directorios del que se accede a cada otro disco/particion. Por tanto, la raiz de la SD, esta en /mnt/sd/. En ese directorio esta todo el contenido de la SD...
Como veis, este script nos obliga a instalar el juego EN LA RAIZ DE LA SD! Mal no esta, pero quien es un poco quisquilloso querra cambiarlo al directorio juegos y ahi dentro el directorio quake... no? :) Asi no petamos de directorios la raiz de una SD grandota...
Naaa, es facil... Supongamos el directorio JUEGOS en la raiz de la SD, y dentro el directorio QUAKE... Queda tal que asi:
-----------------
cd /mnt/sd/juegos/quake/
/mnt/sd/juegos/quake/quake.gpe
cd /usr/gp2x/
exec /usr/gp2x/gp2xmenu
-----------------
Que se podria usar el caso 1.1?? Podria ser, pero el script viene tal que asi, lo mismo nos pasa con el rockdogert o el sopwith_camel, que nos obliga a instalarlo en la raiz de la SD
Podemos corregir las rutas (forzar otra ubicacion) o reducir el script al caso primero, el sencillo
-----------------
./quake.gpe
cd /usr/gp2x/
exec /usr/gp2x/gp2xmenu
-----------------
:)
El quake da mucho jugo con esto de los scripts... es un ejecutable enteramente parametrizable...
-game MOD Nos permite cargar un MOD del quake (Gente se curro en su dia
expansiones y/o juegos nuevos)
-nosound No lo he probado en la GP pero en el PC anulaba el audio
(Mas F/PS??)
etc...
El interesante es el -game MOD, a buscar MODs single-player del quake!!!
Otra opcion es renombrar el ejecutable BINARIO a quake (sin extension) y editar el script:
-----------------
cd /mnt/sd/juegos/quake/
/mnt/sd/juegos/quake/quake
cd /usr/gp2x
exec /usr/gp2x/gp2xmenu
-----------------
Por ejemplo.... Asi ocultais el binario que no llega al menu por si mismo...
1.4-La verdad esta ahi...
Bueno, la verdad es que os he mentido un poco... Vereis:
Script real del 2xQuake
-----------------
mount /mnt/sd -o remount,sync
cd /mnt/sd/quake/
/mnt/sd/quake/quake.gpe
mount /mnt/sd -o remount,async
cd /usr/gp2x/
exec /usr/gp2x/gp2xmenu
-----------------
Jarl!!!! y esas dos lineas "MOUNT"???
Script real del SMS emu de Efegea:
-----------------
mount -o remount,sync /mnt/sd
sync
./sms_sdl rom.sms
cd /usr/gp2x/
sync
exec /usr/gp2x/gp2xmenu
-----------------
Mas "MOUNT" y.... "SYNC"???? Esto que es? bueno.. Por partes..
MOUNT es la orden que se usa para "montar" los discos o particiones auxiliares a un directorio del sistema de archivos. Los parametros a groso modo que se observan en estos usos concretos son remount y sync. son para remontar la SD (/mnt/sd) en modo sincrono (Cada escritura se escribe IPSO FACTO, no se cachea en un buffer de memoria para grabar despues). el remount async nos deja la SD como estaba... cacheable la escritura (La verdad es que ahorra intentos de escritura, al grabar varios cambios de golpe)
SYNC es una orden que se usa para grabar IPSO FACTO los buffers de escritura de disco, en cada disco/particion. Esto es, sincronizar el contenido fisico con el que deberia tener (Pueden haber datos pendientes de escritura al usar modo asincrono)
Nesitemos o no esas ordenes, estan ahi, y biene bien que sepamos que existen y que hacen... Asi sabremos si sobran, hay que dejarlas o hay que tocarlas... ;)
1.5- RESUMEN SCRIPT BASICO
Ahora sabemos:
-Poner comentarios en los scripts ( #Esto es un comentario )
-Lanzar un binario y volver al menu, cuando este programa no deberia poder hacerlo, gracias a scripts
-Lanzar un binario con parametros
-Multiples scripts para multiples parametros (Roms sin menu selector, Mods de quake, parametros numericos, etc)
-Entender rutas absolutas (Ubicacion de la SD en el sistema de archivos Linux, /mnt/sd) y cambios de directorio ( cd directorio o cd /dir1/dir2 )
-No asustarnos con ordenes que aun no conocemos (Mount, y sync en este caso)
En el siguiente capitulo haremos algunas magias con scripts ;) Espero que este os haya ayudado a solventar algun problemita que os haya dado algun ejecutable de la GP2x ;)
Citar
Iniciado por thanatos
Marcadores