deadxwarrior

the GS was the biggest one, i emulate it in WebGPU compute shaders, and texture sampling alone takes about a third of the GPU time, so at 2x GoWw is gpu-bound on an integrated gpu. On the cpu side, VU1 microcode and the GS front end each take roughly a quarter of the time, so both run on their own threads. another one was synchronous GPU readbacks in GT4, and about a thousand tiny effect draws per frame in GoW2 combat batching and caching fixed most of them, and it holds 60fps at native resolution

Thanks for pointing this out! i found the issue and fixed it

i actually developed the project to play my own game dumps remotely via VPN from my home server; making it publicly available is not legal and will be consequences:)

Thanks:) it isn't cycle-accurate, and for the games i have tried so far it hasnt needed to be. EE code is translated AOT, and each block subtracts its instruction count from a cycle budget. Interrupts, timers, DMA and vblank are events on one emulated clock, delivered at block boundaries, so the order is right and the timing is approximate. Most games sync on interrupts and semaphores rather than cycle counts. When one does depend on timing, it shows up as a specific bug i can fix.for example, ran off an HBLANK timer I had set to the PAL period on an NTSC game. VU programs are not really part of the executable; games upload them over DMA. So i record each microprogram the first time its uploaded and compile it aot, and in the browser i JIT any program i havent seen to wasm. The pipeline details games actually observe are modeled: MAC/status/clip flags become visible four instructions late (getting that wrong put blotches on GT4s cars), and PS2 floats, which are nott IEEE (no inf/NaN, clamping instead), are done bit-exact. VU1 runs on its own thread, synced to the EE through the VIF/GIF streams

There is already a native Linux build (Vulkan through wgpu, SDL2 window, audio and gamepad support), so it can run on the Deck as a non-steam game, and the browser build should work in desktop mode too. Two things are missing, the native host still runs on one thread (the VU1 and GS threads only exist in the web host so far), and since i cant distribute anything built from a game, you currently have to convert your own ISO on a PC. Decks GPU is less than half of the laptop iGPU i test on, so 1x resolution is the realistic target for now.Please keep an eye on the repo update, i'll release the relevant update for u.

yes, and its probably where this should go. The recompiler itself is plain C++ and builds for wasm easily, the heavy part is compiling its output (GoW2 becomes about 670k lines of Cpp), which would need clang running in the browser. The nicer route is to have the recompiler emit WebAssembly directly and let the browsers own engine compile it. I already do that for VU1 microprograms that were not seen AOT. It also solves distribution you'd pick your own ISO and the conversion would happen locally, so nothing derived from the game is ever hosted.

Fair point, the IOP is interpreted. Its the PS1-class I/O CPU, and here it only runs the driver modules a game ships on its disc (sound engine, pad, memory card). The IOP kernel and the 20 core Sony libraries are reimplemented natively. In a God of War2 fight that interpreter is about 2% of cpu time, so it hasnot been worth recompiling yet for me. Its the same relocatable module problem i already handle for SN systems overlays, so its on the list. The EE game code is fully recompiled AOT (a missing function is a hard error, there is no interpreter fallback), and VU1 microprograms are recompiled per game, with a JIT and an interpreter only for programs not seen before. Whats left is hardware; the GS runs on the GPU, plus DMA, VIF, SPU2 and CDVD. Every recomp has to model that part, the same way N64Recomp uses RT64 for the RDP as i checked.