RetroArch - Native CRT Support


It selects the correct card when I use D3D9 as the video driver, but then I can’t use video_windowed_fullscreen = false (Retroarch crashes - don’t think it has anything to with resolution switching feature). So I need to use OpenGL (cards don’t have Vulkan support) and there’s no simple way to select the OpenGL renderer AFAIK.

I think the best thing for me would just be to try to figure out why Retroarch doesn’t like windowless fullscreen + Direct3D.


@ilitirit, does this same behavior occur under lakka?


This is amazing, thanks for your hard work.

Following ilitirit’s comments, I want to mention that I am also planning a 2-GPU setup, so I hope that use case can be well supported. With so many people using high-end Nvidia GPUs today (which are poor for low-res gaming), adding a cheap, secondary AMD Radeon for low-res support (that does not compromise high-end 3D applications) seems a natural workaround.

@ilitirit, this person mentions using Nirsoft’s Multi Monitor Tool to switch default monitors via command line. Is that relevant to your current issues? Guessing not, but thought I’d check.


I’m still not quite clear on @ilitirit’s issue, but I also currently use both an Nvidia and AMD GPU and seem to have everything working properly at this time. At one point when @Alphanu changed the method of resolution switching I had to make sure before I launched a game that I would set my CRT to the main Windows screen display instead of one of the secondary monitors of an “extended” display.


Simply put, my issue that the resolution does not change correctly when the setting is enabled.

I am not 100% sure of the cause, but I think it’s because my Nvidia Card is the default OpenGL renderer. I cannot use D3D + windowless fullscreen because for some reason Retroarch crashes (it does this on Alphanu’s build and others). I compiled my own version of Retroarch from Alphanu’s Git repo.

I have also tried setting my CRT to my main display. It does not work:

The resolution still does not switch correctly:

It is as if the height isn’t being set in relation to the “super res”. It kinda works if I use a “native” super res e.g. 384, 512 etc, but I’m still not sure the height is set correctly. I will add some logging statements later.

These are the cards I have installed:

As you can see, GPU Caps shows the Nvidia Card is the OpenGL renderer:


From the look of the running game, it seems that the auto aspect is not functioning. The only reason for this would be if you have your settings on custom aspect ratio. This setting will make things look incorrect. Use 1:1 PAR.

If your not sure about the resolution, press the windows key and load the CRTemu OSD to check the resolution that RA has switch too.

Have you installed the minimum required resolutions for native or superres? If no then the aspect will auto change but your resolution will not. Again causing something similar to what you are seeing.

Check your installed resolutions compared to the list at the bottom of the read me.


Why do you need to windowless? Myself and a few others I know still have this on default setting. It crashes for me when I try to use it too! What difference does this setting make?


My aspect ratio is set to Core Provided. I do have all the modelines in the readme.

I just tested SSF2TU using FB Alpha:

OpenGL - 2560 - Windowed FS = Stretched

OpenGL - 2560 - Windowless FS = Stretched

OpenGL - 384 - Windowed FS = Correct width, incorrect height (borders at top and bottom)

OpenGL - 384 - Windowless FS = Same as above

D3D crashes using any setting, however sometimes it loads depending (display is still stretched) on what my current video settings are. I didn’t test this too much because there are too many variables to control.

GroovyMame selects and displays correct resolution for SSFTU (2560x224).


Output of the log statements:

[INFO] crt_screen_setup_aspect called with 2560x224
[INFO] Setting refresh rate to: 60.000 Hz.
[INFO] height > 191
[INFO] switch_res_crt will be called with 2560x224
[INFO] [Config]: Saved new config to "C:\Retroarch\retroarch.cfg".
[INFO] Saved core options file to "C:\Retroarch\retroarch-core-options.cfg"
[INFO] [Video]: Does not have enough samples for monitor refresh rate estimation. Requires to run for at least 4096 frames.

I can’t see anything obvious wrong there.

I’m still thinking it’s got to do with having the wrong OpenGL rendering device, so I’m going to see if I can find some code that will switch the OpenGL device. At best it solves the issue, at worst it rules it out.

EDIT: Forgot to mention AR 1:1 PAR does not work either.


There is only one other thing I can think of. Check that you do not have any core overrides.

I’ve set this up on 3 machines now with no issues. However, they are only using 1 GPU. They have 2 GPUs in them but the ATI is default and only has 1 monitor connected, the CRT.


Ok guys I have a big update for Linux. However, I’m not sure how much longer it will be for the windows version to be released. I’ve not heard back from the dev team for about 10 days.

Any way I’ll show you this small video of the Linux version.

Now I am in KMS mode. However I am using xrandr for the mode setting. This is due to setting up the custom resolution in supe res. I have not looked into EDID to create custom configurations as I’m not to sure what I’m doing there. Anyway I’m rambling on. It is running really well except having some core issues.

I can’t seem to get bettle psx or Saturn to work. They throw up a time link error with Does anyone know what this issue might be? @hunterk


Hey @Alphanu, thanks for all the work on the res switching features. I love the idea of not having to configure custom aspect ratios for every core. The idea of having a RetroArch that functions similarly to GroovyMAME is awesome.

I’m having a bit of trouble however. Res switching seems to not trigger randomly. I’m trying to figure out what causes it, but it will work once and then it will run the game at 480i (2560x480?) the next time I try it, with the same game on the same core on the same settings.





I’m also not quite clear on what’s going on with the scaling for certain roms (GBA games on mGBA core for instance). It seems to be scaling based on a non-integer. I like to use the health bar in Mega Man games as a quick reference, and they look very garbled.

Also, how does this deal with 50hz games? Admittedly, the only one I want to play is the European version of Sonic CD for the music, but it runs much slower than it should. With the flexibility of being able to switch displaymodes as necessary, is there any way to run it at the intended speed?

Sorry to bombard with issues, I just wanna make sure I’m rigging everything up properly. I’m using the version compiled from your source. Again, thanks for all the work!


Make sure you have all the right resolutions installed as per the included text file because it sounds like you don’t. Where you have it working it’s probably just using the last successfully used res as the correct res is not available. This would be why sometimes it’s interlaced.

For GBA use integer scale and save core overrides. It’s a bit of an odd one due to the resolution of the original system.

Finally with regards to 50hz games, they will in a lot of cases (unless the programmers optimised the game code for PAL regions) run slower than 60hz as the refresh is that much slower. It’s accurate to the original hardware. The japanese version of sonic cd has the same music btw, no japanese text in game either so I’d load that if you want 60hz!


Oh man, I assumed the Japanese version ran at 50hz too for some reason. Great input on all counts. I was thinking that it resized as needed from 2560x240 res (that’s how I’ve always done it on a per-core basis), I didn’t realize it needed other vertical resolutions as well. I installed a few more and it’s working as intended now, thanks!


@Alphanu how did you get the cores? from the online updater or are you compiling them yourself? Which distro are you using?


@hunterk I have been downloading them from the online updater. I am running currently Ubuntu 14.04.


Ah, yeah, I think our buildbot has a different glibc or something.

These packages from the PPA should work. They’re built for Trusty:

It’s going to install the libraries into /usr/x86_64-whatever/lib/libretro but you can then cp them into your ~/.config/retroarch/cores/ directory.


@hunterk is this an issue with Ubuntu then or just trusty/14.04?


It’s a problem with distributing bare dynamic libraries without also bundling their dependencies (i.e., things they link against).

It’s just a thing that can happen when linking against libc, since trusty is super-old (and consequently, its libc is old) and our buildbot is newer. Since libretro cores don’t link against much, it usually isn’t a problem, it’s just the cores that do link against it break on distros that have a different version from the buildbot. Compiling yourself (or using builds for that specific release) sidesteps the issue.


Fair enough!

I have added these trusty cores but now I only get failed to load core?