RetroArch, CRT SwitchRes & Multiple Monitor Issue

General
#1

Hi, Apologies if this has been discussed already (I have had a search and can’t find anything), but is there a “fix” or configuration setup to remove the following issue I am experiencing:

I have set-up RetroArch (v1.7.4 Windows build) and configured VMM for CRT modelines. I have two monitors connected. Primary is a 1440p screen connected to my nVidia GPU, and secondary is a 15khz CRT connected to my ATI R9 280x.

Everything works OK apart from when I start RetroArch I need to ensure my CRT is the Main Display. If I don’t do this some weird resolution for RetroArch is used, which is extremely squished. This is a bit of pain as I’m sure you’ll appreciate. Also when I exit from RetroArch this goofs up the resolution on my CRT (looks like it’s running an out of spec resolution). So I have to go through a process of re-enabling an interlaced 640x480 display image.

Any help/guidance on this would be very much appreciated. :slight_smile:

#2

Does it help if you go to settings > video and set RetroArch to use a different monitor index?

#3

Hi,

It’s already set to the correct index, but doesn’t stop me having to set the CRT as my primary monitor. :frowning:

#4

What is your setup? CRTEmudriver?

Windows should work fine by dragging RetroArch onto the screen that you want when it is in windowed mode. Then full screen it. From that point forth it should always be full screen on that screen.

However, currently RetroArch only enumerates the primary display to find the resolutions. I will add this to my list for the next update.

@hunterk Where can I pull the variable for the menu item monitor index?

Cheers

2 Likes
#5

Hi, Windows 10, CRT Emudriver (latest version) and retroarch 1.7.4

I’m pretty sure I’ve tried what you’ve suggested but I will try again.

I found another thread elsewhere and the conclusion was that you needed to make the CRT the main display. As soon as I did that retroarch and games displayed as expected. It’s just a bit of a pain.

#6

Hi @Alphanu

Thanks for creating the CRT switchres support, it’s fabulous :smiley:

I’ve also created a setup with CRT emudriver and super resolutions, pure bliss. I do have two minor issues that I want to let you know.

First is that I’m also experiencing the same issue that faginrs500 posted about, I have to make the CRT the primary display to make it work correctly. Indeed a bit of a pain when using dual monitor setup, one CRT and one LCD as any programs (file manager, browser etc, open on the CRT instead of the LCD) Luckily I see you’ll be addressing this already.

Personally I think this is a deeper underlying issue in Retroarch / libretro, as I’ve also always been experiencing vsync issues in my dual LCD setup when the refresh rates of them differ and RA is not on the primary display. In that case all seems well when RA is not on the primary, but there are vsync stutters etc every now and then that may go unnoticed by many but they’re there. Only solution is to have RA on the primary.

All in all I hope you can fix this issue of RA needing to be on the primary display for proper vsync operation in the underlying code for RA and not just for CRT switchres. I believe hunterk is aware of this issue in RA, as I’ve seen him occasionally recommend to people with vsync issues to make sure RA is on the primary screen.

The other issue with CRT switchres I’m experiencing is the switching between interlaced and progressive. I’m having the issue that when using the “gl” driver AND when my desktop is in interlaced that 1 (below) works but 2 not:

GL driver with desktop in 640x480 interlaced:

  1. psx driver switches to progressive on first boot: works
  2. psx driver switches from progressive to interlaced: does not work. (Half of) the interlaced desktop is shown and top half is occupied by RA. Audio is really crackling also.

Case 1 and 2 do both work correctly when:

  1. desktop is set to a progressive mode
  2. using the D3D11 driver (doesn’t matter if desktop is in progressive or interlaced, psx driver switching progressive/interlaced always works correct).

So my issue is purely when using the GL driver AND the desktop is in interlaced: progressive <-> laced switching will not work correctly. This is an issue for me because I need the desktop to be interlaced to properly work with file manager / browser / frontend etc when in standalone CRT setup. I also don’t want to use the D3D11 driver as the GL driver has more tight swapping behaviour (less input lag). Vulkan does not work with the CRT emudriver version I’m using (Crimson 16.2.1 for non GCN cards).

Hopefully this issue can be fixed. In case this is a GL driver issue with the 16.2.1 crt emudriver for non-gcn cards, would it be possible to add a user option in the menu to enable/disable progressive-laced switching? (I.e. only have it do resolution switching between progressive modes; maybe in some cases this may be a welcome addition anyway?)

#7

The interlaced issue is with windows. What version are you using? Calamity has released a patch for windows for this reason. You could try and install this and see if it helps.

it could also be to do with your video card. the best cards to use are HD5xxx series.

There are many bugs that I have to sort out, I will get around to them but I don’t have as much time on my hands as I used to.

#8

I’m using Windows 10 x64 with latest updates. The card is a HD6850.

The particular thing is that progressive<->interlaced switching -when desktop is interlaced - works fine when using CRT switchres and the D3D11 driver in RA. The issue occurs with GL only.

I wanted to use / try that interlace patcher, but read a post in the groovymame forums that it doesnt work with the W10 1803 file (calamity answered he would look into it), so havent tried it yet. I’ll give it a go certainly when it gets updated.

Would it make sense to make a switch in RA thats allows to disable progressive to laced switching? Mainly as a fallback as resolution switching seems mostly prone to issues when interlaced is involved.

Maybe you find this interesting, but i also tried a cheap hdmi-vga adapter on another setup (has an nvidia card with only digital outputs) and created some resolutions with CRU. And it works nicely with CRT switchres also.

With that hdmi-vga adapter strangely when adding 640x480i / 2560x480i (interlaced) it will not show up, but when I add something like 2560x488i (interlaced) it will show up. In the end not as good as emudriver, but I guess it may be interesting in some situations. I couldn’t test the psx switching fully with this since it looks for 480i and not 488i. Perhaps in a future you could add a feature that looks for the closest bigger y-res in that case.

No worries about the time, it’s more important to keep family life balanced for sure. The time you’ve already spent on this is highly appreciated.

#9

The vsync -> primary display issue isn’t a problem with RetroArch, it’s just how PCs work. Monitors have slightly different refresh rates and the GPU has to pick one of them, which it does based on which display is the primary.

#10

Sorry Hunterk, but that statement is very wrong. The GPU does not decide by itself whatsoever, it’s the application that is in charge of correctly enumerating all available display adapters and getting the modelist for every single adapter. RA only enumerates the primary, which is why the vsync / resolution switching is going haywire when RA is not on the primary display.

When properly implemented an application enumerates ALL available display adapters, then gets the modelist for each adapter and then correctly sets both the display adapter and the mode for that display adapter based on what the user configures.

It has been the whole point in GroovyMAME for the -screen parameter, which can be set to \\.\DISPLAY1 or \\.\DISPLAY2 etc to target the correct monitor, get the correct modelist from that adapter (and not the generic list from the primary), then set a mode for that specific monitor and as a result get the correct vsync signal from that mode on the specific display adapter.

I think the RA implementation is simply lacking in this department.

If you’re interested in how GroovyMAME does this for D3D9Ex, you only need to take a look at the GroovyMAME patches / diffs available here: GroovyMAME diff , and look for things like EnumAdapterModesEx, GetAdapterModeCountEx and the like.

I hope you guys can support @Alphanu with this, as he seems to have the intention and understanding to correct this long standing issue with Retroarch. (Not entirely sure about GL, but at least for D3D11 and Vulkan).

#11

Yes you are right @rafan. When I originally programmed the windows switching. There was no need for multiple displays. It was more designed for an arcade system or stand alone PC console. Defiantly an oversight on my behalf. I do know what needs to be done to include enumerating etrxa displays. However, when I moved on to Linux switching I removed my windows install.

So before I can start work on it I will need to get a windows system up and running again. Due to my limited time these days with work and family. I can’t guarantee how long this will take me. Sorry.

On a plus side I have been working with an osiliscope more. Now most if not all cores match the exact 15hkz signal as the original hardware.

1 Like
#12

No worries, I just hope somewhere down the road this gets fixed. Luckily the barrier (timewise) to reinstall Windows is quite different from say 10 years ago. I remember sometimes planning whole saturdays or weekends even back then to get a basic install with drivers, apps etc working. How times have changed :slight_smile:

Could you elaborate a bit on that? Have you been fixing up cores for them to report the correct rates? I know a number of them report wrong rates versus what the core (and real hardware) really runs at.

Apart from looking up / calculating the correct values from the hardware manuals, there’s a little trick to filter out ones that set/report wrong rates. If you enable “Onscreen Display -> Onscreen Notifications -> Display Statistics”, then for those that are wrong the “Average Buffer Saturation” under Audio Statistics will not average out at 50%, but for example average out a 65%-68%. Mostly this is the case for cores that have bluntly been set to 60.0Hz, whereas the core (and real hardware) runs really at a progressive long or short field rate of like 59.92xxx or 60.08xxx, as an example.

My assumption is that an incorrect rate also creates an incorrect audio skew that RA sets on startup of a core, leading to detrimental performance (as RA has a mechanism that does very fine resampling of audio when the buffer is nearing over- or underruns).

#13

Hello everybody, first of all thank you very much for your work with CRT resolutions implementation which dramatically raised my interest in Retroarch and for your support.

In the last couple of years I successfully managed to set several emus working at native resolutions (or “super resolutions”) on my “retro PC +PAL TV” (Snes9x, Mame, MagicEngine, Mess, Project64, Fuse, WinUAE, WinVice, ePSXE)

Before bothering you, I did a lot of trial and error with parameters, read documentation and several forum threads, googled for ideas and suggestions but unfortunately I’m not able to display games @ native resolutions with RA (tried Megadrive, Mednafen PSX, Stella and Fuse Cores).

I always notice interlaced resolution (presumably desktop setting 640x480i)

As last chance, I tried set monitor index = 1 with no luck.

My system

Windows 7 PRO 64bit CRT Emudriver 2.0beta ATI Radeon HD5770 TV Sony Trinitron PAL 50Hz as exclusive display (no additional LCD monitor) DMI->VGA TO RGB SCART Cable desktop resolution 640x480 interlaced common low-res modelines installed and working (320x240 etc) super resolution (2560x various vertical resolutions) installed and working

RA Settings \ Video Options CRT SwitchRes ON Monitor Index 1 (also tried “0 auto”) Start in fullscreen Mode ON (also tried off) vertical refresh rate 50.000 Hz (pre-set) Set Display Reported Refresh Rate 100.000 Hz Aspect Ratio CUSTOM (also tried Core provided) Custom Aspect Ratio Width 616 Custom Aspect Height 467 Integer Scale OFF Threaded Video ? Vertical Sync ON Adaptive Vsync OFF Hard GPU Sync OFF Black Frame Insertion OFF

retroarch.cfg parameters

crt_switch_resolution = “0” crt_switch_resolution super = “0” (also tried “2560”) crt_switch_resolution_use_custom_refresh_rate = “false” (also tried “true”) crt_video_refresh_rate = “50.833000” (manual set) current resoution id = “0”

Are these settings correct to display a progressive resolution on CRT? Probably I made a little bit of a mess…how can I set exact vfreq for each system (using override cores.cfg)? Any suggestion to make it work?

Thank you in advance.

#14

Each system will send the refresh rate to the CRT Switres core. So tgere is no need to manually set this.

The main thing that pops out is that you need CRT_switch_reolution = 1

This can all be set from within the Retroarch menu RGUI. But you need to enable advanced options in user interface.

#15

Thank to your suggestions, I succeded in having native resolutions @50 Hz with specific cores:

settings Activated Advanced Menu Activated RGUI

CRT Switchres 15 KHz RESOLUTION NATIVE CUSTOM REFRESH RATE OFF ASPECT RATIO CORE PROVIDED

and IMPORTANT FULLSCREEN WIDTH 640 FULLSCREEN HEIGHT 480

Thank you very much for your support Alphanu. Now the question part.

native resolution@50KHz is working for: Snes9x, Fceux, Sega Geneis Plus GX, Commodore 64 (Vice), Spectrum (Fuse)

not working (still interlaced): Intellivision (FreeIntv), Sony PSX Mednafen (runs @60KHz interlaced 640x480 USA isos. black screen for European ISOS). Nec Turbografx runs @60. Atari Stella, Gameboy Gambatte are interlaced. I suppose this depends on original vfreq of the consoles/games (core informations provides pre-set vfreq). Can I manually set the options for obtaining 240p for 60KHz platforms too?

Thanks.

#16

60hz does work as well. the PlayStation bios is meant to be 640x480. If resolutions are not working it is a case of the resolutions not being installed.

#17

I managed to use super resolutions (2560) with

Aspect Ratio = Core Provided or Custom

Custom Aspect Ratio Width = 640 (2x)

Custom Aspect Ratio Height = 480 (2x)

Integer Scale = ON

but I can’t achieve progressive mode with PSX Beetle, NEC Beetle SGX, FreeIntv, Stella, Sameboy and many others.

I tried with Use Custom Refresh Rate = ON (True) and, for example, Vertical Refresh Rate = 49.759998 (for PSX) Crop Overscan = ON or OFF

Using Beetle PSX, the games (European or USA version) are still displayed in interlaced mode (regularly working, no black screen).

PCSX ReArmed core runs European games @240p without hassle (both in Native or 2560) USA games runs @480i.

I checked all PSX BIOS files.

*In different threads I read that using Aspect Ratio = Core Provided

resolution should switch when the games require it to change but I never see anything different than 480i. BIOS is 640x480 ok but menus, videos and in-game run @480i as well

I also need to set vsync = OFF to avoid heavy audio clipping

You say that “if resolutions are not working it is a case of the resolutions not being installed”… this is correct for sure but now I’m a little confused: I have all PAL 2560 modelines installed (vertical 232, 240, 264, 288, 480, 576 and so on) and I have progressive resolutions working perfectly in ePSXe, WinUAE, Mess and other emus .

I read your CRT guide thread and I understand I’m missing all NTSC modelines so I’ll try to install 60Hz modelines too adding them to existing 50Hz modelines but it’s not straightforward to me why these could be mandatory for RA and not for other emulators.

Excuse me for bothering you, I wish to adopt RA as a standard in my retroPC and I’m trying to understand how it works. I’m aware it depends on my lack of knowledge and it’snot a RA architecture fault. Thank you for patience.

#18

OK, so PlayStation is an awkward one. It is the same in the Saturn emulator as well.

Firstly I see that you don’t have 224 or 448 resolutions installed. However, the most important part is that these emulators Beetle PSX and Beetle Saturn have hard set vertical heights. these can be changed in the core options. you need to set them so that they match the correct resolution e.g. 16 - 272 this will give you 256p. the difference between them creates the resolution. This will have to match a resolution you have installed.

The annoyance here is that this is not how the original hardware does it! In the original hardware the vertical height changes. However, This is something that the core authors either don’t know about or don’t wish to implement.

I have mentioned many times in the past about Linux. This is because each resolution is installed and removed on the fly. So if you are using the PC just for RA then that could be you better option. This is because currently RA CRTSwitchRes is limited to pre-installed resolution on a Windows environment.

There is a trick to the audio issue. You need to turn audio sync off and manually set the skew to 0.05

#19

Alphanu, I can’t thank you enough for you reply but I’m not able to solve. Audio workaround doesn’t seem to work (skew seems to be 0.05 by default). Audio is scrambled in NEC Turbografx too (I suppose it’s the difference between original vfreq of the games (U)(J) and my PC’s PAL vfreq.

Also wasn’t able to find vertical heights settings in core options (there are only 4 options: "Enable hardware shared context, Load Dummy on core shutdown, check for missing firmware, allow rotation). I managed somehow to reach 240p display with Mednafen PSX but RA is unstable (rGUI squeezes and becomes unreadable even in window mode)

#20

You will not get the correct resolutions with PSx rearmed. You need to use Beetle PSx (Mednafen). if you end up with a squished screen it is because the resolution is not installed.

Load Retroarch, turn CRTswitchres off. Load Beetle/ Mednafen PSX witha ROM/ISO. Once loaded pres F1. choose options then change initial scanline and last scanline to match 240p or 224p. Also which I think I may have forgotten to say, disable overscan. TO be fair its a bit of black magic with windows.

I would and have always suggested that Linux is the best environment to run this on!

Did you disable audio sync? is so then maybe change it to 0.00 and then change the option below it to 0.5 instead.

All my work recently has been on Linux. So Windows has kind of been left behind due to its limitations. And its been a while since Ive used it.