pdjstone / arculator-wasm Goto Github PK

The mouse latency in particular could be a lot better. Need to investigate why the lag occurs - whether it's due to the Emscripten/SDL or how Arculator is using SDL. Arculator running on native SDL has much better latency.

My understanding of how the main loop works when running in the browser wrt mouse:

• In emscripten_main.c, arcloop is run once every browser "frame" via emscripten_set_main_loop. This is driven from JavaScript using requestAnimationFrame which is tied to your monitor refresh rate and usually runs at 60fps (i.e. once every 16ms).
• arcloop calculates the number of milliseconds since the last frame and calls arc_run(ms) to emulate that number of milliseconds of emulator time.
• In main.c arc_run calls mouse_poll_host and keyboard_poll_host which should get the latest mouse event data from the browser. It then calls execarm to run the actual emulation.
• In emulator time, keyboard_poll is set to run once every 10000us (10ms). It calls get_mickeys to get the latest mouse movement data into the emulator.

In theory, we should be seeing 1 or 2 get_mickeys calls per frame because each browser frame is 16ms and get_mickeys is being called every 10 emulated ms. There should be new mouse event data every frame (i.e. before every call to arcloop)
But we need to verify this.

One change I've already made from upstream Arculator is to change the order of calls in arc_run from:

execarm();
joystick_poll_host();
mouse_poll_host();
keyboard_poll_host();

to:

joystick_poll_host();
mouse_poll_host();
keyboard_poll_host();
execarm();

This should mean that mouse events get processed before the next frame is rendered, improving latency by one frame.

Profiling shows that a significant time of each frame is current spent in iir_l and iir_r in sound.c which perform the low-pass audio filtering. I'm not sure why these are so slow, but I suspect it would be more performant to do the filtering using WebAudio, which has an IIR filter built in . Currently audio is done using SDL audio which is translated by Emscripten into WebAudio calls.

Bypassing SDL/Emscripten altogether would hopefully be a performance win, especially if we can use an AudioWorklet to do the work in a separate thread from the main emulation.