MME4CRT SR2(Switchres) - Huge Update. Most User Issues Resolved

General Development
#1

Current State of Implementation - Complete TESTING REQUIRED. Just need to clean up a few things :sunglasses:

Almost ready to ask this to be merged into RetroArch. Big things happening :wink:

Please read the readme.txt located here. Loads of testing has been done by a fantastic community. Its now time to pass this testing over to you guys.

  • Proper multi-monitor support for both Windows and Linux.
  • No more primary monitor issue. Resolutions will be checked on all connected devices.
  • Monitor index is now functioning correctly
  • Support for native, dynamic and 2560 super resolution.
  • Support for 31khz standard mode (doubling)
  • Support for 31KHz 120hz mode
  • Switchres.ini allows you to customize you setup if the standard options don’t work for you

Notes:-

  • Only enable 15KHz and native in the RA UI as the switchres.ini configures everything.
  • More UI options may be added in the future. So there is less to do in the switchres.ini
  • RGUI bug. For some reason RGUI returns a resolution of 4x4@60. You will notice RGUI not fitting the screen and scaling funny when you are in super resolutions.

Linux Source - Compile and run

Windows Binary 32 and 64 bit - Download and run

@hunterk any idea on this RGUI bug where it returns a resolution of 4x4@60? This would be good to fix.

8 Likes
New CRTSwitchRes update
CRTSwitchRes is going away. New CRT options now available
#2

Exciting stuff!

I don’t know what would be causing that RGUI res-detection issue :confused: Do you have any pics of it scaling wrong that I can show to some people for reference?

#3

I’ll try and get some picks later.

The scaling issue is related to switching to resolutions. I set an integrated scaleed width and hight based on the active resolution. Which then sets the aspect ratio. This only an issue when only RGUI is active with no content (first launch or after closing content) RGUI sends the width and hight as 4 x 4. The others send the screen resolution. If RGUI did that, I would be able to fix the scaling/aspect issue issue.

#4

Loading RA when in a super rsolutiom

Closing content when in a supper resolution.

Open the menu when in a core.

So as you can see. When RGUI does not have a core running. I am unable to fix the aspect ratio and the reported width and height is 4x4. However, when a core is running I am able to fix the scaling/aspect ratio bcasue there is a proper resolution to work from.

If RGUI can reported the screen width and hight of the system then active this would fix the issue.

#5

Had some spare time. SO here it is :sunglasses:

Monitor preset options 15/31KHz now active. Added new menu option.

Monitor presets can now be chosen from the RA UI. 15KHz and 31KHz will set arcade_15 and arcade_31 respectively. New option INI, if this is chosen your monitor preset will be selected from your switchres.ini file.

Hard set super resolutions now work from the UI too. 1920,2560 and 3840. However, keeping native and adjusting the switchres.ini will give you a better integer scaled width

1 Like
#6

I spoke to jdgleaver about it and after examining the issue, he suggested this:

What’s happening here is that the wrong parameters are being detected. the reported width and height is 4x4 This is the width and height of the current cached ‘content’ frame. It is only valid when content is running. When the menu is loaded with no content, this is nullified to a minimal dummy thing: video_driver_cached_frame_set(&dummy_pixels, 4, 4, 8); While the menu is alive (and when using RGUI), the menu dimensions are read via:

void gfx_display_get_fb_size(unsigned *fb_width,
       unsigned *fb_height, size_t *fb_pitch)

Basically, if (menu_driver_is_alive()) , then use gfx_display_get_fb_size() - otherwise, continue using the cached frame dimensions

#7

Hi, this new version is working fantastic :slightly_smiling_face: I simply copied my custom switchres mointor details from mame.ini into switchres.ini and everything I’ve run so far has worked well. The only thing I notice is that I need more sound buffer in order for sound to be stable (using wasapi… need 16-24ms of buffer for stable sound, previously I could get away with 0ms).

#8

If you were successfully setting it to 0 ms before, you weren’t really getting 0 ms, the driver was just ignoring your request and giving you whatever it felt like :stuck_out_tongue:

#9

thanks @hunterk. Although this did not give the the correct data it did point me in the correct diction.

gfx_display_get_fb_size() Kept giving me 320 240 no mater what the actual resolution was.

Instead I went with video_driver_get_size(&fb_width, &fb_height) which does give me the correct data.

1 Like
#10

Yeh, I figured I wasn’t that lucky :joy: I’m fairly new to RA if you couldn’t already tell.

To be more accurate; with a latency setting of 0ms previously, audio glitches were rare. Now I need a setting of around 16-24ms for sound to be (mostly) glitch-free.

#11

Also, is it possible to specify an exact 2560 super resolution on a per-game basis (when required)?

#12

@vagrant-17 you can do it on a core basis. Just set 2560 and then save a core override. Core overrides will only work if previous content is closed.

1 Like
#13

Hi everybody, Something I never understood : will it be possible to connect my PC, which has a modern graphic card (GTX 1080TI) with only hdmi port, to my CRT TV through an adaptator (hdmi to scart or anything else) and use Retroarch with CRTswitchres ? Thanks for answers

#14

You can get some hdmi to vga adaptors. But you’ll never get a true resolution with them.

Ideally, you need a card with an analog output like VGA or DVI-A

#15

It should work if you get something like the Ultimate Scart Adapter from Arcadeforge and then use a HDMI to VGA converter in addition to it. Also, it’s recommended to use Linux with Non-AMD cards.

#16

Thanks for your answers. I will try to hook my PVM. But, please confirm there is not any chance I damage it by sending by mistake a 1080P signal whereas it can only support 15 KHZ signal (240P) ? Thanks

#17

PVMs will simply not sync to the incompatible signal. It won’t damage them. Perhaps if you left it running the out-of-sync signal for a very long time (like hours/days), but even then I kinda doubt it.

#18

Hello, I switched over to the new version but have some overscan issues now that i can’t resolve via service menu?

When I try to fix the horizontal overscan via service menu, the picture gets cut off instead of “squished”…hope you can understand what I mean…I tried native and 2560 super resolutions.

I’m using Win7, CRTEmuDriver, UMSA, Consumer CRT from Philips

:edit:

Dolphin also has messed up geometry and too little overscan now. ;/ If i try to fix this via service menu for dolphin, SNES gets totally fucked up. :confused:

#19

You need to try different monitor profiles or create custom a crt range. You can find this info in the guide.

Also see here for the Swithres.ini guide

#21

Thanks for the links. Was using the arcade_15 standard profile for years and never had any problems with it…so kinda shocked that things are so fucked up now.

Regarding switchres.ini…whats the right location for windows? It doesnt say for windows in the guide.

I took some pictures to showcase my problem…for some reason PS1 games show proper overscan (fits perfectly as with 1.9.4) as before, so not sure if it really is a timing problem…

BSNES RA 1.9.4 - as you can see when i decrease Horizontal Overscan via service menu, the picture is not Cut

BSNES 194
BSNES 1941500×2666 515 KB

BSNES RA 1.9.5 - same screen/same settings and picture gets cut instead of “squished”

BSNES 195
BSNES 1951500×2666 484 KB

I tried fixing this with horizontal porch values but it is still just cut off if i move it towards the left

Dolphin RA 1.9.4. - perfectly fitting picture

Dolphin 194
Dolphin 1942666×1500 495 KB

Dolphin RA 1.9.5. - same screen/settings and overscan/geometry is messed up

Dolphin 195
Dolphin 1952666×1500 419 KB