RetroArch - Native CRT Support


I tested sonic2 just before I uploaded this version. Switching worked great. I’ll upload a video in a bit.

Are you sure you have the correct setting in Retroarch?


What is your setup foxhole? Works great for me using the latest crtemudriver and vmmaker using native resolutions. I don’t think this version has support for super resolutions yet.


@Retrorepair We might need to release a beta ini file to install requires resolutions. At least the ones we have so far.

I know once I have super resolution sorted it wont be needed, but it will help everyone during the testing stages. Plus its what everyone who wants native will need any way.

If you want the games to look as it should native is the way to go!


Like i said, native works perfectly for resolution switching in all cases, only having tearing issues. The issue with sonic 2 only happens with the Super build.


Ah didn’t realise there were two builds. @Foxhole what is your setup exactly? Crtemudriver? Can you post what modes you have installed?

@Alphanu yeah will sort that tomorrow. I maintain that a native mode option should be kept in though. It doesn’t hurt to have the option if they work.


Oh, OK that does make a difference. Super resolutions are only preliminary added, as i mentioned there is still a lot to add in.

Have you setup your native modes to use exact frequency e.g 49.701hz pal or 59.942hz ntsc genesis or have you set 50hz / 60hz?

I will be incorporation a sync matching algorithm but the theory is if you have the correct values running on your CRT it should not be needed. Are you passing 0 for the refresh rate in the Retroarch config? if so disable VSYNC an test. If not test with the correct Refresh given by ra_res_hz. This will be the refresh setting i’ll be editing on the fly.

Retroarch currently has a 0.2hz + / - window on its refresh setting, this means if its out by less than this much it will not correct it. This will deffo introduce tearing, at least they way we are using it. but when you set the refresh in the Retroarch config you will hard set the frequency.


I’m using crtemudriver. here are my modelines and retroarch configuration files. Configuration


I’ll try now your suggestions. Edit: tried your suggestions, and nothing. Same issue with the tearing. The thing is, it acts like vsync isn’t turned on at all. It only uses the audio for sync. If i turn off Audio Sync the game runs unthrottled at max speed. Second edit: With the original csr native build i didn’t have any vsync issues.


Looking at you mode-line things should work perfectly in native mode, which is what you have said. The main thing here is the refresh rate. I’m not sure if your ntsc refresh rates match the native rates. Make sure you check them against the ra_res file.

There is also a VSYNC option in the video settings.

I can see you have set a video_refresh_rate. its currently set to 60.002399 which means RA will always run at this rate no matter what. This should either be 0 or the exact refresh of your CRT’s refresh, hence the need for on the fly refresh switching.


I do appreciate all the testing being done guys. It is really helpful.


You know, i noticed in the native csr build, which doesn’t have any syncing issue, that if retroarch loses focus due to alt+tab or something else, then vsync no longer works and i get tearing until i restart retroarch completely. Is it possible that in the newer builds somehow retroarch loses focus during the resolution change?


I installed a new modeline with the closest refresh rate to the one in the ra_res, i got: 59.868 I tried changing the refresh in the config to 0 and the exact refresh rate and with both i’m still getting tearing issues. Funny thing is that with the native csr build, when the refresh is set to zero, i also get vsync issues, but when i set it to the exact refresh rate vsync works perfectly.


Just to be clear, am i the only one with tearing issues?


No your not, it’s likely the way the refresh is being manipulated at the moment is breaking retroarches dynamic refresh update.

It’s helpful to know it wasn’t just me tbh.


I also am recieving the screen tearing issues. I did move to the native resolution build, and progressive and interlaced switching does work however unlike w/ super resolutions


Hi guys.

@Foxhole @Retrorepair @Abwezi You were all right about VSYNC. I had managed to disable it while adding the new code. I found my error and have corrected it.

I feel native resolution switching is all but done. Really the only thing left here is to generate a full list if resolution needed. We have a INI for vmmaker that has the majority of them but not all.

I am now moving on to super resolution. The the next release for testing should have a more stable super resolution switching.

You’ll be able to see from this video that there is no more tearing. And that I am matching each game refresh to the CRT refresh.


Alphanu, i noticed from the video you used mednafen saturn core for testing. From my testing it outputs 352x240 for most of the time and adds borders to the sides, do you know how to deal with those borders? If i use Horizontal overscan mask to remove those borders then games that use the full 352 horizontal res will be cropped. Doesn’t the saturn operate mostly at 320x240?


There’s various issues with various emulators which need addressing separately. I’m not sure exactly what the resolution should be for saturn but I feel like this is going to be more a core issue than anything. It always picks 352 for the bios and I don’t feel like it should but again, I think that’s an issue for another thread.

The great thing about what we are doing here is that it is uncovering bugs in a lot of the cores that probably would have gone unnoticed before. The bsnes accuracy core for example always picks the wrong ntsc resolution on boot, but if it switches to a high res mode then it’ll pick the correct res when it switches back. This is definitely a core issue.


What´s happening here is fantastic. I will throw some cash into the bounty!

Will it be possible to have a 15khz lakka distribution?


Once the windows version is done, I will be moving on to a Linux build. Lakka is just a build of Linux so porting from Linux x86_64 to Raspberry Pi ARM should be pretty easy.

Once i have a stable windows build my main goal will be to port this to all devices that support a CRT.