TASEmulators
Have we reached the point of needing a bizhawk-minimal package?
The download size for BizHawk-win-x64 has doubled since 2.8, now surpassing 80 MiB compressed (see also #3505). I think that, starting with this next release (2.10.1), we should offer an alternate, stripped-down download option. Since #3937 has stalled, this would have to be in addition to the full build. But compared to the frontend code changes that I suspect will be required, preparing 3 or 4 builds instead of 2 is a trivial matter.
Open questions:
- Which cores to omit?
- The obvious answer is "the largest ones", which per
unzip -v archived.zip | sort -nk3would mean MAME, DOSBox-X, Encore, and UAE, and that's the download size halved. - I'd add that we could also omit the 3 cores planned for deletion, any cores for fantasy consoles (TIC-80, Uzem), subframe cores, and cores which only exist to emulate a few titles (DSDA-Doom, Emu83, PicoDrive, Virtual Boyee...). I haven't run the numbers but that's probably another 10 MiB at least.
- The obvious answer is "the largest ones", which per
- Name?
- I have some notes from earlier, but tl;dr I'd be fine with the conventional
-minsuffix.
- I have some notes from earlier, but tl;dr I'd be fine with the conventional
- Linux? Nix?
- I don't see why Linux users shouldn't be given the exact same choice. Most of them will be manually downloading still, not that it would be difficult to copy-paste a
-minpackage. - The Nix expression can be left as-is. When I get around to finishing unmanaged cores from-source, the override for that can also be used to remove core binaries. Frontend jank is acceptable in that case.
- I don't see why Linux users shouldn't be given the exact same choice. Most of them will be manually downloading still, not that it would be difficult to copy-paste a
"the largest ones", which per
unzip -v archived.zip | sort -nk3would mean MAME, DOSBox-X, Encore, and UAE
mupen is larger than UAE, if you include all its plugins, with the biggest contributor being GLideN64 (which itself is a must have for the core).
I'd add that we could also omit the 3 cores planned for deletion, any cores for fantasy consoles (TIC-80, Uzem), subframe cores, and cores which only exist to emulate a few titles (DSDA-Doom, Emu83, PicoDrive, Virtual Boyee...). I haven't run the numbers but that's probably another 10 MiB at least.
Combined the cores listed here are less than 5MiB. You're not saving that much by cutting those cores.
"the largest ones", which per
unzip -v archived.zip | sort -nk3would mean MAME, DOSBox-X, Encore, and UAEmupen is larger than UAE, if you include all its plugins, with the biggest contributor being GLideN64 (which itself is a must have for the core).
We can hardly omit Mupen though. Maybe we could omit the Rice, Glide64, and Glide64mk2 plugins.
Excluding largest non-essential cores probably makes sense, the only thing I see as required before making such a release is a system that handles these missing cores gracefully. We can just exclude core dlls from the release but it requires additional work so the user knows what's wrong when such a core fails to load.
Just a casual user here but i wouldnt omit picodrive. Its tiny and compliments the other Sega emulator cores.
If there are going to be two builds maybe have a version dedicated to the first 4 or 5 gens of console and then a version to the rest. A generation split might make sense?
Also snes cores there is the light and optimized snes9x cool, then bsnes 1.15+ cool but then two more cores. Is there need for all those snes cores for power users maybe?
