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

Improvement Request: HD Names as ''Save-Per-Game" name #33

Open
HoraceAndTheSpider opened this issue Aug 11, 2019 · 5 comments
Open

Improvement Request: HD Names as ''Save-Per-Game" name #33

HoraceAndTheSpider opened this issue Aug 11, 2019 · 5 comments

Comments

@HoraceAndTheSpider
Copy link

HoraceAndTheSpider commented Aug 11, 2019

So that this request doesnt get lost in another thread...

I beleive that the Save-Per-Game button works from a name dirived from the mounted ADF, at a guess.

For those of us using HD solutions, it would be nice if, when an ADF isnt mounted, it would attempt to use the name from any mounted Folder HD (Possibly HDFs already do this) - i see there is a Save Config for current HD and i am at a loss as to why these are seperate features, if the former isnt labelled as Save Config for current Floppy? (and why the latter gets placement on the front menu, but the former doesnt)

I was about to suggest that if both HD types are used (i.e. Folder vs. Image - if both were mounted) you would use the one mounted as the boot dir, but actually doesnt make sense, as you are possibly likely to 're use' a bootable drive, and put data (e.g. a WHDLoad game) into the other drive. Is it documented which would be used by Save Config for current HD ...

Thanks again

@rsn8887
Copy link
Owner

rsn8887 commented Aug 12, 2019

Think of the option Config: Save Per-Game on the main menu as Save-Per-Floppy if you want. It derives the config filename from the name of the disk inserted into df0:. The option is on the main menu because that's where floppy insertion is done.

Concerning the Save Config for current HD option in the HD menu: If Boot HD is set to Dir, it derives a config filename from HD Dir. If Boot HD is set to File1, it derives a config filename from HD File1.

This "One Boot HD Dir plus many separate data files, one per game" setup to load games you seem to be talking about is not really needed anymore IMO. It was often used in the old days when WHDLoad wasn't freeware and people couldn't share their keyfiles. They wanted to copy their personal keyfile to just one boot hd folder, not to every game. Since WHDLoad is freeware now, keyfiles are not needed anymore. It is now much easier to either use a game collection with one .hdf per game, like it is often used on RetroPi, or, my recommendation: use a setup with a few very large .hdf files (~1.9 Gb per .hdf, remember the file size limit), with all the games installed on them. Then use an Amiga-side menu system like Tinylauncher to select the game to launch. I find this setup most convenient.

@HoraceAndTheSpider
Copy link
Author

Unfortunately I have disagree that the boot + data isn’t preferable.

For some of us, there are so many reasons why individual game loading is preferable than an all-in-1 HDF, regardless of the keyfile or other shared items (Eg devs/kickstarts)

The Vita is a portable device, so users are looking for a quick, pick up and play experience.

Navigating a TinyLauncher or other menu system doesn’t provide this, it’s a much more preferable route to click a game and boot straight into it. This is why Fs-uae and Amiberry both provide single file (LHA) WHDLoad boot solutions built-in.

Many games may also have bespoke settings , for compatibility settings, custom control layouts (to avoid using the OSK as much as possible, or improving joystick/mouse choices) and even screen resizing to maximise the screen usage.

There there are shared slots for save-states which would be filled with various different games.

A per game HD Config name would also allow the reduction of memory setting on some game and the saving of card space when saving states.

I hope you will reconsider the user requirements in this area, based on the above considerations.

At present I am duplicating a lot of the files on a per game basis because everything needs to be self contained for each game, and is therefore also needlessly lengthy to set up.

@rsn8887
Copy link
Owner

rsn8887 commented Aug 13, 2019

I see. I will look into it.

You are right it took me quite a few hours to set up my tinylauncher hdf stuff using directory opus on WinUAE.

Are you on gbatemp or twitter so I can pm you?

Are you sure those other platforms do not simply extract lha into the host file system and run into those permission and file system limitations though? Easy check would be to try and launch a game with filename or folder name that is invalid on FAT32 but valid on Amiga, and see if it works in Amiberry.

@HoraceAndTheSpider
Copy link
Author

Sure, I’m the same handle as here on Twitter , although the user id is horaceandspider.

I’m fairly sure that the LHA is handled inside - I added the LHA selection of hd myself into Amiberry, and hunted for a long time to see where any extraction was happening - I never found it.

I know Batman WHDLoad used to have issues but might have even been corrected in the slave. I do know a site that has older WHDLoad packs though, so I will have a look at that.

I think it’s best to assume an HDF conversion (game specific) with a File/Folder based booter.... so possibly only minor adapatation to the save-game Config (ie re-use the hd Config Dave code, if no adf present) and some way of selecting that it will use the “not booting” hd for its name...

I will be looking at setting up a Vita dev environment in time, so I am not adverse to creating a pull-request once I’m past a few setup hurdles!

@rsn8887
Copy link
Owner

rsn8887 commented Aug 14, 2019

I followed you on twitter, if you follow me back I can send you some pm's about this stuff.

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

No branches or pull requests

2 participants