New CRTSwitchRes v2.0 for RetroArch

[scandy]

@Alphanu how can I check these options (native/super)?

I’m using the official LAKKA image (Lakka-RPi2.RPi4.arm-2.3.1.img) for my Raspberry Pi 4. I’m also using a Gert’s VGA666 and this VGA-SCART cable (usb-powered) connected to my CRT TV.

I only enabled the VGA666 overlay in distroconfig.txt using the modeline suggested here and the options you specified for CRTSwitchRes in retroarch.cfg, loaded Art of Fighting and Final Fight in Final Burn Neo and everything worked like a charm (excluding Shadow Force with jagged lines on items with vertical scrolling).

@hunterk sure, I will take pictures as soon as I get home.

P.S. Only a doubt: I don’t see the video “switch” as seen in this video (I only get the refresh rate message) but picture is pixel-perfect with Art of Fighting (Neogeo), Final Fight (CPS-1), Undercover Cops (Irem M-92), Streets of Rage 3 (Megadrive), Shinobi III (Megadrive).

UPDATE: This is an example of jagged (diagonal) lines of pixels in Shadow Force.

[shakalakka]

hello, i tried with lakka 2.3.1 and the latest nightlies for x64/x86. The CRTswitchres-Options are not shown in the option menu. I have tried to put the needed lines in the retroarch.cfg but nothing works. No Clue about RPi-System but i think the feature is maybe not fully implemented yet.

[Alphanu]

@scandy There is another CRT option in the retroarch.cfg which is crt_switch_superresolution = 2560 or similar, the values are as follows:

0 = native resolution 1 = dynamic superwidth 1920 = 1920 superwidth 2560 = 2560 superwidth 3840 = 3840 superwidth

[scandy]

@Alphanu @hunterk

So I’m in “1920 superwidth”.

This is my retroarch.cfg: https://pastebin.com/0ZD7NxWN

And this is my distroconfig.txt: https://pastebin.com/mWVh8iB7

Thank you

[hunterk]

That looks to me like you might have the wrong height somewhere, possibly in your ‘crop overscan’ settings? Are the artifacts only present while scrolling vertically or do they just not stand out as much normally?

@shakalakka I think the options just aren’t showing up in Lakka because it’s not fulfilling one or more of the conditionals to show up in the menu, despite having the capability. That is, you can try enabling options through the cfg and it should work, even if the options aren’t accessible in the GUI menu.

[scandy]

@hunterk the artifacts are always present, even on static images, in Shadow Force. Crop overscan is set to “on”. Correct height shouldn’t be set automatically by CRTSwitchRes?

[hunterk]

It sets the correct height for the operating system based on what the core reports, but there’s still a possibility for some other options to mess things up.

It looks like it should be a standard 320x240 game, according to this: http://www.punchpedia.com/games/arc/sforce/sforce.php

So unless it’s getting an incorrect modeline somehow…

[scandy]

@hunterk @Alphanu I’ve done some tests.

Setting crt_switch_superresolution to 0 gives a very, very, very narrow picture in width (like a “pillar”) and the UI is unreadable.

With crt_switch_superresolution 1 I still get a narrower picture, incorrect but better than the previous option.

I also noticed these strange behaviors:

• I do NOT see a real video “switch” (like changing channel) after loading a ROM so I wonder if CRTSwitchRes is not working at all on RPi4… ?!?
• Shadow Force USA and Shadow Force JAP behave differently, despite being two versions of the same game: JAP version behaves like all other titles (pillar boxing etc.) while USA version regardless of the CRTSwitchRes options it always has the correct width.

What other tests should I do? There is a way to check if modeline (and emulator informations) are correct?

Thank you very much.

[hunterk]

You need to use the RGUI menu and set a custom aspect ratio, integer scaling on, and a very wide custom width (like 6x+) to stretch the UI out to match the ultrawide screen.

[scandy]

@hunterk @Alphanu OK thank you very much.

But please I’d also like to understand what I’m doing.

What are the advantages of the option “native resolution” instead of “dynamic/1920 superwidth”?

And how CRTSwitchRes manages video modes with different height (es. 320x240; 320x224) and why I don’t see my crt tv “blinking” at a video-mode change?

Thank you very much.

[Scanlitzer]

@Alphanu

First, thanks for all improvments and work. Can’t wait to try v2.0 on raspberry… Currently, I meet a vertical centering problem with game at 256p resolution. I have try many settings but the black strip on down of the screen still visible (if I move the picture offest Y, the overscan mask the picture)

Even I got some overscan because refresh rate (55hz), is there a way center my picture verticaly on the screen ? (I precise too the X-axis centering option don’t change anything on the screen) thanks !

[Yuke]

I might have asked this before…but is the switching between interlaced and progressive resolutions faster when using Linux instead of Windows?

I always get a small sound hickup when switching between them.

[Alphanu]

Yes, It is faster ans smoother with Linux. in some cases like Playstation bios however there is still a small sound glitch. This is because when the Playstation first boots it switches to 4 different resolutions within a second. This show how accurate Beetle PSX is. However, 98% of the time there is no sound glitches.

[Yuke]

Thanks! Sounds like i finally have to gather my courage and switch to Linux lol

[Scanlitzer]

but why there is a “x-axis” center option , but no Y-axis center option (for games 256p for examples) ?

[vol-2]

Excited to try this out on the Pi4. I have a question:

I understand that interlaced resolutions will not work through Pi4 GPIO. I am using an HDMI-VGA solution to my 15kHzCRT. Can I use CRTSwitchRes this way and display the interlaced parts of games (or games that are fully interlaced)?

Thanks

[Scanlitzer]

Finally for my pb with games at 256p 55hz, got better result with this hdmi_timings directly : hdmi_timings 1888 1 48 184 232 278 1 0 10 9 0 0 0 55 0 38400000 1

here a screen to illustrate what I got to compare:

the pb I got with CRTswitchRes is it’s impossible to center the screen vertically, it’s out of screen at top, and cropped at bottom without any possibilities to get full screen (if I down with Y offset , I see the top of the screen but the bottom become higher cropped). The picture size is also a few smaller with CRTswitchRes. Seems the horizontal resolution may not perfect with this hdmi_timing (but perfect freq and line), and I can’t go down the picture lower for a very perfect centering (I reach the limit with V porch zero) but the render is more satisfactory despite that (on my tv in any case). Please , does the next version of CRTswitchRes could contain more offset settings (porch-like)?

[Alphanu]

Hi,

Thanks for the image comparison image.

Its easy to see from your picture that your hdmi timimg is off. What you have there is 280p. This is stretching the image vertically not giving you a true 256p image. I can see from the refresh rate being used that this is an arcade game (using Mame/fbneo). Home consumer CRT were not designed to work with these. There will be similar or worse issues with MK or Viper X. Arcade monitors were designed with this in mind, this is why they have vertical and horizontal shift and stretch pots with easy access.

The vertical resolution does not have much window for adjustment, any more than a few pixels moment with porch adjustment and you will loose sync or no longer have a true representation of he resolution. You will need to adjust your CRT service options, if available. Just like you have to change the vertical and horizontal shift and stretch on a arcade CRT when you change the game.

If you are running this on a RPi4 you should expect resolutions to not work to well current. This is not the fault of RA, it is a issue with the new frame buffer driver.

I hope this clears a few things up.

[Scanlitzer]

Thanks for your answer , I understand about CRT settings and the benefice to have an arcade monitor. Just a few confused about what you call “true” 256p because when I test patterns with this specific hdmi_timings (which is not from me but by Sir-Ironic I think) , I got a “perfect line” result (in move too , just with normal judder due to the inapropirate 55hz refresh rate for the 240p suite), at the proportionnal size of the used viewport (224p on the test , cf picture). If we extrapolate to 256 lines (red editing part on the picture), we got the exact size of what I see on r-type in terms of screen size…So why don’t call this “true” 256p if there are 256 effective lines at final ? I agree, the pixel ratio is probably wrong because the horizontal resolution is here one of the compliant parameters to reach 55hz and 256p maximised size with pi3 pixel clock limit, but the picture seems really true with any visible loss sync (in r-type), judder or picture shear unlike what I watch when wrong resolution or non native refresh rate for this game are used. (I’m sorry about my previous screen if it was perceived as screenshot for the game display part, it was just an edited and resized shot to illustrate in green the wrong centering) .

Meanwhile to test Pi4, I will continue to follow your work, thanks

[JK1974]

Hi,

I gave it a try with Lakka 2.3.2 (latest) on Raspberry Pi 2 (!), and it basically seems to work on my JVC consumer CRT TV, using VGA666 and a self-built VGA-to-RGB adapter (described at https://github.com/randyrossi/bmc64/issues/115), judging the difference in sharpness of the RGUI depending on what core you are currently running (e.g NES vs. PSX) and visible “flashes” when starting Gran Turismo due to several resolution changes right at the beginning

However, there are still some open points that also haven´t been answered above that also happened to me:

• There seems to be no CRT Switchres setting entry in the “settings” or “video” settings menu. But like I said, the settings in the config are working.
• Like also mentioned by some users above, also my screen is shifted to the right, and values from -4 to 4 in crt_switch_center_adjust did not change anything. Anyone with answers on this?

And something that you might also be able to clarify: crt_switch_resolution_super set to 0 or 1 did not work here with the Raspberry Pi. As far as I have read in https://github.com/raspberrypi/firmware/issues/734, the Raspberry Pis 0-3 are not able generate every valid pixel clock value and there is even a limit regarding lower frequencies, therefore only 1920 is a valid value here. This is said to be solved with the Raspberry Pi 4. Would you agree on this? However, I plan to switch to x64 as soon as a new VGA-2-RGB adapter (that generates the combined sync signal on it´s own) and an appropriate ATI graphics card are ready.

Thanks a lot in advance - great job btw.!