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
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.
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?
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
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.
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 I have just sorted this, but let me know how you get on with it as it stands.
Congratulations man! Yor job is awesome!
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?
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)
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!
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!
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.
I will upload it later this evening.
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?
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.
I don’t use gitub much so this may sound like a noob question but what is PR?
It stands for “pull request”. It’s basically just a diff patch submitted through github.
Ok guys. I’m really close to a finished product now.
Still a few bugs to iron out. One big one is turning CRT switching on from the menu.
Here is a little teaser showing the menu working.
Currently you can toggle CRT Switing on and off. The menu will display your super resolution, which you can set in the cfg. You should be able to set core overrides to use different superees. I plan to make superees choosable from the menu but not sure how yet!
At the end of the video I turn the CRT option off but as I was in a super res everything was squashed. But this show it being toggled.
As I said a few issues to tidy up yet.
Is it possible for you to add the option of turning off refresh rate switching? Since it’s not possible to create the same resolution with refresh rate that is closer than 1hz, then on some cases changing the refresh rate will be less beneficial, even more so when dealing with super res. Edit: just read your post on the groovymame forum about the dynamic hz. Nevermind my request.
The hz that consoles use only send to vary by 0.3hz this is the case for PAL and NTSC. I’d you have 50hz and 60hz resolutions installed this would be close enough. Pal would normally be between 49.7 - 50.06 so you could average that and install mode lines with 49.88hz which means your only ever be 0.18hz out worst case. His would be similar for NTSC. I’m setting the games hz to match the original so the closer your CRTs hz the better.
Things get a little more in-depth when it comes to mame as some resolution will have 54hz or 57hz e.t.c this is because the resolutions are odd e.g arcade reolutuon can be 320 x 237 or 384 x 262. This is where dynamic or closest hzand closest resolution match comes in.
I believe that Mortal Kombat uses 320 x 237. I’ve been working on this some mane can be included in the resolution switching.
I attempting to create the ultimate All in One CRT emulation solution.