Override configuration based on video mode #567
Conversation
|
When you add a feature, don't rewrite the whole code. Remove all stl code, please. |
|
Thanks for looking at this and responding. What do you think about doing this by reloading the configuration file, like how the core sections work? I think that would meet your requirements. Do you see a problem with doing that every time the video mode changes? |
|
if there is no resolution sections used then code should avoid to reload of INI, so it should work exactly as before changes, so users not using this feature won't be affected by any possible side effect. Reloading ini gives some latency in processing of other FPGA requests and input devices. If core will change resolution together with some other events (like reading CD data) then it may impact the work. I cannot tell how it will affect the work in reality... |
Configuration options can now be overridden based on the core's video mode. The config parser now supports sections with names in the format "video=WIDTHxHEIGHT[@VREFRESH]". When a core changes video mode, MiSTer reloads the config file and checks for a section matching the new mode. If one is found, the options in the section override options in the MiSTer/core sections. MiSTer will look for a section matching the width, height, and vertical refresh rate first. If none is found, it will fall back to a section matching the width and height but not specifying a refresh rate. If there is still no match, no overrides will be used. Also, VREFRESH must match exactly the output from video_info or the logs. To match 720x400 31.48KHz 70.1Hz, the section title would need to be [video=720x400@70.1].
|
Thanks - I was worried about impacting users who are not using the feature, so that's a great idea. I just pushed a version that works by reloading INI and only reloads if there were video sections in the initial load. Where possible, I tried to make it consistent with the way the core sections work. Please let me know if you have any other thoughts. |
|
why HAS_VIDEO_SECTIONS and USING_VIDEO_SECTION added as possible options in ini? According to code they are calculated variables. |
|
Just to make use of the existing cfg interface, but I understand why that wouldn't be the right place for them. Here's a commit that moves them into separate variables. |
|
i didn't mean to move them. Just don't expose them into INI file would be fine. Anyway.. |
* Override configuration based on video mode Configuration options can now be overridden based on the core's video mode. The config parser now supports sections with names in the format "video=WIDTHxHEIGHT[@VREFRESH]". When a core changes video mode, MiSTer reloads the config file and checks for a section matching the new mode. If one is found, the options in the section override options in the MiSTer/core sections. MiSTer will look for a section matching the width, height, and vertical refresh rate first. If none is found, it will fall back to a section matching the width and height but not specifying a refresh rate. If there is still no match, no overrides will be used. Also, VREFRESH must match exactly the output from video_info or the logs. To match 720x400 31.48KHz 70.1Hz, the section title would need to be [video=720x400@70.1]. * Move video section variables out of cfg_t (changes from upstream commit f5fd16c)
* Override configuration based on video mode Configuration options can now be overridden based on the core's video mode. The config parser now supports sections with names in the format "video=WIDTHxHEIGHT[@VREFRESH]". When a core changes video mode, MiSTer reloads the config file and checks for a section matching the new mode. If one is found, the options in the section override options in the MiSTer/core sections. MiSTer will look for a section matching the width, height, and vertical refresh rate first. If none is found, it will fall back to a section matching the width and height but not specifying a refresh rate. If there is still no match, no overrides will be used. Also, VREFRESH must match exactly the output from video_info or the logs. To match 720x400 31.48KHz 70.1Hz, the section title would need to be [video=720x400@70.1]. * Move video section variables out of cfg_t
* Override configuration based on video mode Configuration options can now be overridden based on the core's video mode. The config parser now supports sections with names in the format "video=WIDTHxHEIGHT[@VREFRESH]". When a core changes video mode, MiSTer reloads the config file and checks for a section matching the new mode. If one is found, the options in the section override options in the MiSTer/core sections. MiSTer will look for a section matching the width, height, and vertical refresh rate first. If none is found, it will fall back to a section matching the width and height but not specifying a refresh rate. If there is still no match, no overrides will be used. Also, VREFRESH must match exactly the output from video_info or the logs. To match 720x400 31.48KHz 70.1Hz, the section title would need to be [video=720x400@70.1]. * Move video section variables out of cfg_t
This adds support for overriding configuration variables for specific video modes. The intended purpose is to support automatically switching to an output mode that is best-suited to the core's video mode. It's especially useful for letting CRTs do their own scaling for "rectangular pixel" modes like 320x200.
Overrides are specified at the end of MiSTer.ini in sections with names in the format
video=WIDTHxHEIGHT[@VREFRESH].For example:
When a core changes video mode, MiSTer checks for a configuration section matching the new mode and swaps in the new configuration if there is a match. Sections that match width, height, and vertical refresh rate take precedence. Then if there is no match, it looks for a section matching width and height but with no vertical refresh rate specified.
By the way, I tried to take a light touch with the changes to cfg.cpp, and one drawback is that it stores a copy of the entire cfg struct for each video mode override section... which is a bit wasteful. Let me know if you'd like me to take a different approach.