RetroArch - Native CRT Support

Thanks Alphanu, I have xdotool and xrandr installed and retroarch says sh: 1: xrandr: not found sh: 1: xdotool: not found

That’s a strange one. I assume when your in terminal and run xrandr it works ok?

Have you tried running RA in super user mode?

yes xrandr works

When I try to run retroarch with sudo it does not start.

I think that retroarch 1.7.3 is not tested with the latest version of ubntu. It also does not detect the usb joistick.

Are you using the snap package, by chance? I doubt it’s going to work with res-switching due to snappy’s funky sandboxing stuff.

Thank you very much Hunterk,

Yes I am using the snap version, I will try the ppa version. What distro of linux you use?

I use Ubuntu and do most of the work on the snap package, which led me to suspect that’s what was going on.

Thank you very much again Hunterk,

With the ppa repository everything is fine in ubuntu 18.14. For the moment, I just tried the core of bsnes with the version of Supermario World ntsc. In the upper part of the tv there are some black lines.

Is there any way to vertically center the modeline without touching the TV settings using modeline generated in your code?

Can it be by touching a configuration file?

1 Like

I am still working on the modeline generator, it still needs some work but I am always working on it. I don’t think allowing people to edit these would be a good idea, even making a small incorrect change can cause porching issues or even the loss of sync. Can you upload a a image for me, it will help finalizing the generator.

Maybe in the future i will include some settings to make tiny adjustments, but at the moment I am concentrating on porting the code to 31khz, Lakka and correcting the generator.

3 Likes

Thanks Alphanu,

Her are some images om my crt KV-32FX60E. If you need some others please request me.

The tv has an option to centering horizontal position without entering in service mode and I have centered image in horizontal.

PCE: 1 or 2 lines black lines in the up:

MEGADRIVE/GENESIS: 1 or 2 lines black lines in the up: SATURN: 1 or 2 lines black lines in the up: SNES: haves about 7 black lines in the up. Left and Right wood frame is hidden.

The option for modify the modelines it could be configuration file that whill be hidden to normal users.

I found here a guide to modify modeline: https://arachnoid.com/modelines/

Thank you again.

In previous comments I read that I can disable vsync. When I disable vsinc, the scroll is less smooth. I’ve tested it with Sonic 2(MD) and Yoshis island(SNES) in ubuntu 18:04

In interlaced modes like psx bios emulation goes very slow. In same pc with lcd conf goes well. Satrun interlaced modes haves the same problem.

Yeah in some cases it can be disabled. Mainly Mame but you have to enable Mames frame throttle. In some other cores you can enable RA throttle to 1.0x and it does work quite well too.

@rares Thanks for the images, I was already aware snes had a bit of a vertical position issue. I is gonna to be one of the first things I fix once I’ve ported over to xrandr.h. The website you mention can be helpful but not always helpful Different CRTs handle porches differently from Sony PVMs to standard home B&Os and especially arcade CRTs. The idea is to get a best match situation doing on. I have 5 CRT that we are testing on an each time they give slightly different outputs.

Your Images show me that in most cases standard home CRT handle it better. However, my algorithm is still not 100% accurate YET!

There are fixes on my git if you want to compile, the changes should position things better. Aslo it fixes the aspect issues too.

its pretty easy to compile just follow this guide but replace the libretro git with mine.

https://docs.libretro.com/compilation/ubuntu/

1 Like

Hi,

I compiled from your source and have made a video with snes, megadrive and pce test suite.

I also test a saturn game but I have’t recorded the test.

In vertical all is ok. But in horizontal all systems goes to the left.

If you need i will make more videos and pictures with new compilations.

The 1st test is SNES

Sometimes when I change the game happens that you can see when game is changed and in the finish of the video. Retroarch loses focus and you can see the desktop of lubuntu 18.04. Sometimes I rescue the focus making random click with the mouse.

Regards.

@rares Thanks for the video.

I was on a little break from working on this recently, as I have had other important things to deal with.

Fear not! I am back :grinning:

I have some big news. Linux CRT switching has got even better. I have re-written my porch algorithm, as you can see from rares video things were not quite right. Now though things are looking great. I have built this around comparing to original hardware on the TV I am developing this on. So in short even if my TV is not calibrated correctly. The video the RA outputs is the same as the original hardware. And this is all in native resolution.

At the start of the video I am comparing real hardware to the new porch calculation on RA. I have to say it got to be 99.99% accurate :heart_eyes: Bear in mind that I am in the UK so I am comparing 50hz consoles with 50hz mode in RA. the video then shows a few 60hz games as well as 240p test suit.

So whats next. Well I don’t think I’ll ever be 100% happy with the outcome so I will always be tweaking these settings :sunglasses: But other than that I am moving forward with the 31khz mode as well as The RPi port.

F.Y.I the new porch algorithm seems to work lovely on my 2 CRTs, but we have some weird results on a Toshiba CRT. I’m not sure why yet but if you guys can do some testing that would be great.

5 Likes

Hi Alphanu

This is amazing!

I have two doubts:

1 - Will this new porch algorithm be available to Windows? 2 - Are you using native or superwide resolutions to get this 99.99% of accuracy?

Thanks!

Hi @purity1516

To answer the first question. It is simply no. With windows you need resolutions pre-installed, this means that the porches are already created by Calamity’s Vmmaker. Calamity has not shared how he uses dynamic resolutions yet. But it is something I’m looking into.

The video above is all native resolutions.

This new calculation is for native resolutions only. It uses the original width, height and hz to calculate. This will not work as well with super res as all widths are 2560 or what ever is used. However, I will be working on the super res version next.

I see.

As a Windows user, I hope that Calamity can share his dynamic resolutions algorithm.

Thanks for your great job!

Hello Everyone,

First of all, huge thanks to @Alphanu for this great work, a true stride forward.

I’m posting with the hopes that some light may be shed on an issue I have encountered with the Retroarch CRT Switch Res solution on my setup.

Background
I have been using GroovyMAME and CRT_emudriver for a number of years to output from my Windows 7 machine to a Mitsubishi XC-3315C successfully.

I have installed Alphanu’s list of suggested Super modelines, along with the list of Native modelines; in both combined and separate clean installs. I have successfully configured Retroarch to enable resolution switching, which it does sucessfully in both “2560” and “0” (native switching) modes.

Questions and issues
When booting a game, Retroarch’s notification informs me that it has set the refresh rate to “60.000hz”, this is the same for any and all game/cores loaded.

First question: Is this the intended behavior?

For example: I have/had tested @Alphanu’s early pre-mainline build posted to this thread in March 3, 2018, this older build, on launching a game, notifies that it has set the refresh rate to the actual-correct-for-core-refresh (ie. 60.099, 59.xxx, etc.). In any case, this build also suffers from the problems listed below.

Once loaded and displaying in the correct 15khz resolution, in all cores (multiple systems, resolutions, cores for tested systems), in both Super-Res and Native switch modes, my setup suffers either:

  • VSync OFF, Throttle 1.0x ON/OFF, Hard GPU Sync ON/OFF — Very noticeable stuttering
  • VSync ON, Throttle 1.0x ON/OFF, Hard GPU Sync ON/OFF — Consistent tearing. To try to describe: the raster offset slowly noticeably creeping up the screen from bottom to top during scrolling

I have tried, I believe, all combinations of relevant options in the Video settings. Tried manually tweaking the refresh rate in the Video settings to the hardware-correct numbers and arbitrary settings. As mentioned above, tried separate clean successful modeline installs of both Super-Res and Native lists.

Testing game for game, using say LTTP & Sonic 2 as examples: GroovyMAME displays perfect scrolling behavior.

Does this ring a bell to anyone? Have I overlooked something? Any insights much appreciated.

Thanks in advance.

I use xrandr to set desktop 640x480i on linuxmint. everything is ok using super-Res but the native switching is not available,someone would tell me how to make it work? which audio and video driver is the best ?udev or linuxraw? how can I enable kms?my graphics card is ati hd5450

@Victor bear with me here, I believe this is a native res bug. Do games sync properly in super res?

@yuuyuubaishu currently the only way to enable native res is to edit the retroarch.cfg. It is located in ~/.config/retroarch folder. Change the CRT switch resolution option to 0.

They do not, same issues in both Super and Native switch modes.