Fix emscripten build

[Namaneo]

• JIT recompiler isn't available for this platform, setting DYNAREC to nothing forces the interpreter mode.
• WASM raises "null function or function signature mismatch" when calling a fallback function like dummy_func, I replaced it by actual dummy implementations.

[notaz]

Just curious, does it actually work? If so, how's the performance?

[Namaneo]

Well, I must say I've been surprised how well it runs, actually! I'm only supporting single file games atm, so I could just try Soul Blade, but it's running full speed on both Chrome (Window 11) and Safari iOS (iPhone 12)!

If you have some games laying around, you can try here: https://namaneo.github.io/Junie/ Chrome and Safari only, and support is still experimental (e.g. joypad might not be mapped correctly, multi-files games will not start, etc.).

[notaz]

Cool, works for me too in Chromium under Linux. But it stutters periodically, like once every 5 seconds or so, even though it's using just 1 core at ~80%. On another faster Linux machine it hogs 2 cores 100% and runs rather poorly, strange.

One thing you can try is enabling the neon gpu using it's x86 intrinsics version that emscripten docs claim to support. It will be more accurate and might be faster if it works. According to the docs -msimd128 -mavx might work, if it does it should take the least amount of instructions, else some -msse variant maybe. Supposedly it also supports ARM NEON intrinsics so that might also work with -mfpu=neon, but the docs say 64bit vectors are poorly supported so it'll probably be bad as those were used a lot by the ARM version of the neon plugin (it was designed for now very old Cortex-A8).

[Namaneo]

Thanks for the suggestions! I've tried a bunch of different things during the past few hours: either the flags are completely ignored, or it doesn't compile at all. Out of curiosity, I tried to directly update a few system headers to make it compile, assuming that some optimizations might happen under the hood: tried before and after, no noticeable change on my end. I should precise that I'm not actually compiling with Emscripten, I'm using the WASI-SDK with Emscripten's headers (not sure if that makes a real difference though).

That's said, I found something strange in libretro.c: the update_variables function always crashes the core when called after the game has started (so when in_flight is true, again with a null function or function signature mismatch). It comes from the GPU_open/GPU_close lines, commenting them out make the core work fine. Do you have an idea of what could be happening? Would it be safe to remove them?

   if (in_flight)
   {
      // inform core things about possible config changes
      plugin_call_rearmed_cbs();

    //   if (GPU_open != NULL && GPU_close != NULL)
    //   {
    //      GPU_close();
    //      GPU_open(&gpuDisp, "PCSX", NULL);
    //   }

      /* Reinitialise frameskipping, if required */
      if (((frameskip_type     != prev_frameskip_type)))
         retro_set_audio_buff_status_cb();

      /* dfinput_activate(); */
   }

[notaz]

I can't tell if it's really needed as that code is more than 10 years old, but maybe some platform relies on it. I'd prefer the platforms to not deviate too much as that creates situations where something works on some platforms but not the others, which is annoying to debug. Try if the latest commit helps.

[Namaneo]

Tried the latest commit, it seems to work fine now! Thanks a lot for the update!

Reacting a bit late to "On another faster Linux machine it hogs 2 cores 100% and runs rather poorly, strange.": there might be reasons unrelated to the core itself, the most reasonable one being that I'm rendering using requestAnimationFrame without taking into account the time passed between each retro_run (i.e. the core speed matches your screen's refresh rate). I think it's safe to assume that the bottleneck here is the frontend. The core runs surprisingly well even on my phone, and since the main purpose of Junie is to bring easy emulation to mobile devices (especially iOS), I'm fine with it for now.

Anyway, good talk! Not so long ago I couldn't even imagine bringing PS1 to the web with decent performance, thanks for being so reactive and for making it possible!