loader is barely called whereas audio for example is called super often
thus demote loaderr
jit is only ever used by Super Mario 3D stars, and no other
games require this to be a separate jit thread
additionally even of 3D stars this is called often chary
so no; we dont need a dedicated thread for it either way
this pr should help low power devices/devices with less cores/threads
to schedule the existing emulator threads more efficiently
also moving to guest means the CPU threads get more loaded with
stuffings, which is a good thing as most of the time theyre
sleeping and/or waiting for a mutex
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4148
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
take If{then, else} for example
100% of the time If{} only has a leaf terminal, supporting If{If{}, If{}} is very dumb and we don't need that
so remove that
this reduces
> The recursive_wrapper class template has an interface similar to a simple value container, but its content is allocated dynamically
aka. uses malloc and spams heap EVERYTIME A CONDITIONAL TERMINAL IS USED
thats bad tbf, i dont like it, removing it is better for general speedup
also we dont REALLY need if{if{if{if{}}}} support, like really
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4218
Reviewed-by: MaranBr <maranbr@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
Closeseden-emulator/Issue-Reports#8Closeseden-emulator/Issue-Reports#428
Currently, [Android's input layer](https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/android16-release/data/keyboards/Vendor_057e_Product_2009.kl#54) doesn't return `KEYCODE_DPAD_*` for the left Joy-Con, we fall back to the scan code in this case, this will also fix most third party Joy-Con controllers.
- The scan codes are not reliable and may vary from device to another. I searched for (0x220-0x223) values in the [android repo](https://android.googlesource.com/platform/frameworks/base.git/+/refs/heads/android16-release/data/keyboards) and they all have the same DPAD_* key mapping, so not a big issue just might cause future issues if Google change the mapping in another vendor. I could simply limit the fix to the [left Joy-Con](https://github.com/torvalds/linux/blob/master/drivers/hid/hid-ids.h#L1096-L1105) `if (event.keyCode == 0 && event.device.vendorId == 0x057e && event.device.productId == 0x2006)`.
- Auto mapping doesn't work, I'm not very familiar with the JNI Specification, I managed to implement the below workaround, it basically checks if it's the left Joy-Con and add the first four DPAD_* keycodes
```cpp
// ./src/input_common/drivers/android.cpp
ButtonMapping Android::GetButtonMappingForDevice(const Common::ParamPackage& params) {
// ...
const char *yuzu_device_name = env->GetStringUTFChars((jstring) env->CallObjectMethod(j_device, Common::Android::GetYuzuDeviceGetName()), &isCopy);
const char *switch_left_string_name = "Nintendo Switch Left Joy-Con";
bool is_switch_left = strncmp(yuzu_device_name, switch_left_string_name, strlen(switch_left_string_name)) == 0;
std::set<s32> available_keys;
for (size_t i = 0; i < keycode_ids.size(); ++i) {
if (j_has_keys[i] || (is_switch_left && i <= 3)) {
available_keys.insert(keycode_ids[i]);
}
}
// ...
}
```
Signed-off-by: crueter <crueter@eden-emu.dev>
Authored-by: Anas Bouzid <bouzid.anas.1@gmail.com>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4225
Reviewed-by: Lizzie <lizzie@eden-emu.dev>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
CamilleLaVey
CamilleLaVey
lizzie
PavelBARABANOV
crueter
Eden CI