RetroArch - Native CRT Support

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.

@Alphanu thanks for this! I used your latest linux native build and did some tests. Setup is a 20" sony pvm with a vga arcade 5000 (enhanced ati hd5450) on ubuntu 18.04, using native mode. the retroarch menu displays fine. on mednafen psx there is a big black border on the left (say 1/4th of the screen) as soon as the bios starts, meaning the image is shifted to the right so the right part is not visible. this also happens ingame. ingame later on with finalfantasy8 there are black borders on both sides left and right. also there is quite some white flickering when modes are switched. when using bsnes-performance with Seiken Densetsu 3, the image is at first perfect. but later on the black border on the left returns. When the sword fight starts the pictures is first perfect but then keeps switching back and forth to the resolution with the black border on the left. Also flickering on snes when modes are switched. When the camera flies over the world map the picture is perfect.

Some questions: could you list all necessary settings that MUST be enabled and disabled to test properly? I only found out to enable native mode, superres setting needs to be set to 0 in config file. It would be convenient to have all settings listed in the first post for example. Also could you make this work in KMS mode (text mode in ubuntu)? Emulation there runs at 100% speed, in desktop mode there is a lot of lag. So KMS would be a huge improvement in my opinion. Last question, does this work in KMS mode with EDID (native mode or superres)? Thanks!

Echoing previous sentiments, thanks for implementing this functionality @Alphanu

Initially I was having overscan issues with the left and right side of the screen in Genesis plus GX - enabling full borders in the options for the core seems to have solved this though - pointer if anyone else is having this problem.

I’ve pulled your MME4CRT_GA repo on Ubuntu 18.04 LTS and have been playing with it for the past couple of days, but I seem to be having issues with tearing which I can’t seem to resolve - different combinations of Vsync and hard GPU sync don’t seem to do much, although I think it seems to be worse with threaded video.

I’ve been using the intro to angel island from Sonic 3 as my test, due to the fast scrolling.

Occasionally on loading a ROM the core detects a refresh rate that is too high and runs far too fast - I’m wondering if detection is attempted possibly during the mode change and is upsetting the core/retroarch? I can only speculate since I don’t have any understanding of the code.

Does the choice of GPU matter in Linux? I know that Ati cards are generally recommended for Windows. I’m using a pretty basic Geforce GT 710, but the board I’m using does have an onboard Radeon, though it uses part of the system RAM as VRAM so I’d rather not use it.

Can anyone give me any pointers? Thanks :slight_smile: