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

common settings for many cores #901

Open
jotego opened this issue May 16, 2024 · 5 comments
Open

common settings for many cores #901

jotego opened this issue May 16, 2024 · 5 comments

Comments

@jotego
Copy link
Member

jotego commented May 16, 2024

Although each arcade core is a different RBF file, many cores come from the same author and hence follow some common settings and OSD arrangements. The 57 RBF files I am maintaining have a consistent OSD interface and status word. But other authors, including those publishing in the mister-devel area, are also managing settings uniformly.

It would be convenient to provide some way for the user to enter common information for cores in the ini file. A good use case is the CRT adjustments. Even today, CRT users are about 50% of MiSTer users according to polls I run periodically. If you have a CRT that shifts the image to the left, you currently need to adjust each core manually and save settings. It would be convenient if users could do something like this in the ini file:

[author: jotego]
CRT H offset: +8

In this case the CRT H offset string comes directly from the cfgstr provided by the core. And the author name is listed in the MRA file. Using glob patterns for the core name could work too, at least for me:

[jt*]
CRT H offset: +8

But I do not care so much about these solution proposals. My point is that letting the user set common settings outside the list shown in the wiki would be very convenient. Is this already supported? If not, may I please request support for this?

@sorgelig
Copy link
Member

Do you mean, user is ready to play the arcade core but too lazy to enter OSD settings once?
MiSTer doesn't allow to manage the same settings from both INI and OSD. Settings are controlled in either one place or another, not both.

Besides that, there are already enough problems with settings. Users download packs with many settings pre-made, then come to me to complain that something misbehaves while it's simply some settings are changed.

It's better if core would load in default fail-safe settings at beginning, and if something is not right, then user will adjust. It's not a problem to adjust the settings in core you supposed to use.

@jotego
Copy link
Member Author

jotego commented May 17, 2024

I think that the user experience would be better if they adjust settings for their TV once for as many cores as possible.

A general way of being able to modify core settings in the ini file looks like a very convenient extension for everyone. Including people making download packs.

Thank for sharing your thoughts on this. I'll keep an eye open in case this is re-considered in the future.

@wickerwaka
Copy link
Contributor

I don't know if having them in the INI solves any problems and probably would create more confusion.

I do like the idea of the core config data being plain text instead of a blob of binary data. All the information is in the confstr to do it and it would make the config data more resilient to core changes. The CPU and diskspace costs aren't significant. If people did want to manage settings with some external script then it would be more practical with text than binary.

@sorgelig
Copy link
Member

Yes and no. Sometimes options get renamed or values added/deleted. This will give confusion too. While in blob, names aren't matter.

@birdybro
Copy link
Member

birdybro commented May 17, 2024

Regarding the cfg/blob discussion, couldn't you do it instead like this for instance --> https://github.com/MiSTer-devel/Arcade-Joust2_MiSTer/blob/master/Arcade-Joust2.sv#L214-L224

...
[2]Orientation=Horz
[5:3]Scandoubler FX=None
[9:8]Aspect ratio=[ARC1]
...

The names would be ignored by parsing, it's merely there for the user, just the status bits are considered by the program and the corresponding value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants