Replaces nlohmann_json with the much faster and much less bloated [jacinth](https://github.com/crueter/jacinth), a JSON library I'm working on that essentially aims to be a lightweight wrapper around `yyjson` with extra C++23 sauce. It's not as fast as yyjson or glaze, but has a very nice API that allows for compile-time struct serialization *and* traditional nlohmann-like OOPery (plus to_json and from_json). Jacinth also exclusively exposes itself as a C++20 module, so consider that migration started
httplib has been replaced with the **much** smaller [Hydrocarbon](https://github.com/crueter/hydrocarbon) (which is <1500 LoC compared to 24k). It's a much cleaner API than httplib and doesn't depend on curl or anything else (besides openSSL). Insert joke about me NIHing everything here.
Auto updater has been reworked. Windows setup executables will have a system.txt that indicates this is a system install; that will just execute the exe directly (same as .dmg on macOS)
Zip files will instead:
- Ask the user if they want to keep the old one around in a different directory.
- Extracts the zip into a staging directory
- Close while detach-launching a thin helper shim executable that:
- Removes or renames the old application directory in accordance with the user's choice
- Renames the staging directory to the current directory name
- Launches and detaches the *new* eden.exe in the background.
So to the user it looks like: download, extract, new Eden launches, yay.
Alongside all of these changes, I had to make a bunch of CMake changes to bring this project up to be modules-compatible. Consider it a bonus.
Assisted-by: Local Ornith-1.5-35B (fixing a few nonsensical build errors)
Signed-off-by: crueter <crueter@eden-emu.dev>
- [x] I have read and followed the [Contribution Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/CONTRIBUTING.md#code-contributions).
- [x] I have read and followed the [AI Policy](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/AI.md)
- [x] I have read and followed the [Coding Guidelines](https://git.eden-emu.dev/eden-emu/eden/src/branch/master/docs/policies/Coding.md) to the best of my ability.
-------------------
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4412
Reviewed-by: lizzie <lizzie@eden-emu.dev>
FFmpeg offers two opus decoders:
- libopus, this one is fed the same data (that affects output) as the previous libopus decoder had as well
- native opus decoder: this only takes Float32 samples, we then need to invoke swrescale to translate between s16 (what switch sends) and float32 (what FFmpeg expects), the process is computationally more expensive, but trades off neatly as the native opus decoder is very optimised
It also relegates the handling to FFmpeg, which simplifies existing code (more concretely, by using the "fill/drain" scheme for packets/frames)
Closes#2897
Signed-off-by: lizzie <lizzie@eden-emu.dev>
Co-authored-by: crueter <crueter@eden-emu.dev>
Reviewed-on: https://git.eden-emu.dev/eden-emu/eden/pulls/4169
Reviewed-by: CamilleLaVey <camillelavey99@gmail.com>
Reviewed-by: Maufeat <sahyno1996@gmail.com>
crueter