Retroarch: (Menu) CRT Switch Res Menu Options

Created on 14 Jul 2018  路  16Comments  路  Source: libretro/RetroArch

The current menu options for the CRT res-switching option don't cover the recent improvements. In fact, the new additions are probably sufficient to necessitate their own 'settings' submenu rather than cluttering up the 'video' submenu:

(copied from a forum post from @alphanu1 ):

Superres.

15 - 31khz 240p toggle.

Ouput ID and number. E.g. HDMI-1 or DVI-1 *

31khz compatability mode. Two or three options for hz.**

Custom refresh is sync does not work. E.g. 138hz. *

(it will speed up swithing and fix a resolution switch bug. This will only be needed for Linux.)

**A few pre-set porches to help centre and or sync the image

* used if pc monitor needs a different sync. Also for windows users when installing modlines through CRTEmudriver.

There may even be a couple more towards the end.

I think the custom refresh may need to be a on/off toggle that refers back to a config option for the specific number, as it may not be feasible/convenient to enter weird refresh rates manually via gamepad.

ui enhancement

Most helpful comment

The possible display IDs should be enumerated at runtime instead of including a whole bunch of ones many people don't even have. e.g. my laptop has none of the above IDs at all, because everything is DisplayPort.

All 16 comments

The options for superres should be 3840 2560 1920 or 0 where 0 means native. Currently.tge code base will ignore any ither value and native will be used.

I agree with the on/off toggle for the custom refresh options. It will make things simpler.

Let me know what other information you'll need or alternative options that you think should be used instated.

OK, how's this:

Option 1: CRT SwitchRes [IF EXISTING crt_switch_resolution BOOL IS TRUE, THIS SETS NEW crt_switch_31_khz BOOL TRUE/FALSE] - OFF / 15 kHz / 31 kHz
Subtitle 1: For CRT displays only. Attempts to use exact core/game resolution and refresh rate.

Option 2: Horiz. Res [EXISTING crt_switch_resolution_super NEEDS OPTIONS] - Native / 1920 / 2560 / 3840
Subtitle 2: Switch among native and ultrawide super resolutions.

Option 3: Output Display ID [LINUX ONLY - NEEDS NEW crt_switch_output_name ADDED AS CONFIG VAR] - HDMI-0 / HDMI-1 / HDMI-2 / HDMI-3 / DVI-0 / DVI-1 / DVI-2 / DVI-3 / VGA-0 / VGA-1 / VGA-2 / VGA-3 / Config
Subtitle 3: Select the output port connected to the CRT display.

Option 4: X-axis Centering [LINUX ONLY - NEEDS NEW crt_swich_center_adjust ADDED AS CONFIG VAR] - 0 / +1 / +2 / +3 / +4 / -4 / -3 / -2 / -1
Subtitle 4: Cycle through these options if the image is not centered properly on the display.

Option 5: Custom Refresh Rate [NEEDS crt_switch_custom_refresh ADDED AS CONFIG VAR; OVERRIDES video_refresh_rate WHEN crt_switch_resolution IS "TRUE"] - OFF / Config
Subtitle 5: Use a custom refresh rate specified in the config file if needed.

Yeah that looks good.

Option 1 will set the bool for CRT to true and toggle the bool for 31khz.

Option 2 should set the value of the resolution variable to said value or 0 for native option.

Options 3 should also incorporate 0 as it's number VGA-0 and config for any odd ID like DVI-I-1. These are rare but do exist and in some cases there is IDs such as VGA0. I think 0 - 3 will be OK, anything other can be config.

Option 4 should be left adjust 1 - 4 and right adjust 1 - 4. And used for both 15 and 31 khz. Also it will set a variable value from -4 - 4.

Option 5 will ignore detected hz and set its varable, video_refresh_rate and use the custom value globally. This is for extreme cases where the 31khz won't sync due to the pixel clock being too low. Mainly for 50hz pal low res or monitors that can't handle < 29khz. I think for now it should be it's own variable. If it can be merged with video_refresh_rate we can change it down the line.

Ok, I added some more notes. The output display ID is only needed on linux, right? no point in exposing it for Windows?

Linux only options are options 3 and 4. Agreed, there is no need to expose them for windows.

I am working on windows switching that does not rely on CRTEmudriver. Which would then mean option 4 would then pe applicable to windows. However, I don't have a current time line for this.

Are you waiting on the merge with the new features before adding these new menu options?

I think Twinaphex just hasn't gotten to it. I mentioned this thread to him in passing the other day, but I'll nudge him again.

No rush man. I was think more about the variables that will need to be added and weather I'll be doing it or him!

Plus it will be a little while till it's ready to merge.

I hope these configuration options get introduced soon, as this would allow me to test the implementation.

Additionally, I would like to request configuration settings for the sync signal to be implemented.

The current implementation sets "-hsync -vsync", but other configurations may be required in some settings.

Specifically, it's very desirable to have an option to turn on "CSync" instead of "HVSync" when the card allows this (most ATI/AMD cards seem to support this option). This would remove the need for a sync combiner in some scenarios, as well as increase compatibility with NTSC encoder ICs (such as the sony cxa series) and simplify cabling in others.

The possible options are

+/-HSync +/-HSync (for separate sync signals on pins 13 and 14 of vga connector)

CSync/+CSync/-CSync (for a composite sync signal on pin 13 of the vga connector, I'm pretty sure it's pin 13 and not 14.. but I can't recall exactly, and documentation is sparse)

Notice the CSync option can be set to three configurations, strangely.. I use +CSync and it works fine with my consumer ntsc set on a hd5450 (tested from a linux desktop running x11 using xrandr and a 240 snes-like modeline at native resolution).

I haven't tested the effect of applying the CSync option (without sign) after specifying the signs of the Hsync and Vsync settings, and there's no documentation about it. If that works it would be rad, but I'd need to take my system to my workplace to test the sync output on a scope.

Ok, for @twinaphex 's benefit, we need:

  • [x] A new menu in 'settings' called CRT Switch Res. We can move the existing CRT options here to clean up 'video'. This menu should be behind the advanced options toggle by default. The subtitle for the menu could be something like "Output native, low-resolution signals for use with CRT displays". This entire menu can be behind an ifdef for linux || windows, as it doesn't work anywhere else.

Inside the new menu, we need:

  • [x] The current CRT SwitchRes option needs to go from a toggle to having 3 options: OFF / 15 kHz / 31 kHz. It needs a subtitle of: "For CRT displays only. Attempts to use exact core/game resolution and refresh rate."
    The option currently sets a bool, crt_switch_resolution. This could either change to accommodate the 3 options, or it could use a second nested bool to switch between 15 and 31 kHz. Up to you how to implement that.

  • [x] The current CRT Super Resolution option is not really usable from the menu. To be usable it needs options: Native / 1920 / 2560 / 3840. It needs a subtitle of "Switch among native and ultrawide super resolutions"
    This option corresponds to the config variable crt_switch_resolution_super.

  • [ ] A new option called "Output Display ID" with a subtitle of "Select the output port connected to the CRT display". This option needs possible values of HDMI-0 / HDMI-1 / HDMI-2 / HDMI-3 / DVI-0 / DVI-1 / DVI-2 / DVI-3 / VGA-0 / VGA-1 / VGA-2 / VGA-3 / Config. This option does not have any use in Windows and can be hidden behind an ifdef. As bparker mentions, it would be better if these names were enumerated at runtime instead of hardcoded.
    To work with this option, we also need a new config variable called crt_switch_output_name. If someone chooses the 'config' value here, it will pull the value from that config variable (for example, some people have weird device names like DVI-I-1 and we don't want to have to cover all of them directly in the menu)

  • [x] A new option called "X-axis Centering" with a subtitle of "Cycle through these options if the image is not centered properly on the display". It needs possible values of 0 / +1 / +2 / +3 / +4 / -4 / -3 / -2 / -1. This option also needs a new corresponding config variable called crt-switch_center_adjust.

  • [x] A new option called "Custom Refresh Rate" with a subtitle of "Use a custom refresh rate specified in the config file if needed". It needs possible values of OFF / Config.
    This option also needs a new corresponding config variable called crt_switch_custom_refresh.

The possible display IDs should be enumerated at runtime instead of including a whole bunch of ones many people don't even have. e.g. my laptop has none of the above IDs at all, because everything is DisplayPort.

@bparker06 @hizzlekizzle @twinaphex

I do agree with bparker06 on this! As you know the current code is not using randr source, instead it uses the external application xrandr. The aim is to eventual port this over to xrandr.h so the external program will not be needed. However, work life and family take up a fair amount of my time, so it may be a while until I get that done.

So at the moment we need some form of ID implementation. This will work two fold as well. For people that have multiple displays connected, we will only wont to switch 1 of the displays, the 15khz or 31khz CRT. Not all connected displays, including the internal eDP.

My suggestion at this point then, would be to have only the ID name as a choice i.e. HDMI, DVI, VGA, DiplayPort and config. This can then be cycled to find the number associated with it. and the config used for any odd display IDs like the ones with a -I after the ID name.

I am currently working out automatic modelines for windows now as well. So Options 4 will need to be for both.

I suggest there should be one more option in the CRT submenu, to configure Sync output.

Default could be "+HSync +VSync", and selectable options would be "-HSync -VSync", "+Csync", "-Csync", and perhaps a "Custom" (to be loaded from the cfg file, for situations that require mixed sync conditions).

If the "Custom" option is not possible, then there should be more options in this setting (-HSync +VSync, +HSync -Vsync).

Was this page helpful?
0 / 5 - 0 ratings