RetroArch - Native CRT Support

Bounty Discussion
#116

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.

1 Like
#117

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?

#118

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.

#119

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

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

#120

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.

1 Like
#121

I also have this issue, this it what makes super resolutions so efficient. With Super Resolution configurations and Saturn and N64 I would normally set a game cfg remap with aspect ratio set to custom and set the horizontal viewport a little higher to something like 2680 or something so if the game and bios have a lot of overscan area they will still fill the screen. Then for games on those systems that don’t have a lot of overscan I just set the viewport to the whole 2560

#122

Another update on this project. I have done a lot of work on this over the weekend, I think I might take a small break lol

So super resolutions is where I was heading and I feel I have got a lot done.

Firstly I have incorporated aspect ratio correction for native resolution. This works great BTW, no need for custom CFGs anymore.

Secondly I have made good headway on super resolutions. Now to be honest with you, I’m not only using 4 - 8 resolutions, im using about 20 lol however, this is because I have not incorporated a nearest resolution matching yet. It’s a vast improvement on the 70 resolutions for native.

Finally game speed /FPS is synced to the original console rate, this is as long as the modeline resolution is within say 0.1hz.

I’ll post a video here for you guys to check out but I will not be uploading a version yet. There are a few bugs I want to iron out first. @Foxhole @Retrorepair @fogueman @SkyHighGam3r

5 Likes
#123

This looks very positive. I tried out both native and super resolution. Native worked but without vsync it made the images very jerky. Super resolution just gave me a ton of issues and I’m hoping the latest version can take care of some of the issues.

I know this is out of scope, but is everyone where using the CRT Emu Driver + VMMaker to get their resolutions? or is RetroArch simply looking at the modes available and chooses?

#124

Yep all of those issues are gone.

I believe most here are using crtemudriver + vmmaker, there are probably other methods to generate the modelines retroarch is looking for but crtemudriver is highly recommended

2 Likes
#125

OK guys,

Here it is. There are still a few kinks to iron out but I feel its defiantly ready for testing.

Before you start:- Backup any custom configs you have. rename you config folder. // No core overrides getting in the way Change your aspect ratio to 1:1 or core provided. // It can be anything really except config or custom. turn off Integer scaling. // This needs to be turned off as I i am sending floats for aspect correction.

While you change the above options the menu may look strange or shrink. just escape out and run again for things to start working.

This version starts Retroarch in 2560x480 so please make sure this mode line is installed, it should already be. If you come across something that does not look right, check the ra_res_hz.txt and make sure that the resolution is installed. As I said I have about 25 - 30 mode lines but I have also been testing PAL so many are duplicates in 50hz.

This version will auto set the aspect ratio to fit the viewport, while keep the correct resolution. there should be no tearing or juddering.

Let me know what issues you come across, so I can look into it. I am now starting work on the menu options and cleaning up the code. So if there are not too many issues with testing, a full release should not be to far away.

2 Likes
#126

I have already found a bug causing a fair amount of issues. It may not effect your is your system is powerful.

In short the ra_res_hz.txt file is being written to every frame oops :roll_eyes: I have just sorted this, but let me know how you get on with it as it stands.

2 Likes
#127

Congratulations man! Yor job is awesome!

1 Like
#128

It’s working perfectly so far with everything I’ve tested! Is there a possibility of a version that runs at 3840 wide instead of 2560?

1 Like
#129

I was wondering something similiar, like is there feasibly a way to change the horizontal resolution number for the super rez version? I use 1920 myself as my monitor doesn’t seem to want to go higher. (wider)

#130

When I incorporate the menu options you’ll be able to choose 3840, 2560 or 1920 as well as native.

I’m glad all is working well. I have incorporated some doubling for low res cores like GBA so they can be played fu screen instead of just a small square in the middle.

Is everyone happy with the auto aspect scaling? In some cases it may leave you with a black boarder!

1 Like
#131

The auto aspect ratio works great, the only time there are borders so far for me are some Saturn and N64 games. If variable widths are going to be an option you can select in the menu, I’m guessing it would be on a per .cfg basis so you can even set it differently between two games on the same platform probably? With that I’ll be able to set those particular consoles or games to a different width and just tweak the resolution in Arcade OSD to get rid of those borders too!

1 Like
#132

Any chance you could upload a version without the ra_res file being written every frame? Not sure it’ll do good for my ssd.

#133

I will upload it later this evening.

#134

This is the fix for the ra_res_hz.txt bug. But this version is only in 1920 superres @Foxhole @SkyHighGam3r .

As I have had completely positive feed back I am now going to incorporate the menu items ready for the full release.

I am aiming to complete this co I can claim the bounty, Is there anything you feel is not yet Incorporated and you feel should be before I claim the bounty?

#135

This is so cool.

You may know this, but you will need to stage your code as a PR on github or have someone else do so in order to claim the bounty.