This adds the option to configure real Wiimotes by specifying their Bluetooth addresses in
the configuration file. This allows off-brand Wiimotes to work without using the
Bluetooth Passthrough option, if you know their Bluetooth addresses beforehand.
Despite correctly setting the LAP to `0x9e8b00` in `WiimoteScannerLinux::FindWiimotes`
while scanning, which is indeed enough to make off-brand / knock-off Wiimotes respond to a
Bluetooth Inquiry, some (several? all?) bluetooth adapters seem to override and ignore
this given LAP value when performing the Inquiry, and actually use the `0x9e8b33` value as
if a null pointer have been given to `hci_inquiry`, as inspection of USB/Bluetooth packets
by Wireshark indicate. Off-brand Wiimotes don't respond to inquiries with this LAP.
If one happens to know the Bluetooth address of their Wiimote (for example, by checking
`BluetoothPassthrough.LinkKeys` after using Bluetooth Passthrough, or other means such as
directly using `libusb` to force the adapter to use the correct LAP in the Inquiry), then
it's enough to add those addresses to the vector of found Wiimotes.
Since this a niche use case and I only happen to know and have tested in Linux, this
change only affects the `WiimoteScannerLinux` backend. It's likely that it could be added
to other backends, but I'm unfamiliar with these.
If no addresses are given or this config section does not exist, behavior is completely
unchanged.
Move ImGui::End() calls out of if(ImGui::Begin()) blocks.
Quoting from ImGui::Begin's function comment in imgui.cpp:
"You always need to call ImGui::End() even if false is returned."
In practice this didn't cause problems because the windows don't have
title bars and thus can't be collapsed, and so the block containing
::End would always run, but let's do it the right way.
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
We exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00218 mov w24, #0x100000 ; =1048576
0xcb180379 sub x25, x27, x24
After:
0xd1440379 sub x25, x27, #0x100, lsl #12 ; =0x100000
You can encode a 12-bit immediate in a SUB instruction on ARM64. We can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x5280003a mov w26, #0x1 ; =1
0xcb1a033b sub x27, x25, x26
After:
0xd100073b sub x27, x25, #0x1
While we cannot always avoid materializing immediates, we can still
inspect the most significant bit and potentially skip sign extension.
This can sometimes save an instruction.
Before:
0x5280003a mov w26, #0x1 ; =1
0x93407f5b sxtw x27, w26
0xcb38c37b sub x27, x27, w24, sxtw
After:
0x5280003a mov w26, #0x1 ; =1
0xcb38c35b sub x27, x26, w24, sxtw
Before:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb38c339 sub x25, x25, w24, sxtw
After:
0x52a20018 mov w24, #0x10000000 ; =268435456
0x93407f79 sxtw x25, w27
0xcb180339 sub x25, x25, x24
You can encode a shifted 12-bit immediate in an ADD instruction on
ARM64. If the negated constant fits in this range, we can exploit this
to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52bff01a mov w26, #-0x800000 ; =-8388608
0x93407f1b sxtw x27, w24
0xcb3ac37b sub x27, x27, w26, sxtw
After:
0x93407f1b sxtw x27, w24
0x9160037b add x27, x27, #0x800, lsl #12 ; =0x800000
You can encode a 12-bit immediate in an ADD instruction on ARM64. If the
negated constant fits in this range, we can exploit this to avoid
materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x12800019 mov w25, #-0x1 ; =-1
0x93407f5b sxtw x27, w26
0xcb39c37b sub x27, x27, w25, sxtw
After:
0x93407f5b sxtw x27, w26
0x9100077b add x27, x27, #0x1
You can encode a shifted 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52a00099 mov w25, #0x40000 ; =262144
0x93407f7a sxtw x26, w27
0xcb39c35a sub x26, x26, w25, sxtw
After:
0x93407f7a sxtw x26, w27
0xd141035a sub x26, x26, #0x40, lsl #12 ; =0x40000
You can encode a 12-bit immediate in a SUB instruction on ARM64.
Constants in this range do not need to be sign extended, so we can
exploit this to avoid materializing the immediate.
This approach saves an instruction if it does not need to be
materialized in a register afterwards. Otherwise, we just materialize
it later and the total number of instructions stays the same.
Before:
0x52800416 mov w22, #0x20 ; =32
0x93407f78 sxtw x24, w27
0xcb36c318 sub x24, x24, w22, sxtw
After:
0x93407f78 sxtw x24, w27
0xd1008318 sub x24, x24, #0x20
Thales MG