Waits that polled now block on an eventcount that the waited-on thread
notifies:
- Booting in dual core waits for the CPU thread to reach its run loop
instead of polling every millisecond.
- AsyncShaderCompiler::WaitUntilCompletion wakes as each worker
finishes an item instead of every 33 ms.
Timed sleeps go through Common::SleepUntil and SleepCurrentThreadUs,
built on retro_sleep_us: the CoreTiming throttle, PrecisionTimer, real
Wiimote report pacing, Bluetooth timed transfers, the Linux L2CAP
connect retry and the BBA read thread's idle wait.
FrameTiming::ThrottleFrame had no callers and is deleted.
No std::thread, std::async, std::future or std::promise is left. Each
thread is an sthread with a plain entry point: Common::ThreadEntry<&C::F>
turns a member function into one, Common::JoinThread joins and clears a
handle, and Common::StartDetachedThread covers the fire-and-forget users.
Common/ParallelFor.{h,c} (C89) runs fn(ctx, i) for i in [0, count) on a
persistent pool of one worker per extra core plus the caller. Jobs are
claimed with an atomic counter, workers park on an eventcount between
batches, and the batch hand-off is a seq_cst users/active pair, so there
is no lock anywhere. A caller that finds the pool busy runs its batch
serially instead of waiting. retro_deinit joins the pool.
- VolumeWii::HashGroup spawned 64 threads per 2 MiB group and
EncryptGroup another one per core; both are now parallel_for batches
on the pool. The H1/H2 tail is a few small hashes and runs inline.
- VolumeVerifier spawned up to five std::async threads per chunk; the
chunk's tasks now go to one persistent worker that fans them out with
parallel_for, still overlapping the next read. The Redump lookup is an
sthread joined in Finish or the destructor.
- The dual-core "GPU thread" in Core only set a thread_local on itself
and exited, since the frontend runs the GPU loop. It is gone, along
with the non-libretro branches of Core.cpp.
- The emu thread is started through Core::StartEmuThread.
- CPU core counts come from cpu_features_get_core_amount().
Dolphin fitted its picture into the frame by the Aspect Ratio mode, bars
and all, and the frontend scaled the frame to 4:3 or 16:9 once more, so
every mode but Stretch came out squeezed or stretched (Custom, Custom
Stretch and Raw the most). Dolphin now always stretches over the frame,
and the core gives the frontend the aspect ratio Dolphin works out for the
chosen mode (Presenter::CalculateDrawAspectRatio for a given mode), again
whenever it changes. Stretch and VR are as before.
Vulkan hands the frontend the whole swapchain image Dolphin presented
into, as D3D11 and OpenGL do with their backbuffer, instead of the EFB's
size (640x528 against a 640x480 image), which squeezed the picture.
A frontend can only get a real Wiimote by offering the Real WiiMote
device for each port, next to the emulated Wiimote. This option lets the
player pick one device for every Wii port instead, in place of what the
frontend set: any of the Wiimote devices, a Real WiiMote or a GameCube
Controller. Left at "Set per port", the frontend's choice stands.
Real WiiMote also scans for Wiimotes continuously, since a real one is
only found by scanning.
They were only declared when a game loaded, so a frontend that lists a
core's options without loading content saw none. Kodi's add-on generator
does that, so Dolphin's Kodi add-on ships with no settings.
Adds dolphin_ir_passthrough, letting the frontend supply the Wiimote
camera's view of the sensor bar directly instead of having the core
synthesise it from a cursor position.
The cursor path parks a notional remote two metres from the bar and
rotates it by Total Yaw/Total Pitch, a scale with no physical
derivation, so where the game draws its hand depends on a constant
fitted per game. It also cannot express roll or distance. A frontend
that knows the real geometry (a VR room, a tracked light gun) can
compute the two dots outright, which BuildDesiredWiimoteState already
supports and nothing exposed.
* The option itself, off by default, under Wiimote IR.
* The Pointer device registers all four touch indices instead of only
the first, so the four IR objects ride on indices 0-3. Index 0 keeps
its old names, leaving the mouse-mode IR binding untouched.
* IRPassthrough is bound and enabled when the option is on: object N
takes Pointer:XN+/YN+ over the camera's 0..1 field, PressedN as
presence, and a small constant size. Bindings are cleared when off,
since AreInputsBound() is half of what selects this path.
* irPassthrough is raised at controller setup as well as on an option
change, so the setting applies on a cold boot.
In dual-core mode, retro_serialize and retro_unserialize queue DoState
to the CPU thread via RunOnCPUThread. The CPU thread does not have the
frontend's GL context current, so any GL calls during DoState segfault.
Temporarily declare the calling thread as the CPU thread so DoState
runs inline where the GL context is valid.
Tested on macOS arm64 with a third-party libretro frontend using an
offscreen CGL context.
* Fixed the issue where you had to manually edit `Dolphin.ini` to enable GC controllers 2-4.
* Added the possibility to un/plug Wiimotes or GC controllers on-the-fly. Previously not possible with GC controllers, and it was messing with the players order if Wiimotes were not reconnected in the correct order.
* Added the possibility to use GC controller as players 1-4 in Wii mode. Makes it possible to play Brawl, MK Wii, etc. with a GC layout.
* Fix Wiimotes displaying GC labels by default.
* (not related to inputs) Removed the unused "efb_scale" variable. It was harmless but that's one less warning during compilation :p
libretroadmin