LAS Recomp for Android 0.5.8 (preview): native game code, game files in place / código nativo do jogo, arquivos do jogo no lugar

English

Native game code (experimental): the game can run without building its code on the phone. Game files used in place: no copy of the game data. The setup takes a ready-made romfs.bin. Plus fixes for issues #2, #7 and #10, and a crash when going back to the start screen.

• Native game code (experimental). The game's own ARM64 code runs directly on the phone's CPU instead of the game code the setup builds from your files. With Game code: Native (chosen above the game files folder, before picking it), the setup only copies the files: no build, none of the minutes, memory and storage it takes. An installed game can switch in Video > Native game code (applies at the next start). Off by default; the recompiled path is unchanged. Only what can't run outside the Switch is rewritten when the game loads (system calls, thread storage, the clock), and LAS Recomp's own fixes and features (widescreen, frame pacing, the crash fixes) hook into the same places. On phones whose clock isn't the Switch's 19.2 MHz (most Mali phones), the game's time is converted to it. From BOTWRecompAndroid, after the approach of MacNativeGames and d2r-mobile.
• Back to the start screen no longer crashes on Turnip while sound plays: the audio kept reading the game's memory after it had been released.
• Crash on 0.5.7 with write tracking (issue #2: signal 11 right after "page write tracking on"): a fault on a page that should already be writable is now reopened instead of ending the game.
• Mali memory coherency (issue #2): on Mali, the shader memory and the GPU readbacks live in cached memory that isn't coherent; it's now flushed and invalidated by hand. This may be behind the dark village and the broken geometry reported there.
• Up to 16 swapchain images (issue #10): drivers that ask for more than 8 no longer stop the game at startup.
• Game memory on the GPU only with ~7 GB of RAM or more: on a 6 GB phone with the option turned on by hand, Android killed the app while the world loaded.
• Lighter game code build (issue #7): no debug info, sanitizer or stack protector from the compiler, which used much more memory and time.
• Game files used in place (no copy). A new choice above the game files folder: Game files: Copy them / Use them in place. In place, the setup copies only exefs/ (small) and the game reads its data straight from your folder - its romfs/ or its romfs.bin - so the ~6 GB copy, its wait and its space are gone. Android asks for the permission to access all files when you pick the folder (only in this mode). The folder must stay where it is: moved or deleted, set the game files up again (the game says so). Mods still apply on top. From BOTWRecompAndroid.
• Game data in one romfs.bin, now ready-made too. The game reads its data from a single image, romfs.bin, not from its ~3,800 loose files (the setup has built that image from the picked folder since 0.4.0; only the few files opened by path, the movies and the sheets, stay loose). The setup now also takes a folder with exefs/ and a romfs.bin made already (on a PC with hactool --romfs, or from another install) when there's no romfs/ folder: it's copied as one file instead of ~3,800 through Android's file picker (what fails or crawls on many phones), checked from its own tables (header, size - a copy cut short is named - and every file by name and size against the game's version), and the loose files are taken out of it. A romfs/ folder is set up as before.

Updating from 0.5.7 doesn't build the game code again. Saves aren't touched.

Validation: release APK built and signed with the same key as the previous versions. On the POCO F7 Ultra (Adreno 830, Turnip), 1.1.0, with native game code: title screen, file select, Mabe Village with Link walking, widescreen; 60 fps in the village at 50% internal resolution, as with the recompiled code (the game thread took 5.4 ms a frame against 7.8 ms, one reading each; native showed an occasional single slow frame); back to the start screen and in again; and issue #2's route (Mysterious Woods, the village, the Library and out) with a Mali-like path simulated - game memory through CPU copies with write tracking, non-coherent shader memory, Vulkan 1.1 without dynamic rendering, synchronization2 or extended dynamic state, and the converted clock forced on - with the right picture at each stop and no crash. The start screen crash was reproduced with the recompiled code too, and fixed. Game files in place: the image made up from a folder is identical, byte for byte, to the romfs.bin built from it (PC); on the POCO, with 1.1.0's romfs/ folder in the phone's storage, the game stops with a clear message without the all-files permission, and with it indexes the 3,836 files in 0.1 s, plays the movies from the folder and reaches the village; a romfs.bin used in place too (with native game code). The file picker's in-place flow itself wasn't run on the phone (it would have replaced the installed setup). Not tested on a real Mali, Xclipse or Qualcomm driver here; the romfs.bin import and the 16 swapchain images weren't run on a phone.

Experimental preview for Android 11+ / ARM64. It does not include any files extracted from the game.

---

Português

Código nativo do jogo (experimental): o jogo pode rodar sem compilar o código dele no celular. Arquivos do jogo usados no lugar: sem cópia dos dados do jogo. A configuração aceita um romfs.bin pronto. Mais correções para as issues #2, #7 e #10, e para um crash ao voltar à tela inicial.

• Código nativo do jogo (experimental). O código ARM64 original do jogo roda direto no processador do celular, no lugar do código que a configuração compila a partir dos seus arquivos. Com Código do jogo: Nativo (escolhido acima da pasta dos arquivos do jogo, antes de escolhê-la), a configuração só copia os arquivos: sem compilar, sem os minutos, a memória e o espaço que isso pede. Um jogo já instalado pode mudar em Vídeo > Código nativo do jogo (vale a partir do próximo início). Desligado por padrão; o caminho recompilado não muda. Só o que não roda fora do Switch é reescrito quando o jogo carrega (chamadas de sistema, armazenamento das threads, o relógio), e as correções e recursos do próprio LAS Recomp (widescreen, ritmo dos quadros, as correções de crash) entram nos mesmos pontos. Em celulares cujo relógio não é o de 19,2 MHz do Switch (a maioria dos com Mali), o tempo do jogo é convertido para ele. Vem do BOTWRecompAndroid, seguindo a ideia do MacNativeGames e do d2r-mobile.
• Voltar à tela inicial não trava mais no Turnip com som tocando: o áudio continuava lendo a memória do jogo depois de ela ser liberada.
• Crash da 0.5.7 com o rastreio de escrita (issue #2: signal 11 logo depois de "page write tracking on"): uma falha numa página que já deveria poder ser escrita agora é reaberta em vez de encerrar o jogo.
• Coerência de memória na Mali (issue #2): na Mali, a memória dos shaders e as leituras de volta da GPU ficam em memória com cache que não é coerente; agora ela é sincronizada à mão. Isso pode estar por trás da vila escura e da geometria quebrada relatadas lá.
• Até 16 imagens na swapchain (issue #10): drivers que pedem mais de 8 não param mais o jogo na abertura.
• Memória do jogo na GPU só com ~7 GB de RAM ou mais: num celular de 6 GB com a opção ligada à mão, o Android fechava o app enquanto o mundo carregava.
• Compilação do código do jogo mais leve (issue #7): sem informações de depuração, sanitizer nem proteção de pilha do compilador, que gastavam bem mais memória e tempo.
• Arquivos do jogo usados no lugar (sem cópia). Uma escolha nova acima da pasta dos arquivos do jogo: Arquivos do jogo: Copiar / Usar no lugar. No lugar, a configuração copia só o exefs/ (pequeno) e o jogo lê os dados direto da sua pasta - o romfs/ ou o romfs.bin dela -, então somem a cópia de ~6 GB, a espera e o espaço. O Android pede a permissão de acesso a todos os arquivos quando você escolhe a pasta (só nesse modo). A pasta tem que ficar onde está: movida ou apagada, configure os arquivos do jogo de novo (o jogo avisa). Os mods continuam valendo por cima. Vem do BOTWRecompAndroid.
• Dados do jogo num único romfs.bin, agora também pronto. O jogo lê os dados de uma única imagem, o romfs.bin, e não dos seus ~3.800 arquivos soltos (a configuração monta essa imagem a partir da pasta escolhida desde a 0.4.0; só os poucos arquivos abertos pelo caminho, os vídeos e as planilhas, ficam soltos). Agora a configuração também aceita uma pasta com exefs/ e um romfs.bin já pronto (feito no PC com hactool --romfs, ou de outra instalação) quando não há pasta romfs/: ele é copiado como um arquivo só em vez de ~3.800 pelo seletor de arquivos do Android (o que falha ou se arrasta em muitos celulares), conferido pelas próprias tabelas (cabeçalho, tamanho - uma cópia incompleta é apontada - e cada arquivo por nome e tamanho contra a versão do jogo), e os arquivos soltos são tirados dele. Uma pasta romfs/ é configurada como antes.

Atualizar a partir da 0.5.7 não compila o código do jogo de novo. Os saves não são alterados.

Validação: APK de release compilado e assinado com a mesma chave das versões anteriores. No POCO F7 Ultra (Adreno 830, Turnip), 1.1.0, com o código nativo: tela de título, seleção de arquivo, Vila Mabe com o Link andando, widescreen; 60 fps na vila com resolução interna de 50%, como com o código recompilado (a thread do jogo levou 5,4 ms por quadro contra 7,8 ms, uma leitura de cada; o nativo teve um quadro lento de vez em quando); voltar à tela inicial e entrar de novo; e a rota da issue #2 (Floresta Misteriosa, a vila, a biblioteca e a saída) simulando o caminho da Mali - memória do jogo por cópias pela CPU com o rastreio de escrita, memória dos shaders não coerente, Vulkan 1.1 sem renderização dinâmica, synchronization2 nem estado dinâmico estendido, e o relógio convertido forçado - com a imagem certa em cada parada e sem crash. O crash da tela inicial também foi reproduzido com o código recompilado, e corrigido. Arquivos no lugar: a imagem montada a partir de uma pasta é idêntica, byte a byte, ao romfs.bin feito dela (PC); no POCO, com a pasta romfs/ da 1.1.0 no armazenamento do celular, o jogo para com uma mensagem clara sem a permissão de acesso a todos os arquivos, e com ela indexa os 3.836 arquivos em 0,1 s, toca os vídeos da pasta e chega à vila; um romfs.bin usado no lugar também (com o código nativo). O fluxo pelo seletor de arquivos no modo no lugar não rodou no celular (substituiria a instalação existente). Não testado numa Mali, Xclipse ou driver da Qualcomm de verdade aqui; a importação do romfs.bin e as 16 imagens da swapchain não rodaram num celular.

Preview experimental para Android 11+ / ARM64. Não inclui arquivos extraídos do jogo.