I don’t use gitub much so this may sound like a noob question but what is PR?
It stands for “pull request”. It’s basically just a diff patch submitted through github.
Ok guys. I’m really close to a finished product now.
Still a few bugs to iron out. One big one is turning CRT switching on from the menu.
Here is a little teaser showing the menu working.
Currently you can toggle CRT Switing on and off. The menu will display your super resolution, which you can set in the cfg. You should be able to set core overrides to use different superees. I plan to make superees choosable from the menu but not sure how yet!
At the end of the video I turn the CRT option off but as I was in a super res everything was squashed. But this show it being toggled.
As I said a few issues to tidy up yet.
1 Like
Is it possible for you to add the option of turning off refresh rate switching? Since it’s not possible to create the same resolution with refresh rate that is closer than 1hz, then on some cases changing the refresh rate will be less beneficial, even more so when dealing with super res. Edit: just read your post on the groovymame forum about the dynamic hz. Nevermind my request.
The hz that consoles use only send to vary by 0.3hz this is the case for PAL and NTSC. I’d you have 50hz and 60hz resolutions installed this would be close enough. Pal would normally be between 49.7 - 50.06 so you could average that and install mode lines with 49.88hz which means your only ever be 0.18hz out worst case. His would be similar for NTSC. I’m setting the games hz to match the original so the closer your CRTs hz the better.
Things get a little more in-depth when it comes to mame as some resolution will have 54hz or 57hz e.t.c this is because the resolutions are odd e.g arcade reolutuon can be 320 x 237 or 384 x 262. This is where dynamic or closest hzand closest resolution match comes in.
I believe that Mortal Kombat uses 320 x 237. I’ve been working on this some mane can be included in the resolution switching.
I attempting to create the ultimate All in One CRT emulation solution.
1 Like
I have been struggling with this for the last few days… I finally got CRT_Emudriver installed, but everytime I tried to run the new RA file, the resolution changed and my screen would never kick in…
I was actually getting farther with CRU resolutions for some reason…
Anyway, I figured out my problem. My CRT doesn’t support 15Khz.
- 1920x240 has to be at 120Hz for it to pull up.
- 1920x480 can be 60Hz, but of course with double the horizontal lines it’s at 31Khz.
So, mostly I am screwed lol.
What’s interesting is the latest file would actually take my 1024x768 resolution, switch it to the 1920x480 @60hz resolution from CRU, but then the resolution wouldn’t change to the 1920x240 @120hz resolution from CRU, instead just showing the half-horizontal-size image.
So, outside of adding 31Khz support to this… I don’t think there’s anything else of value I can add to this testing-wise, or get much out of usage wise 
If you are using a PC CRT monitor then just adding the interlace shader to most of your games at 480p should simulate interlaced and progressive switching pretty well. For 15khz CRT’s that will never be an option that’s really the biggest reason this is so helpful
Here’s a few testing updates as well. One important thing is that I’m finding this build seems to take a hit in performance. Testing side by side with my original retroarch.exe I’m receiving frame drops in places I wasn’t at all previously such as the DK64 and Animal Forest 64 intro, most other cores don’t seem to experience the slowdown but because N64 is so demanding it is very apparent there. The second thing I was able to notice was that I tested your fork that runs at 1920 super res side by side with the 2560 fork and there appears to be scaling artifacting issues
Here it is using the 1920 exe
Here is using the 2560 exe, same config with both
I did assume there would be a small overhead with my code. But it would be marginal. When it comes to N64 as you are aware angrylion is really, really, realy, unbelievably CPU hungry lol so I’m not surprised it notices there!.
The reason 2640 is the defacto super resolution is because nearly all horizontal resolution multiply to an exact integer to it. In the case of 1920 not so much. Again 3840 increases this change of exact multiplication too.
I would.say from all my tests and knowledge 2640 is the option you want too use.
Just to clear my mind. You have not noticed a slowdown in any other cores?
Correct I haven’t noticed that in the other cores
OK Guys I have submitted the PR. Hopefully soon this will be in mainstream Retroarch. 
3 Likes
I’ll leave it with the dev’s but if they decide not to put this in mainstream , I will release my fork.
One issue is that function placeholders will needed to be placed in other areas of the code to compile for other platforms like android and ps3.
@hunterk I have started looking into Linux, my core code should work great for switching. I need to create desktop resolution switching and x-server mode-line additions. But before I do I will need to setup my machine with a dual boot with Linux. This should not take too long though 
Here is a teaser of the pending release. I have incorporated mame resolution detection with a nearest set. as well as removing most of the overhead @Abwezi. Switching is super fast.
2 Likes
whew, looks great! I’m sure it’ll make it into mainline, it just may take a little bit of work to get it merge-able. No worries, though.
For linux, doing it all through xrandr is easy enough and we can add precalculated modelines for it all at once, but that won’t work for wayland or KMS. I’m not sure what the best way to deal with those guys is, but if we have to pick one or the other, my vote is for wayland/KMS.
Well all the switch info is generated within my CRT core code. This means it will send the resolution and hz to any function we choose to generate a resolution switch. Whether that be XRRScreenSize / XRRScreenConfiguration as long as mode-lines are available or xrandr --newmode / xrandr --addmode / xrandr --output.
To be honest its is 98% complete for any switching method, only small changes or additions will be needed.
Amazing work, man. Can’t wait to use the final version.
1 Like
Just a small update here. Still waiting for the devs to accept this switching version.
I have started work on the Linux version. Here is the video. Currently Retroarch looses focus on the resolution change. However, everything else is looking good.
3 Likes
Whew! I love it!
Btw, the merging should happen soon. There are a few other big PRs that we’re working through at the same time, but this one is in the queue.
EDIT: Here’s a good reference for using DRM for modesetting, which should work in KMS and wayland (and also X?): https://01.org/linuxgraphics/gfx-docs/drm/drm-mode-setting.html
2 Likes
Does this only work if you have a single graphics card? I have 2 screens and 2 GPUs. An Nvidia powers my LCD and an AMD powers my 15khz CRT. The CRT works fine with Switchres + Groovymame (Windows 7) so I know it works. I also have all the appropriate mode lines. However, I cannot get Retroarch to switch CRT resolutions correctly. I always appears squashed (like it’s applying the literal Super resolution). The only way I can get it to display correctly is if I enable 2560x224 (for example) on my desktop. Then I can’t really see the RetroArch menu properly, but the games load at the correct resolution.
If you have multiple monitors you would need to make sure retroarch is set to use the monitor you are using as your CRT in video settings. Also make sure integer scale is set to off.
I’ve also had issues with the retroarch.cfg becoming corrupt (before this codebase too) so try it with a fresh install of RA or just backup the cfg so it creates a new one.
My monitor is set correctly. The resolution just doesn’t switch. Going by what I read in the log files, it seems it’s trying to switch the resolution on the wrong GPU (the one that’s powering my LCD, not my CRT).