Hola!, ¿Qué tal?
Para muchos puede ser brujería esto de las WSL y como nos ayudan a compilar una ROM de GBA enpocos muchos segundos desde una PC Windows sin necesidad de una partición en Linux (donde lo anterior tendría más sentido). Aquí intentaré aclararlo un poco, aunque no sea la intención del tutorial.
Dejando en claro el por qué estamos compilando en Linux y no en Windows como SO nativo, partimos a exponer qué es realmente la WSL (Windows Subsystem Linux, o la terminal de Linux en Windows para los amigos)
¡PERO BUENO JUANJO, que siempre te vas por las ramas y hablas hasta por los codos!!!
Si tienes algo de sentido común, te habrás saltado toda la información que solté y quieres que te resume los puntos importantes. ¡Enhorabuena yo también pienso como tú! Puedes invitarme a una cerveza cuando quieras.
EN RESUMEN:
Actualización a la WSL2:
Requisitos:
Si no tienes una versión previa de la WSL (como la WSL1) puedes instalarla directamente en PowerShell o el símbolo del sistema de Windows del administrador y, a continuación, reinicia la máquina:
Si quieres saber que versiones de la WSL están instaladas, usa:
Antes de instalar WSL 2, se debe habilitar la característica opcional Plataforma de máquina virtual. En el PowerShell ejecutar:
Ahora vamos a ver que tipo de sistema usamos, para esto ejecutamos:
(Si tu PC está en inglés u otro idioma, usa en cambio "System Type" o comos ea en tu idioma)
Yo obtuve:
Por lo que debería instalar Paquete de actualización del kernel de Linux en WSL 2 para máquinas x64
Si, en cambio, tienes ARM64, descarga el paquete ARM64.
Ejecuta el paquete de actualización que descargaste en el paso anterior. (Doble clic para ejecutarlo. Pueden pedirte, pedirán permisos elevados. Selecciona "Sí" para aprobar esta instalación).
Definimos WSL2 como predeterminada:
Para actualizar de WSL 1 a WSL 2 en distribuciones de Linux instaladas previamente, vamos a usar el comando
, reemplazando <distro name> por el nombre de la distribución de Linux que desea actualizar. Por ejemplo,
.
Si no has instalado la distribución de Ubuntu, simplemente búscala en la tienda de Windows.
¡Si has seguido los pasos correctamente, entonces habrás instalado/actualizado la WSL2 correctamente!
INSTALACIÓN DE POKEEMERALD:
Un momento, Juanjo, yo ya he instado Pokeemerald ¿Por qué debería yo instalarlo nuevamente? A lo que te diré:
Si usabas WSL 1 tenía entonces mucho sentido que tuvieras tus archivos del ROM en una carpeta de Windows y su instalación seguiría los pasos de instalación para Windows. Sin embargo, si hacemos eso con WSL 2 la compilación sería lentísima porque estaríamos compilando algo dentro de Windows. Aquí asumimos que estamos en UNA VERSIÓN NATIVA DE LINUX.
Por lo tanto, lo más limpio sería instalar de nuevo Pokeemerald (y tu proyecto actual). Sin embargo, como todo está en GitHub no es mayor problema. Siempre y cuando tengas tu proyecto bien actualizado y al tope de commits no será un problema clonar de nuevo el repositorio y continuarlo.
Para esto seguiremos las instrucciones de https://github.com/pret/pokeemerald/blob/master/INSTALL.md para Linux. ¡IMPORTANTE! Ahora estamos en Linux, por lo que seguiremos las instrucciones como si fuera de Linux e ignoraremos lo de Windows. Esto es muy importante.
Una vez tenemos el pokeemerald (y cuanto proyecto quieras) instalado, vamos a instalar algunos paquetes necesarios que nos servirán para el debug del juego. (Aquí realmente comienza este tutorial)
Instalar devkitARM
Edit:
Para instalar el devkitpro, ahora será necesario ejecutar el siguiente comando en la carpeta de descargas
Esto descargará un script que se encargará de instalarlo. Para ejecutar el script escribimos:
Y ya podremos continuar con la instalación de dev apra GBA normalmente:
El último comando pedirá que selecciones los paquetes a instalar. Solo tiene que pulsar Enter para instalar todos ellos, seguido de escribir «Y» para proceder a la instalación.
Ejecutamos el siguiente comando para establecer las variables de entorno relacionadas con devkitPro (alternativamente, cierra y vuelva a abrir WSL):
Haciendo estos pasos, yo tuve un problema en el que tuve que crear un enlace simbólico para devkitPro. Para arreglarlo, desde /opt ejecuté sudo ln -s devkitpro/ devkitPro:
Si todo va correcto, deberíamos ahora compilar el juego usando el compilador moderno. ¡Lo cual es genial!
¡Ya lo difícil ha terminado!
DINFO=1 activa la información de depuración
modern construye con un compilador más moderno, permitiendo más optimizaciones y características del lenguaje.
-j$(nproc) calcula cuántos procesadores tiene el PC y construye utilizando todos ellos. Esto acelerará en gran medida el proceso de build.
CONFIGURAR EL VSCODE PARA WSL2
Ahora sí que podemos decir que este tutorial realmente comienza XD (me he basado mucho en este tutorial https://github.com/walkingeyerobot/pokeemerald/wiki/wsl2-and-vscode-setup)
Créditos a walkingeyerobot.
Aquí dejé un breakpoint dentro de CB2_MainMenu() cuando hay un archivo guardado antes de cargar el menú:
BONUS: Configuración de Porymap
Hasta ahora hemos configurado el Visual Studio Code para poder compilar, ejecutar y debuggear.
Ahora configuraremos Porymap. En el tutorial de walkingeyerobot nos dicen que
Seguiremos con su tutorial y luego yo les explico a usar el X11
Esperen una actualización con más trucos
Juanjo
Para muchos puede ser brujería esto de las WSL y como nos ayudan a compilar una ROM de GBA en
A pesar de que estamos hablando de lenguaje C, el cual es agnóstico al sistema operativo, ejecutar un programa en Linux se siente más natural que en Windows:
Fuente: https://www.quora.com/What-are-the-advantages-of-C-development-in-Linux-over-Windows
- Linux es un sistema operativo hecho por desarrolladores para desarrolladores, en el sentido más amplio del término. A través del shell, las herramientas se integran entre sí para el desarrollo de una manera que no lo hacen en otros SO.
- Los IDEs en Windows (MSVS) suelen estar restringidos a «solo desarrollo de software». Lo mismo con XCode en Mac. Tal vez tengas algunas herramientas de repo o SCM, pero en su mayor parte se trata de construir un ejecutable, no de construir un producto de software.
- Muchos programas tienen comandos de línea (command line arguments) o CLA para los amigos, son los argumentos que se pasan al programa (main) cuando el sistema operativo (SO) lo llama. Si queremos pasar CLA superrápido en la terminal de Linux podemos ejecutar:
mientras que en Windows se deberían encontrar las opciones para CLA (y eso depende del IDE [entorno de desarrollo integrado], como por ejemplo Visual Studio Code). Esto resulta que la depuración en Linux sea más nativa y con mayor facilidad manual. Solo hay que escribir los argumentos en una línea y se pueden cambiar con facilidad en cada ejecución.Bash:
$ ./programa arg1 arg2 arg3 ... - Si queremos automatizar la ejecución de un montón de programas con CLA dependiendo de algunas condiciones de lógica o secuencias de ejecución. En Linux esto sería trivial (haciendo un programa wrapper en shell script, por ejemplo), mientras que en Windows sería un dolor de cabeza, además que elimina parte de los warnings explícitos que para un usuario novato serían útiles.
- Luego vienen temas como las bifurcaciones (forks), es decir, programas con procesos que se bifurcan para crear procesos hijos. Técnicamente, Windows no está hecho para eso y lo poco que hay es HORRIBLE. Mientras que en Linux es bastante robusto con el sistema fork().
- En Linux, todo el sistema operativo es la cadena de herramientas. Como parte de tu proceso de construcción, compruebas los cambios en los activos como el audio o los gráficos y los actualizas, en consecuencia, puedes reformatear los activos (como lo hacemos cada vez que compilamos desde el código en De-compilación).
- En Linux también es probable que tengas el código fuente de todas las bibliotecas con las que se vincula tu aplicación. Es fácil localizar errores que no están en tu código.
- Hay muchas más opciones de librerías en Linux. ¿Necesitas una librería muy específica? Hay como 100 de ellas. Todas gratuitas y con código fuente. ¿Par Hacking Decomp? Habrá una o dos, y TODAS en Linux.
Fuente: https://www.quora.com/What-are-the-advantages-of-C-development-in-Linux-over-Windows
Dejando en claro el por qué estamos compilando en Linux y no en Windows como SO nativo, partimos a exponer qué es realmente la WSL (Windows Subsystem Linux, o la terminal de Linux en Windows para los amigos)
WSL 1
La WSL 1 que todos conocemos simula ser un kernel de Linux (sin contener código de Linux propiamente dicho), lo que nos permita usar la shell y ejecutar comandos nativos de Linux, permitiéndonos muchas de las ventajas que no teníamos en Windows.
Sin embargo, la WSL 1 no es capaz de correr todo el software Linux, como los binarios de 32 bits o esos que requieren servicios específicos del núcleo Linux sin implementar en WSL. Dado que no existe un núcleo Linux "real" en WSL, tampoco se han lanzado las cabeceras del kernel, lo que impide construir controladores y otros programas que dependen del kernel (como drivers, o contenedores como Docker).
Algo que tal vez no muchos sabían es que se pueden lanzar aplicaciones gráficas desde la WSL usando un servidor X11 (Algo que explicaré más adelante y que nos servirá para el Porymap)
WSL 2
La versión 2 está muy altamente optimizada e incluye un núcleo Linux real, lo que nos da muchísimo más poder que con la WSL 1, aumentando su poder de compilación y de drivers.
Sin embargo, esto hace que tarde muchísimo tiempo leyendo archivos que no estén en las carpetas nativas de Linux. Al igual que aumenta el tiempo de acceso a archivos dentro de Linux para aplicaciones que se ejecuten en Windows.
La siguiente tabla puede explicar muy bien lo que quiero decir.
Una experiencia de VM tradicional puede presentar un arranque lento, aislamiento y un consumo excesivo de recursos, además de exigir tiempo para su administración. WSL 2 no tiene estos atributos.
WSL 2 ofrece las ventajas de WSL 1, incluida una integración perfecta entre Windows y Linux, tiempos de arranque más breves y una superficie de recursos pequeña. Además, no requiere ninguna configuración ni administración de las VM. Aunque WSL 2 usa una VM, se administra y se ejecuta en segundo plano, lo que te permite disfrutar de la misma experiencia de usuario que WSL 1.
Fuente: https://docs.microsoft.com/es-es/windows/wsl/compare-versions
La WSL 1 que todos conocemos simula ser un kernel de Linux (sin contener código de Linux propiamente dicho), lo que nos permita usar la shell y ejecutar comandos nativos de Linux, permitiéndonos muchas de las ventajas que no teníamos en Windows.
Sin embargo, la WSL 1 no es capaz de correr todo el software Linux, como los binarios de 32 bits o esos que requieren servicios específicos del núcleo Linux sin implementar en WSL. Dado que no existe un núcleo Linux "real" en WSL, tampoco se han lanzado las cabeceras del kernel, lo que impide construir controladores y otros programas que dependen del kernel (como drivers, o contenedores como Docker).
Algo que tal vez no muchos sabían es que se pueden lanzar aplicaciones gráficas desde la WSL usando un servidor X11 (Algo que explicaré más adelante y que nos servirá para el Porymap)
WSL 2
La versión 2 está muy altamente optimizada e incluye un núcleo Linux real, lo que nos da muchísimo más poder que con la WSL 1, aumentando su poder de compilación y de drivers.
Sin embargo, esto hace que tarde muchísimo tiempo leyendo archivos que no estén en las carpetas nativas de Linux. Al igual que aumenta el tiempo de acceso a archivos dentro de Linux para aplicaciones que se ejecuten en Windows.
La siguiente tabla puede explicar muy bien lo que quiero decir.
| Característica | WSL 1 | WSL 2 |
|---|---|---|
| Integración entre Windows y Linux |  | |
| Tiempos de arranque rápidos | | |
| Huella de recurso pequeña en comparación con las máquinas virtuales tradicionales | | |
| Se ejecuta con las versiones actuales de VMWare y VirtualBox | | |
| VM administradas |  | |
| Kernel de Linux completo | | |
| Compatibilidad completa con las llamadas del sistema | | |
| Rendimiento entre sistemas de archivos del sistema operativo | | |
Una experiencia de VM tradicional puede presentar un arranque lento, aislamiento y un consumo excesivo de recursos, además de exigir tiempo para su administración. WSL 2 no tiene estos atributos.
WSL 2 ofrece las ventajas de WSL 1, incluida una integración perfecta entre Windows y Linux, tiempos de arranque más breves y una superficie de recursos pequeña. Además, no requiere ninguna configuración ni administración de las VM. Aunque WSL 2 usa una VM, se administra y se ejecuta en segundo plano, lo que te permite disfrutar de la misma experiencia de usuario que WSL 1.
Fuente: https://docs.microsoft.com/es-es/windows/wsl/compare-versions
¡PERO BUENO JUANJO, que siempre te vas por las ramas y hablas hasta por los codos!!!
Si tienes algo de sentido común, te habrás saltado toda la información que solté y quieres que te resume los puntos importantes. ¡Enhorabuena yo también pienso como tú! Puedes invitarme a una cerveza cuando quieras.
EN RESUMEN:
- Para compilar en lenguaje C es siempre mejor hacerlo de forma nativa en Linux, puesto que tienes más opciones nativas triviales y una mejor compatibilidad con drivers y librerías.
- El WSL 1 es un buen emulador de un kernel de Linux y se puede usar para trabajar en decompilación. Sin embargo, no es un kernel de Linux completo, no tiene compatibilidad completa con llamadas del sistema y no administra máquinas virtuales (VM).
- A pesar de esto, se puede utilizar el WSL1 en Windows para decompilación teniendo los repositorios dentro de Windows.
- El WSL 2 es un verdadero kernel de Linux altamente optimizado y completo, funciona con llamadas del sistema y administra máquinas virtuales; sin embargo, su rendimiento es terrible si tenemos que emplear archivos que vengan del otro sistema operativo. (Como abrir archivos que estén en Windows desde el WSL2 o viceversa).
- A pesar de esto. Si la empleamos bien podríamos tener una experiencia de decompilación brutal mucho más poderosa que con WSL 2, eso sí, si lo hacemos mal podríamos hacerlo incluso peor.
- Un incremento del rendimiento a la hora de compilar la ROM.
- Uso de librerías nativas en Linux como devKitpro que permitirían hacer debug en tiempo real usando breakpoints.
- Trabajar como si lo estuvieras haciendo directamente en Linux (al seguir los tutoriales no te preocuparías de que estás en Windows, sino que lo harías directamente para Linux, el cual tiene mayor soporte).
- Reducción de problemas de instalación y arbitrariedades de Windows.
- Mejora de experiencia de usuario en VSCode.
- Si no la configuramos bien, la compilación podría tardar mucho más que en la WSL1.
- Desconfiguración del Porymap (Anexo como resolverlo
) y una posible disminución del rendimiento en la interfaz de usuario (al ser una aplicación nativa de Windows). También anexo como lo resolveríamos. - Requiere un mayor nivel de conocimiento de Linux como sistema operativo (aunque si la tienes, entonces sería una ventaja).
Actualización a la WSL2:
Requisitos:
- Windows 10 y posteriores ×64
Si no tienes una versión previa de la WSL (como la WSL1) puedes instalarla directamente en PowerShell o el símbolo del sistema de Windows del administrador y, a continuación, reinicia la máquina:
Bash:
wsl --install
Bash:
wsl -l -v
Bash:
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Bash:
systeminfo | find "Tipo de sistema"Yo obtuve:
Tipo de sistema: x64-based PCPor lo que debería instalar Paquete de actualización del kernel de Linux en WSL 2 para máquinas x64
Si, en cambio, tienes ARM64, descarga el paquete ARM64.
Ejecuta el paquete de actualización que descargaste en el paso anterior. (Doble clic para ejecutarlo. Pueden pedirte, pedirán permisos elevados. Selecciona "Sí" para aprobar esta instalación).
Definimos WSL2 como predeterminada:
Bash:
wsl --set-default-version 2
Bash:
wsl --set-version <distro name> 2
Bash:
wsl --set-version Ubuntu-20.04 2Si no has instalado la distribución de Ubuntu, simplemente búscala en la tienda de Windows.
¡Si has seguido los pasos correctamente, entonces habrás instalado/actualizado la WSL2 correctamente!
INSTALACIÓN DE POKEEMERALD:
Un momento, Juanjo, yo ya he instado Pokeemerald ¿Por qué debería yo instalarlo nuevamente? A lo que te diré:
Si usabas WSL 1 tenía entonces mucho sentido que tuvieras tus archivos del ROM en una carpeta de Windows y su instalación seguiría los pasos de instalación para Windows. Sin embargo, si hacemos eso con WSL 2 la compilación sería lentísima porque estaríamos compilando algo dentro de Windows. Aquí asumimos que estamos en UNA VERSIÓN NATIVA DE LINUX.
Por lo tanto, lo más limpio sería instalar de nuevo Pokeemerald (y tu proyecto actual). Sin embargo, como todo está en GitHub no es mayor problema. Siempre y cuando tengas tu proyecto bien actualizado y al tope de commits no será un problema clonar de nuevo el repositorio y continuarlo.
Para esto seguiremos las instrucciones de https://github.com/pret/pokeemerald/blob/master/INSTALL.md para Linux. ¡IMPORTANTE! Ahora estamos en Linux, por lo que seguiremos las instrucciones como si fuera de Linux e ignoraremos lo de Windows. Esto es muy importante.
Abrimos la terminal de la WSL2
Ejecutamos:
(podría tardar un poco, pero esto actualizará todo el sistema)
Ahora instalaremos los paquetes necesarios:
En este punto deberemos escoger una carpeta donde almacenaremos pokeemerald (y agbcc). Por ejemplo, yo lo tengo en /home/juanjo/hack/decomp. Aunque tu la podrías escoger donde quieras (evita usar espacios a toda costa). Para este tutorial usaremos la carpeta tuto_decomp.
Creamos la carpeta (si no existe):
Ingresamos a la carpeta
Clonamos el Pokeemerald de pret:
Clonamos el agbcc
Y recuerden utilizar el comando ./install.sh ../MIPROYECTO para cada uno de los proyectos que clonen.
Volvemos a la carpeta anterior:
Y entramos a Pokeemerald
Revisamos si podemos compilar:
Ejecutamos:
Bash:
sudo apt update && sudo apt upgradeAhora instalaremos los paquetes necesarios:
Bash:
sudo apt install build-essential binutils-arm-none-eabi git libpng-devCreamos la carpeta (si no existe):
Bash:
mkdir tuto_decomp
Bash:
cd tuto_decomp
Código:
git clone https://github.com/pret/pokeemerald
Código:
git clone https://github.com/pret/agbcc
cd agbcc
./build.sh
./install.sh ../pokeemeraldVolvemos a la carpeta anterior:
Bash:
cd ..
Bash:
cd pokeemerald
Bash:
make -j$(nproc)Una vez tenemos el pokeemerald (y cuanto proyecto quieras) instalado, vamos a instalar algunos paquetes necesarios que nos servirán para el debug del juego. (Aquí realmente comienza este tutorial)
Instalar devkitARM
Bash:
sudo apt install gdebi-coreDescargamos el devkitpro-pacman.amd64.deb o el devkitpro-pacman.arm64.deb dependiendo de nuestra versión como vimos cuando instalamos el WSL2 (generalmente es amd64).
En la terminal del WSL2 volvemos al home con el siguiente comando
Creamos una nueva carpeta para descargas:
Entramos a la carpeta y usamos el comando pwd:
Debería darte una dirección así:
Vamos a abrir el explorador de archivos de Windows y buscamos a la dirección:
Recuerda que tu nombre de usuario será diferente.
Ahora pegaremos aquí usando las ventanas de Windows el archivo que descargamos previamente
Revisamos que en la terminal el archivo exista:
Debería mostrarte que el archivo existe:
Si todo va bien, vamos a ejecutar
En la terminal del WSL2 volvemos al home con el siguiente comando
Bash:
cd
Bash:
mkdir Downloads
Bash:
cd
Bash:
mkdir Downloads/home/juanjo/DownloadsVamos a abrir el explorador de archivos de Windows y buscamos a la dirección:
Recuerda que tu nombre de usuario será diferente.
Ahora pegaremos aquí usando las ventanas de Windows el archivo que descargamos previamente
Revisamos que en la terminal el archivo exista:
Bash:
lsdevkitpro-pacman.amd64.debSi todo va bien, vamos a ejecutar
Bash:
sudo gdebi devkitpro-pacman.amd64.deb
sudo dkp-pacman -Sy
sudo dkp-pacman -S gba-devEdit:
Para instalar el devkitpro, ahora será necesario ejecutar el siguiente comando en la carpeta de descargas
Bash:
wget https://apt.devkitpro.org/install-devkitpro-pacman
Bash:
sudo ./install-devkitpro-pacman
Bash:
sudo dkp-pacman -Sy
sudo dkp-pacman -S gba-devNota: devkitpro-pacman.amd64.deb es el nombre de archivo esperado del paquete devkitPro descargado (para el primer comando). Si el nombre de archivo del paquete descargado es diferente, utiliza ese nombre de archivo en su lugar.
Ejecutamos el siguiente comando para establecer las variables de entorno relacionadas con devkitPro (alternativamente, cierra y vuelva a abrir WSL):
Bash:
source /etc/profile.d/devkit-env.sh
Bash:
cd /opt
sudo ln -s devkitpro/ devkitProSi todo va correcto, deberíamos ahora compilar el juego usando el compilador moderno. ¡Lo cual es genial!
Bash:
make DINFO=1 modern -j$(nproc)DINFO=1 activa la información de depuración
modern construye con un compilador más moderno, permitiendo más optimizaciones y características del lenguaje.
-j$(nproc) calcula cuántos procesadores tiene el PC y construye utilizando todos ellos. Esto acelerará en gran medida el proceso de build.
CONFIGURAR EL VSCODE PARA WSL2
Ahora sí que podemos decir que este tutorial realmente comienza XD (me he basado mucho en este tutorial https://github.com/walkingeyerobot/pokeemerald/wiki/wsl2-and-vscode-setup)
Créditos a walkingeyerobot.
- Instala la extensión de sintaxis para los .inc de pkmscript (opcional) https://www.pokecommunity.com/showthread.php?t=434031
- Añade la carpeta .vscode
Esta debe ser una subcarpeta inmediata del directorio pokeemerald. Luego crea 3 nuevos archivos dentro de su nuevo directorio .vscode:- c_cpp_properties.json
- tasks.json
- launch.json
- Contenidos:
- c_cpp_properties.json: Este archivo le dirá a vscode cómo informarnos sobre los errores y advertencias. También habilitará intelliSense:
JSON:{ "configurations": [ { "name": "GBA", "includePath": [ "${workspaceFolder}", "${workspaceFolder}/include", "${workspaceFolder}/gflib", "${workspaceFolder}/tools/agbcc/include" ], "defines": [ "_DEBUG", "UNICODE", "_UNICODE", "DEBUG", "DINFO", "_MSC_VER" ], "intelliSenseMode": "gcc-arm", "browse": { "path": [ "${workspaceFolder}" ], "limitSymbolsToIncludedHeaders": true, "databaseFilename": "" }, "cStandard": "c99" } ], "version": 4 } - tasks.json:Aquí es donde definimos nuestra tarea de construcción, que nos permite construir directamente desde vscode:
JSON:{ { "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "make", "args": [ "DINFO=1", "modern", "-j$(nproc)" ], "group": { "kind": "build", "isDefault": true }, "problemMatcher": [ "$gcc" ] }, ] } - launch.json:Esto permite el uso del depurador vscode. El soporte no es perfecto, pero sigue siendo bastante potente:
JSON:{ "version": "0.2.0", "configurations": [ { "name": "Debug", "type": "cppdbg", "request": "launch", "program": "${workspaceRoot}/pokeemerald_modern.elf", "args": [ "target remote ${env:TODAYSIP}:2345" ], "stopAtEntry": true, "cwd": "${workspaceRoot}", "environment": [], "externalConsole": false, "miDebuggerServerAddress": "${env:TODAYSIP}:2345", "debugServerArgs": "${workspaceRoot}/pokeemerald_modern.elf -g", "serverStarted": "started", "preLaunchTask": "${defaultBuildTask}", "logging": { "moduleLoad": true, "trace": true, "engineLogging": true, "programOutput": true, "exceptions": true }, "linux": { "MIMode": "gdb", "miDebuggerPath": "/opt/devkitpro/devkitARM/bin/arm-none-eabi-gdb", "debugServerPath": "${workspaceRoot}/mgba.sh" } } ] }
- c_cpp_properties.json: Este archivo le dirá a vscode cómo informarnos sobre los errores y advertencias. También habilitará intelliSense:
- Script para ejecutar mGBA:
Para conectarse a un depurador remoto, vscode escanea la salida estándar del servidor de depuración remoto (como funciona mGBA) en busca de un mensaje de inicio definido por la propiedad serverStarted en el archivo launch.json. mGBA no imprime nada en la salida estándar, así que tenemos que envolverlo en un script que sí imprima algo.
Entonces, en el directorio raíz de nuestro espacio de trabajo, (por ejemplo pokeemerald creamos un archivoo llamado mgba.sh. Asegúrate de marcar el archivo como ejecutable después de guardarlo con chmod +x mgba.sh. Además, no utiliza el bloc de notas para editar este archivo; obtendrá malas líneas nuevas, que bash no entenderá. Usa algo como vim de WSL2, el Notepad++ de Windows o directamente el VSCode.
El $1 será el archivo rom pasado por vscode. -g le dice a mGBA que inicie inmediatamente el servidor de depuración gdb.Bash:#!/bin/bash ( sleep 4 echo "started" )& /path/to/your/mGBA.exe $1 -g
Aquí tendríamos que llenar /ruta/para/el/mGBA.exe. Como esta es una aplicación de Windows, la ruta estará en el sistema de archivos de Windows, que está montado en /mnt/c. En mi caso es
/mnt/c/Program\ Files/mGBA/mGBA.exe $1 -g - Definir $TODAYSIP:
Cada vez que WSL2 se inicia, obtiene una nueva dirección IP. Como estamos depurando sobre IP, necesitaremos saber cuál es esa dirección. Añadimos esta línea al final en el ~/.bashrc:
(Si no sabes abrir el .bashrc, puedes usar este comando:Bash:export TODAYSIP=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')code ~/.bashrc) - Configurar el Firewall de Windows:
Por defecto, todo el tráfico de red entre WSL2 y Windows está bloqueado por el Firewall de Windows. Tenemos que desbloquearlo. En Windows, creamos un archivo llamado firewall.ps1 y pegamos el siguiente contenido:
Este script añadirá una excepción para nuestro tráfico de red de depuración, así como eliminará cualquier regla antigua que tuviéramos desde la última vez que ejecutamos el script. Este script necesita ser ejecutado como administrador, y necesita ser ejecutado cada vez que WSL2 se inicie.Código:$remoteport = wsl -- cat /etc/resolv.conf `| grep nameserver $found = $remoteport -match '\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}'; if( $found ){ $remoteport = $matches[0]; } else{ echo "cannot determine ip"; exit; } iex "Remove-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' "; iex "New-NetFireWallRule -DisplayName 'WSL 2 Firewall Unlock' -Direction Inbound -LocalAddress $remoteport -Action Allow";
Abre el Programador de Tareas (está integrado en Windows) y haz lo siguiente:
- Has clic en Acción -> Crear tarea.
- En la pestaña General, dale a tu tarea el nombre de "WSL firewall exception".
- Todavía en la pestaña General, marca la casilla "Ejecutar con los más altos privilegios".
- En la pestaña Desencadenadores, has clic en Nuevo...
- En el menú desplegable Comenzar la tarea, selecciona Al iniciar la sesión.
- En Configuración avanzada (a mitad del cuadro de diálogo), marca Retrasar la tarea para: y ajústala a 30 segundos.
- Haz clic en Aceptar para volver a la pestaña de Activadores.
- En la pestaña Acciones, has clic en Nuevo...
- Introduce "powershell" (sin las comillas) como programa/script.
- Introduce "-File C:\path\to\your\firewall.ps1" (sin las comillas) en Añadir argumentos.
- Has clic en Aceptar hasta que todos los cuadros de diálogo se han ido.
- Reinicia el computador
Esto establecerá la configuración del firewall cuando vuelva a iniciar sesión. También permitirá que vscode lea los cambios que hicimos en.bashrc. - Instalar requisitos adicionales de debugging
Bash:sudo apt-get install libtinfo5 libpython2.7 - LISTO!!
Intenta poner algunos breakpoints y presionar F5 para compilar el juego y ejecutar el debug.
Aquí dejé un breakpoint dentro de CB2_MainMenu() cuando hay un archivo guardado antes de cargar el menú:
BONUS: Configuración de Porymap
Hasta ahora hemos configurado el Visual Studio Code para poder compilar, ejecutar y debuggear.
Ahora configuraremos Porymap. En el tutorial de walkingeyerobot nos dicen que
Afortunadamente yo me se un truco que nos permitiría usarel Porymap nativo desde Ubuntu. (sin embargo lo dejarépara una segunda parte de este tutorial)
Seguiremos con su tutorial y luego yo les explico a usar el X11
Abrimos Porymap y seleccionamos su proyecto. Podemos navegar hasta el sistema de archivos WSL2 introduciendo manualmente
El siguiente paso es conseguir que el botón "Open Map Scripts" funcione. Podríamos simplemente establecer VSCode como nuestro editor por defecto, pero esto siempre abriría el archivo de la ruta
Primero, creamos un nuevo archivo en algún lugar de tu sistema de archivos WSL2 (en Linux) llamado
Asegúrate de hacer
Este script reescribirá las rutas de la versión Windows a la versión Linux, permitiendo que VSCode las lea a través de la extensión WSL2.
Ahora en Porymap, ve a Opciones -> Editar Preferencias. Para "Open Directory Command", establece el valor a
\wsl$\Ubuntu\path\to\your\pokeemeraldEl siguiente paso es conseguir que el botón "Open Map Scripts" funcione. Podríamos simplemente establecer VSCode como nuestro editor por defecto, pero esto siempre abriría el archivo de la ruta
\wsl$\Ubuntu, que es lento y nunca se abrirá en nuestra ventana VSCode existente.Primero, creamos un nuevo archivo en algún lugar de tu sistema de archivos WSL2 (en Linux) llamado
wslcode.sh y ponemos lo siguiente en él:
Bash:
#!/bin/bash
echo $@ | sed 's/\\/\//g' | sed 's/\/\/wsl\$\/Ubuntu//' | xargs codechmod +x wslcode.sh para que sea ejecutable.Este script reescribirá las rutas de la versión Windows a la versión Linux, permitiendo que VSCode las lea a través de la extensión WSL2.
Ahora en Porymap, ve a Opciones -> Editar Preferencias. Para "Open Directory Command", establece el valor a
wsl /path/to/your/wslcode.sh . Para "Goto Line Command", establece el valor a wsl /path/to/wslcode.sh -r --goto %F:%L. A continuación, haga clic en Aceptar y ya está.Esperen una actualización con más trucos
Juanjo
Adjuntos
Última edición:
