Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement a rudimentary core/dll download form #3937

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Morilli
Copy link
Collaborator

@Morilli Morilli commented Jun 4, 2024

This implements a very simple download form that can be used to download additional files into the dll directory, mainly intended to be used for large core downloads, such as the mame or encore cores. This, in addition to excluding those files from the release zips can help bring the initial download size of bizhawk down.

How it currently looks like (accessable from Tools->Download cores):
image

PRing for visibility and feedback. I think this could work as is, but probably needs additional support from the excluded cores to not feel bad when a user tries to load a ROM for a core that isn't downloaded and is then presented with an undecipherable error message.

Disclaimer: I do not take responsibility for the diff in Mainform.Designer.cs.

Check if completed:

src/BizHawk.Client.EmuHawk/CoreDownloaderForm.cs Outdated Show resolved Hide resolved
public partial class CoreDownloaderForm : Form
{
// TODO edit
private static readonly string BaseUrl = $"https://github.com/Morilli/BizHawk-extra/raw/{VersionInfo.MainVersion}/";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having FFmpeg in https://github.com/TASEmulators/ffmpeg-binaries makes sense because it doesn't change. Before hosting any core binaries in a GitHub repo like that, we need to plan ahead and decide on a versioning scheme, a way to check compatibility (in case it's downloaded manually), and an expiration date for URIs (#2235). We also need to decide how dev builds should behave.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, this is one of the things that need to be decided before this can work. In this implementation I was thinking of having a separate repository (just like ffmpeg-binaries) that hosts downloadable dlls for each released bizhawk version in a separate branch, so for release 2.9.2 you would have a 2.9.2 branch with the binaries from that release. Those would of course stay static after the release.

It would probably also be possible to fetch the binaries from the BizHawk repo itself using the release tag, but that feels a little more volatile in regards to future-proofness.
I see your point in that potentially breaking this download in the future because we don't control the url anymore would be bad, but I don't see how this case here differs from the ffmpeg download case.
Compatibility checking could be implemented but I personally wouldn't bother, because as long as we serve proper downloads compatibility should be guaranteed, and if people download stuff on their own, well, that's their own problem (you can already replace any non-bizhawk dlls and cores with different versions).

We also need to decide how dev builds should behave.

I say ignore that case completely, dev builds can stay being full-size downloads and one dev 2.9.2 has little meaning when it could span an entire year of changes, so those downloads don't need to work (or be valid working files) for dev builds.

src/BizHawk.Client.EmuHawk/MainForm.Designer.cs Outdated Show resolved Hide resolved
src/BizHawk.Client.EmuHawk/MainForm.cs Show resolved Hide resolved
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants