Registrarse

[Decomp-GBA] Configura la WSL2 y rompe las posibilidades del Decomp [desde 0]

Juanjo

Hacker del pasado... Compilador del presente
Miembro insignia
Hola!, ¿Qué tal?

Para muchos puede ser brujería esto de las WSL y como nos ayudan a compilar una ROM de GBA en pocos 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.

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:

  • 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:
    Bash:
    $ ./programa arg1 arg2 arg3 ...
    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.
  • 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.
Por último, para hacer verdadero C en Windows, lo mejor sería optar un sabor de Linux en Windows, como lo es Cygwin.

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.
CaracterísticaWSL 1WSL 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.
¿Qué ventajas me traería trabajar con el WSL2?
  • 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.
¿Qué desventajas me traería trabajar con el WSL2?
  • 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 :p) 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
Si quieres saber que versiones de la WSL están instaladas, usa:
Bash:
wsl  -l -v
Antes de instalar WSL 2, se debe habilitar la característica opcional Plataforma de máquina virtual. En el PowerShell ejecutar:

Bash:
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Ahora vamos a ver que tipo de sistema usamos, para esto ejecutamos:

Bash:
systeminfo | find "Tipo de sistema"
(Si tu PC está en inglés u otro idioma, usa en cambio "System Type" o comos ea en tu idioma)

Yo obtuve:Tipo de sistema: x64-based PC

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:

Bash:
wsl --set-default-version 2
Para actualizar de WSL 1 a WSL 2 en distribuciones de Linux instaladas previamente, vamos a usar el comando
Bash:
wsl --set-version <distro name> 2
, reemplazando <distro name> por el nombre de la distribución de Linux que desea actualizar. Por ejemplo,

Bash:
wsl --set-version Ubuntu-20.04 2
.

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.

Abrimos la terminal de la WSL2
Ejecutamos:
Bash:
sudo apt update && sudo apt upgrade
(podría tardar un poco, pero esto actualizará todo el sistema)

Ahora instalaremos los paquetes necesarios:

Bash:
sudo apt install build-essential binutils-arm-none-eabi git libpng-dev
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):
Bash:
mkdir tuto_decomp
Ingresamos a la carpeta
Bash:
cd tuto_decomp
Clonamos el Pokeemerald de pret:
Código:
git clone https://github.com/pret/pokeemerald
Clonamos el agbcc
Código:
git clone https://github.com/pret/agbcc
cd agbcc
./build.sh
./install.sh ../pokeemerald
Y recuerden utilizar el comando ./install.sh ../MIPROYECTO para cada uno de los proyectos que clonen.

Volvemos a la carpeta anterior:
Bash:
cd ..
Y entramos a Pokeemerald
Bash:
cd pokeemerald
Revisamos si podemos compilar:
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-core
Descargamos 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
Bash:
cd
Creamos una nueva carpeta para descargas:
Bash:
mkdir Downloads
Entramos a la carpeta y usamos el comando pwd:
Bash:
cd
Bash:
mkdir Downloads
Debería darte una dirección así:
/home/juanjo/Downloads

Vamos a abrir el explorador de archivos de Windows y buscamos a la dirección:
1651923654322.png


Recuerda que tu nombre de usuario será diferente.

Ahora pegaremos aquí usando las ventanas de Windows el archivo que descargamos previamente
1651923829894.png


Revisamos que en la terminal el archivo exista:
Bash:
ls
Debería mostrarte que el archivo existe:
devkitpro-pacman.amd64.deb

Si todo va bien, vamos a ejecutar
Bash:
sudo gdebi devkitpro-pacman.amd64.deb
sudo dkp-pacman -Sy
sudo dkp-pacman -S gba-dev

Edit:
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
Esto descargará un script que se encargará de instalarlo. Para ejecutar el script escribimos:

Bash:
sudo ./install-devkitpro-pacman
Y ya podremos continuar con la instalación de dev apra GBA normalmente:

Bash:
sudo dkp-pacman -Sy
sudo dkp-pacman -S gba-dev
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.

Nota: 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
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:

Bash:
cd /opt
sudo ln -s devkitpro/ devkitPro

Si todo va correcto, deberíamos ahora compilar el juego usando el compilador moderno. ¡Lo cual es genial!
Bash:
make DINFO=1 modern -j$(nproc)
¡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.

  1. Instala la extensión de sintaxis para los .inc de pkmscript (opcional) https://www.pokecommunity.com/showthread.php?t=434031
  2. Añade la carpeta .vscode
    1651925542122.png

    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
  3. 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"
      }
      }
      ]
      }
  4. 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.

    Bash:
    #!/bin/bash
    
    (
    sleep 4
    echo "started"
    )&
    
    /path/to/your/mGBA.exe $1 -g
    El $1 será el archivo rom pasado por vscode. -g le dice a mGBA que inicie inmediatamente el servidor de depuración gdb.

    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
  5. 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:

    Bash:
    export TODAYSIP=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2}')
    (Si no sabes abrir el .bashrc, puedes usar este comando: code ~/.bashrc)
  6. 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:
    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";
    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.

    Abre el Programador de Tareas (está integrado en Windows) y haz lo siguiente:
    1. Has clic en Acción -> Crear tarea.
    2. En la pestaña General, dale a tu tarea el nombre de "WSL firewall exception".
    3. Todavía en la pestaña General, marca la casilla "Ejecutar con los más altos privilegios".
    4. En la pestaña Desencadenadores, has clic en Nuevo...
    5. En el menú desplegable Comenzar la tarea, selecciona Al iniciar la sesión.
    6. En Configuración avanzada (a mitad del cuadro de diálogo), marca Retrasar la tarea para: y ajústala a 30 segundos.
    7. Haz clic en Aceptar para volver a la pestaña de Activadores.
    8. En la pestaña Acciones, has clic en Nuevo...
    9. Introduce "powershell" (sin las comillas) como programa/script.
    10. Introduce "-File C:\path\to\your\firewall.ps1" (sin las comillas) en Añadir argumentos.
    11. Has clic en Aceptar hasta que todos los cuadros de diálogo se han ido.
    [*][*][*]
  7. 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.
  8. Instalar requisitos adicionales de debugging
    Bash:
    sudo apt-get install libtinfo5 libpython2.7
  9. LISTO!!
    Intenta poner algunos breakpoints y presionar F5 para compilar el juego y ejecutar el debug.
1651930226522.png

Aquí dejé un breakpoint dentro de CB2_MainMenu() cuando hay un archivo guardado antes de cargar el menú:

1651930288816.png

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
Casi cualquier hack va a requerir el uso de Porymap. Prácticamente no podemos ejecutar Porymap directamente desde WSL2 porque es una aplicación gráfica. Sin embargo, ejecutándolo desde Windows, la mayoría de las veces funciona. La lectura y escritura de archivos es un poco lenta, pero eso es debido a la naturaleza de WSL2, así que no hay nada que podamos hacer al respecto.
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 \wsl$\Ubuntu\path\to\your\pokeemerald

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 \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 code
Asegúrate de hacer chmod +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:

Xiros

¡Creador de Pokémon Omega!
Miembro del equipo
Miembro de honor
Excelente aporte Juanjo!!

Seguro ayudará a que muchos puedan compilar más rápido y hacer uqe la experiencia sea mucho más placentera aún :)
 

Awuis

Usuario mítico
Sin lugar a dudas, es un aporte de primerísima calidad;
El tutorial está super bien redactado, y la disposición de imágenes paso a paso lo vuelve casi a prueba de cualquier error.

En mi caso, no tengo una PC con un procesador muy potente, venía compilando en WSL1 y demoraba de 8 a 16 minutos aprox (haciendo cambios en el PoryMap) y líneas de código quizás demoraba unos 2/3 minutos.
Utilizando WSL2 el tiempo de compilación mejoró considerablemente, llegando a los 2 minutos como super óptimo (4 min en el peor de los casos) haciendo cambios en PoryMap, y si tocase líneas de códigos, pfff, tardaría nada.

Mis dieces, simplemente un gran aporte. 🙌

PD: Estaría bueno que más gente se animase a trabajar en decompilación, es lejos 10 veces mejor que en binario tradicional.

PD2: Edito, estuve pasando tiles y creando mapas en el PoryMap, el tiempo de compilación ahora es de 1 minuto y medio aprox (!!!) increíble.
 
Última edición:

Lunos

Enfrentando a La Organización
Miembro insignia
Disculpe por molestar... pero el link a devkitpro está caído, github dice "page not found"...
El metodo de obtención de devkitPro cambió. Sus desarrolladores removieron los paquetes ".deb".
La forma de instalarlo ahora es utilizando wget https://apt.devkitpro.org/install-devkitpro-pacman para descargar un script diseñado por ellos mismos, y ejecutandolo usando sudo ./install-devkitpro-pacman.

Che @Juanjo, tal vez quieras editar el post principal.
 

Vindavlarljod

Aprendiz de leyenda
El metodo de obtención de devkitPro cambió. Sus desarrolladores removieron los paquetes ".deb".
La forma de instalarlo ahora es utilizando wget https://apt.devkitpro.org/install-devkitpro-pacman para descargar un script diseñado por ellos mismos, y ejecutandolo usando sudo ./install-devkitpro-pacman.

Che @Juanjo, tal vez quieras editar el post principal.
Gracias amigo, me funcionó, recibí ayuda en el Discord de WAH también, gracias. <3
 

Juanjo

Hacker del pasado... Compilador del presente
Miembro insignia
El metodo de obtención de devkitPro cambió. Sus desarrolladores removieron los paquetes ".deb".
La forma de instalarlo ahora es utilizando wget https://apt.devkitpro.org/install-devkitpro-pacman para descargar un script diseñado por ellos mismos, y ejecutandolo usando sudo ./install-devkitpro-pacman.

Che @Juanjo, tal vez quieras editar el post principal.
Gracias Lunitos,

Justo estaba siguiendo este tutorial para configurarlo en mi nuevo computador (Sí, estuve sin computador este tiempo y por eso no estuve activo) y noté que ya no se podía instalar el devkitpro.

Ya mismo actualizo el tutorial
 
Arriba