RetroArch - Native CRT Support

Bounty Discussion
#21

Thanks so much! I actually managed to discover a fix to my initial issue as well and so I have information on both the native resolution and the super resolution builds as I’ve tested them both. So to start the Super resolution build worked nearly perfectly aside from one issue but it’s nothing you can fix it’s just a result of the way retroarch handles aspect ratios. There is no current aspect ratio setting that stretches to full screen regardless and because of this when using Super Resolutions the only good aspect ratio setting is custom, then you define static x and y values, this prevents the vertical size of retroarch from scaling correctly between resolutions, either 480i will be squished in half or 240p will be doubled off screen.

Because I was receiving that last issue I just mentioned, I downloaded your last release of the build for use with Native resolutions and now interlaced modes are working with that as well! However now I’m coming across another issue. For some reason when the horizontal resolution changes in game retroarch does not change the implied internal horizontal resolution of the game. For example I launched Castlevania Symphony of the night, the PS1 BIOS displays well, as well as the intro FMV, however when the game gets to the title screen to press start the screen resolution changes to 512x240p and this squishes the picture in to the center of the screen, going into the retroarch video menu shows that retroarch believes the games internal horizontal resolution is still 320 pixels wide. Here is a picture of the issue.

20180306_232257
20180306_232257.jpg4032×2268 2.87 MB
Same issue with Crash Bandicoot, immediately after the PS1 BIOS, which works properly, the resolution switches to progressive for the title screen but is not the correct aspect ratio. Something different happens with Ape Escape, this game starts with a couple 480i screens but when the game switches to the opening cutscene the game should switch into progressive mode however this time there is no resolution change, the game remains interlaced. All of these games I tested behave properly in the Emu4CRT fork of Mednafen. One game I tested however is working perfectly with native resolutions and that is Donkey Kong 64, the 2 interlaced splash screens as well as the switch into the progressive intro both display perfectly! So here is a short video of that in action!

#22

If you use config as your aspect ratio and set integer scaling on it should fill the screen in all modes (except some lower 50hz modes, they will always have borders, as the real hardware would have).

#24

I understand some games have borders on real hardware and naturally not all games will fit the entire screen but that’s not what I believe is the problem.

This is me forcing a custom viewport of 512x240 and running Castlevania SOTN at the title screen at that full screen resolution which is the resolution Alpapha’s build sets the screen to and it is the correct resolution for this screen.

20180307_022139
20180307_022139.jpg2851×1603 2 MB

Now here I’m going to show me forcing the fullscreen and viewport to 320x240 which is what Retroarch has reported to it as the native resolution instead and if you look closely you can see the artifacts from not being a clean interger scale

20180307_022343
20180307_022343.jpg2851×1603 2.11 MB

20180307_022410
20180307_022410.jpg1603×2851 2.16 MB

1 Like
#25

Are these test in native or super resolution?

In native resolution you should not need to change any aspect ratio. The video driver should fills to the screen.

RetroRepair has been doing the core of my testing and has found that there are some cfg conflics. I sent iver my ra2 folder over to him instead of just the exe and things work brilliantly. Except hz swithing. If you could extract a fresh RA and then add my files to it. You should notice some differences. My cfg is passing 0 for fullscreen x and y. Some cores you need to change interlaced mode to double field and integer scaling.

I am looking into automatic ration changes as and when needed. May be a while till this is implemented though.

#26

First of, a big thank you, amazing work. I’ve tried both the native and super builds and so far the native worked perfectly for me as long as the modeline is available. With the super build i’m having 2 issues, first one i’m not sure is actually an issue, but if i’m playing a game that changes the horizontal res midgame from 320 to 240 and vice versa, like splatter house 3 on the genesis, instead of simply scaling it seems to unnecessarily “refresh” the resolution. Using the official retroarch this doesn’t occur and the change of resolution is perfect without any sign of changes in the resolution, the same behavior as with groovymame. The second issue is that with the super build it seems no matter what i’m getting issues with vsync, the picture looks as if vsync is not enabled even though it is, with the official retroarch this doesn’t occur either.

#27

If the game changes res at all then so will retroarch with this build. It should be correct behaviour. Check the ra_res_hz text file (delete it then load RA and test that rom). I have a feeing splatterhouse 3 is a lower res than most games at least on certain screens. If it does change, that file will log the mode it’s changed to. Mainstream RA won’t do that because it doesn’t change res mid game :wink:

Regarding super modes, it’s likely the refresh won’t match what RA is trying to sync to for the moment but this is being looked into. By the way, vsync shouldn’t need to be used once this build reaches maturity as it shouldn’t need it. If your resolutions are set up correctly megadrive in pal mode should already sync correcty for example.

Having next to no lag with the correct resolution on a CRT is something to behold :sunglasses:

#28

I think i didn’t explain myself correctly, english isn’t my native language, so sorry for that. I know that the game changes resolution mid game and that this is correct behavior, i just think it’s unnecessary since it’s already using super resolution 2560 and basically changes the resolution to the same resolution, and the resolution change is only on the horizontal, not vertical. the game uses two resolutions, 320x224 and 256x224 (No overscan) so it would make more sense to simply scale the game without changing resolutions, eliminating the small hiccup that happens during the resolution change. This is how groovymame deals with super resolution and this is also what i was using up until now with retroarch 1.2.2, which worked perfectly with this setup. About the refresh, what do you mean vsync will not be needed? how would you sync the video to the monitor without tearing? And if i understand correctly, the super build should be avoided at the current moment do to the problem with the refresh? I checked again and it’s definitely an issue with vsync not working. If i disable audio sync then the game runs unthrottled as if vsync is off. Thank you.

#29

I ran my tests using native mode. I installed a fresh retroarch but it is still the same thing with PS1 games, any horizontal resolution that is not a clean multiple of 320 gets borders incorrectly because the core still reports the native horizontal resolution as 320 pixels. In games where this isn’t the case and horizontal widths are either 320 or 640 all displayed perfectly, for instance I just tested the game Activision Classics for PS1 with no issues. So for games with oddball horizontal resolutions like 512 the only way to properly fill the screen horizontally is with the custom aspect ratio settings that set the horizontal viewport to the exact number of pixels those are the only working aspect ratio settings for those games I can find because retroarch seems to think that those games are an incorrect horizontal resolution as opposed to what they actually are

Super resolutions could potentially resolve the issue I just mentioned but interlaced and progressive modes don’t alternate to fit the screen in both modes with super resolutions and I’ll explain why. Interger scaling relies on the 2 values trying to match a specific aspect ratio, 320x240 and 640x480 are both 4:3 so with aspect ratio set to 4:3 they both fit. 2560x240 and 2460x480 even though due to the nature of a CRT they will be squished in to 4:3, when you look at just the demensions they are totally different aspect ratios so there is no good setting that matches both of those resolutions at once. Interger scaling would normally help but this case is different because I believe retroarch will only select even multiple interger scales (so for example if I select the config aspect ratio and set interger scale on at 2560 x 240, retroarch will pick 320x240 to scale to and not 2560x240 because it’s not a clean multiple of the entire native res. I think we are pushing the limits of what the current aspect ratio settings were designed for, it would really help to have some aspect ratio setting that just generally scales as far out on both demensions as possible

Lastly I ran one more test. Sonic 2 on Genisis does not yet switch to interlaced for 2p vs mode

#32

Abwezi, i also tried the psx core with the native build, and i tested castlevania sotn and i had no problem with borders or scaling artifacts, though the main menu used a weird resolution. Anything else you want me to try? as for sonic, make sure you have a 320x480i modeline and also make sure that you set the core (genesis plux gx) to output double field in the core options, the default is single field.

#35

Wow I’m not quite sure what it is then. I even got a fresh download of retroarch and made a fresh config to install this over and still no dice. You wouldn’t mind uploading your retroarch.cfg for me to try would you? I’d greatly appreciate it

#36

My thoughts are exactly this.The interlacing shader is finding those changes extremely well - maybe this functionality could be used as a template? I don’t know.

I just want to re-iterate this statement. There is a 4:1 which is suitable for 1920x480, but not an 8:1 for 1920x240. Let alone higher resolutions like 3840x240, etc, etc.

As far as I know, the only way to get proper visuals is to set the aspect ratio correctly and set integer scale to “on”. Setting it to ‘config’ requires you to manually input the x/y resolution numbers; which are going to differ between each system (and in our case multiple times per game).

@Alphanu I tested this on my own build a little last night with my CRU resolutions setup instead of CRTEmudriver and it kept screwing with the resolution on the wrong monitor - Is this only configured for single monitor setups? I didn’t have time to test it again with the other monitor shut down but I thought it was an interesting result, none-the-less.

#37

I tested this on my own build a little last night with my CRU resolutions setup instead of CRTEmudriver and it kept screwing with the resolution on the wrong monitor

If you look at the batch file it generates it uses monitor index /d=0 ; I’ve actually used the program Alphanu seems to be using here for other games before to automate resolution switching through my frontend, I have 3 copies of all the batch files use with this program (i.e /d=0, one with /d=1, /d=2, etc.) and keep them organized so I can copy and paste into the root of my hard drive and switch them out on the fly, I have 3 displays and there really is no way that I’ve found to make windows keep a monitor indexed to one static number. So for now you’d have to unplug your displays until they are ordered the way the program expects

#38

Just a little info on the interlacing shader: it’s very dumb. It just says “anything taller than 400 px must be interlaced, so treat it as such”.

4 Likes
#39

When it comes to sonic 2, the emulators don’t imitate true interlaced on the standard settings. This is because it was not destined for CRT. The emulators Hack Interlaced to progressive for LCDs. You need to enable double field in the options for Gens, This then emulates true resolution.

#41

Currently this is in early stages and does not detect multiple displays, It will only set device 0 ATM. This will be where I will have to build in some options to set which display you want to use.

Its not a big code change to recompile, so if you know whether your CRT is plunged into device 1 , 2 or 3 let me know I’ll make the change so you can test.

#42

Sorry if I didn’t answer all your question this evening, I’m not ignoring them. I have a fair amount going on ATM.

@Abwezi @SkyHighGam3r @anon24419061

#43

No worries, I’ll try testing it tonight with just the CRT hooked up and see what happens. I just wanted to make sure it wasn’t my setup since I’m testing with CRU instead of CRTEmuDriver.

1 Like
#44

Does CRU add modelines into windows registry?

#45

Sorry if I didn’t answer all your question this evening, I’m not ignoring them. I have a fair amount going on ATM.

You are certainly alright I’m more than appreciative of what you’ve done already.

1 Like
#46

I’m not sure - I know you open the program - create a resolution - use a restart file and it resets the graphics drivers. Then those resolutions show up in the Windows display settings options.

Seems to stay with it after a restart - so possibly? I’m not sure where I’d look in the registry for that to confirm.