RetroArch - Native CRT Support


Is this on Windows or Linux?


I am using Linux. After building from the latest commit of MME4CRT, RetroArch shows only a black screen on startup. Tried switching video drivers and using a new retroarch.cfg, but I get the same result.


Hi @soulnet

There are a few bugs that still need working out here. What games and cores have you tried and more importantly that hardware are you running. A lot of things are fixed on my git but have not been merged yet.

Http:// give it a try and let me know how you get on.


After compiling the MME4CRT_GA fork, the gl video driver seems to be working correctly. I was only able to test a few games with the beetle_psx core, but had no problems. I look forward to testing more cores this weekend when I have more time. Great work Alphanu


Hey @Harrytoons

I am from the UK but my issue is space, I looking for a small 31khz CRT. If you can help out with that, that would be great.

To be fair I am still sorting out a few bug with Linux anyway so there is no real rush for one.


I also have a 31khz CRT I can test with when the time comes if you need any help


Just to clarify, by 31khz support do you mean that if the resolution for a game were 2560 x 224 on 15khz, the res would be automatically switched to 2560 x 448 on a 31khz monitor? (similar to how groovymame handles 31khz)

If this is the case, I would be happy to help you test this, as I have a couple of 31 khz monitors.


Just wanted to pop by and first say thanks for working on this.

I wanted to say that I’m seeing the same issue soulnet saw in Linux. I’m using the main RetroArch nightly from 05/20/18 I’m actually on Windows and my machine is an old laptop with an A6 APU that has the CRT_Emudriver V2 installed. I added all the suggested super resolutions including the PAL ones. I’m seeing 2 issues:

  1. Using the GL driver when I first open RetroArch, it seems to freeze for about 5 seconds. It also will freeze for 5 seconds or so when changing a resolution while a core is running. Using D3D11, I don’t see this issue. This is most noticeable when starting a PSX game. Everything works, it’s just slow using the GL driver due to the pause after a res switch.
  2. After opening a 2nd game from the same core/res the resolution switches back to the interlaced menu resolution. The game is then interlaced and in the wrong aspect ratio. If I goto “close content” before opening a 2nd game then I don’t have any issue. Also I tried a fresh config and then later a fresh config and install just to make sure I didn’t have some setting wrong. This also appeared for me when using both GL and D3D11.

I’ll try to see if compiling your branch fixes the issue for me as well but wanted to corroborate that I saw something similar. I’ll probably just switch over to your fork anyways since I really like this feature. Thanks again.


Would someone tell me how to build the linux patched the 15khz,it is too difficult to use the linuxmint and ubuntu. I succeed in win7 and the groovymame is nice.but the retroarch is not perfect. Must I install the xf86-video-ati? I have fond three kind of 15khz patch but I dont konw which one is right.


@yuuyuubaishu You don’t need a patched kernel to run it. The kernel patch is just to be able to see the boot screen. All you need to do is set a desktop res on boot with xrandr. However, you can use the Groveyarcade ISO, its Linux Arch but with a pre-patched kernel once setup you will need to go to ga-setup and change the options to load the desktop environment instead of whacade.


I’m not sure why this would introduce any freezing or delay when switch. Turn off the option to pause in background. I know that on slower machines there is a delay in loading the core and game for cores like bsnes.

For note 2 there was an issue that caused this way back as well as aspect problems when staying in the same core. but it was fixed. The only reason for resolutions not switching correctly would be that there not installed. what cores and games have you noticed this on?


This is the idea. However, increasing the image size may have some unwanted effects . I am toying with some ideas, one being scanlines. Making them double size but not the rest!?

I have not done much work on it yet as I need to finish my end of module assignment first. its due the end of the month so I will start working on it then.


Cool, Keep an eye out here then. I’m not sure how long till a test release will be available though


thanks a lot! I wii give a try on my linuxmint with xrandr. I have the last groovyarcade iso and I don’t know if I can install retroarch and other software like the normal linux.


Thanks for the response. I looked into the first issue more and determined it has nothing to do with Switchres and happens whenever I go into exclusive fullscreen. It might just be a hardware/driver issue I have to live with for now.

I’m still seeing the 2nd issue. I tested with bsnes mercury and snes9x. I will load a game and everything is fine, I goto the menu, load content, select the exact same game and core, and it doesn’t change the resolution and starts in the same interlaced mode the menu was in. I’ll upload a video when I get a chance later.


First of all: Thank you so much for this @Alphanu! Being able to play Neo Geo games, amongst others, the way they should be with CRTSwitchRes, coupled with the new Low Latency-mode, has just turned Retroarch into retro-gold for me! Perfect quality output? Check! Lower input-lag than real hardware? Check! :smiley:

Some questions then. FYI I am running a fresh install of Retroarch with CRTSwitchRes at 2560p-resolutions and mode-lines:

  • Is it possible to force 480i-games into 240p instead? (I have only come across this with PSX games, a.k.a. Tekken 3 and the PSX logo intro). I get really bad performance when running interlaced, probably because of too slow GPU? (Radeon 4850). CPU should manage though (8700K). Any ideas?

  • As for now I can’t get Mupen64 core running, it instantly crashes Retroarch. Parallell core works, but seems a bit slow. Has anyone got Mupen64 running? Or tips on how to set up Parallell properly?

  • I understand the reason for expanding GB, GBC and GBA’s vertical resolutions to fill the screen but in most games I am not a fan of the vertical scrolling artifacts this introduces. Is there a way to launch them in a native 144p, or 160p instead? I would love to be able to switch between native and expanded on the fly :slight_smile:

  • Maybe noob question, but how can I find out the current active resolution after having launched a game? It would be good for troubleshooting.


If you want to force 240p for 480i content, then you don’t really need to have res-switching, just set your machine to [email protected] Hz modeline and be done.

If you have a very fast CPU, you can use the angrylion gfx plugin and cxd4 RSP plugin with ParaLLEl-N64 and get very accurate, authentic output.

Most GPUs won’t put out <200p, AFAIK. However, you can use the super game boy border shader to center it and fill up the dead space. I’m not sure how this interacts with res-switching but it’s what I’ve always done on my arcade monitor.


Since the whole point of CRTSwitchRes is to “allows the emulators to output the correct video resolutions and refresh rates as the original consoles and arcade hardware did”, isn’t the current method of handheld resolutions (not being integer scaled and thus looking “wrong” and introducing artifacts) kind off breaking the whole idea of this original intent? The Raspberry Pie Retropie cores can output 144p and 160p and looks nice, so I was just thinking that a Windows PC could do the same. But then I am not tech-savvy and like you say, maybe it is not possible? I would love having a choice if at all this is in fact possible.

EDIT: Just found this “240 x 160 @ 59.730000 GBA” in the documentation wiki so I guess it should work if I run native res.

I will try your PSX and N64 suggestions, thanks :slight_smile:


Hi @DatMonkey for cores like GBA you will want to turn integer scaling on. This should fix the horizontal artifact-ing. In most cases I am not doubling the resolution as this will not work for NTSC as your limited to 240p. Instead I draw the original image at its normal size within a 200p window. Only games that run below 120p are doubled, this is fine but the issue is that the horizontal scale does not work 100% without integer scale. So turn it on and just save a core override as it needs to be off for different cores.

On windows you can run the Arcade OSD software that comes with CRTemudriver. This will tell you the current resolution. ALT tab out of RA make sure you have created a shortcut on the desktop for Aracde OSD and just run it. On Linux switch to the desktop and load terminal and just run xrandr.

The reason to have integer scale off is because aspect ratios use floats so for resolution 258x224 the aspect ratio is 1.157857 or 11.428571 if using super resolution 2560x224. If you have integer scale on it will round this down to 1 or 11 respectively. I’m not sure if this is the intended behavior for RA but it is how it works. Giving you the incorrect aspect.

As @hunterk says in most cases you cannot get lower than 200p this is a Windows limitation, but also hardware limitations. Also I see you are using a 4850, this will also be an issue for you especially in interlaced. The best Radeon cards to use are 5xxx or above, Calamity mention’s this over at Arcade controls.

With that said Linux is another ball-game I am switching as low a 160p ATM and would assume lower is possible.

@hunterk @Abwezi @astos The current Linux version should work with current 31khz games at least MME4CRT_GA will. So if there are cores that run 31khz games someone could start some testing and let me know how it goes.

@Sir_Kevith I see you have mentioned bsnes with this issue. I have been doing a lot of testing with bsnes as I am going to submit an issue. It does not always report the correct resolution when loading a game, so the CRT code receives the wrong information. I am not yet sure what the cause is for it is, but I can defiantly say its an issue with bsnes. Thus far it happens with all the variants too.


@hunterk Once I am done with my EMA I will be porting the xrandr code used in Linux over to the XrandR.h library. Could you mention that to the devs, Just in case someone else was think or has started work on it.