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…
@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:
What other tests should I do? There is a way to check if modeline (and emulator informations) are correct?
Thank you very much.
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.
@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.
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 !
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.
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.
Thanks! Sounds like i finally have to gather my courage and switch to Linux lol
but why there is a “x-axis” center option , but no Y-axis center option (for games 256p for examples) ?
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
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)?
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.
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) .
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:
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.!
VGA-2-RGB adapter (that generates the combined sync signal on it´s own)
Tell me more.
Maybe my description is kind of misleading. The Raspberry Pi (as well as the MiSTer hardware) are able to output a combined sync signal when configured correctly, so that further discrete hardware is not needed (tested with tons of modelines with the RPi before when I had played around with retropie and a special startup script - that unfortunately just allows one modeline per emulator).
While MiSTer uses a (free) VGA pin, the Raspberry Pi can output the csync signal on GPIO1/pin28. To enable this, you have to add dpi_output_format=0x105 to your config.txt as described in the link above - see https://www.raspberrypi.org/documentation/hardware/raspberrypi/dpi/README.md (“output_enable_mode -> 1: DPI_OUTPUT_ENABLE_MODE_COMBINED_SYNCS”) for detailed information on this parameter.
However, just to emphasize this again:
@Alphanu @hunterk (and also Nikoh77 and Scanlitzer),
I had a closer look on the reason why the image is shifted to the right (in my case) with CRTSwitchRes v2.0, showing a clearly visible border on the left on my consumer JVC CRT TV, especially because I haven´t had this problem with tons of modelines/hdmi_timings I have tested before. Furthermore, the system menu of my TV does not allow to move the image thus far to the left - and I also don´t know if it makes sense to change the default global values in general because it also modifies the image shift of all other input sources…
I currently use these retroarch settings:
I played around with different emulators and roms from different regions, and they all had this shift to the right. This is clear to me, because the horizontal front porch value always stays at 80 (see calculations in lines 324-328 in video_crt_switch.c), e.g.:
Using the values calculated for the RGUI, I played around with the crt_switch_center_adjust value:
As you can see, only the horizontal sync signal length is modified by the crt_switch_center_adjust value, but as also Nikoh77 wrote, this does not seem to alter anything regarding the horizontal positioning.
In fact, this approach in fact seems to be wrong, because in my opinion, the front porch and back porch would have to be changed instead. Therefore, to get a centered picture, I would have to change the front porch and back porch as follows for my TV:
As you can see, while the sync signal length stays the same, the front porch is increased by 115 while the backporch is lowered by the same value.
This also works for the vertical positioning btw.
For further tests and maybe as a proof that this is the right way to handle this, I found a link to a video timings generator script by Frank Skilton from 2017 at https://drive.google.com/file/d/0B10JEKHkXafmajlWbVcyTEVzdGM (apparently, there is no repository available; linked e.g. from the Pi2Scart website). With this, you can show a test image (in this case, scale the included align.png e.g. to 1920x240px or alike) and move the output image by using the cursor keys. If you are satisfied with the positioning, you can save the adjusted modeline settings - this is how I found out the correct front-porch/back-porch settings for my TV.
@Alphanu @hunterk Since I don´t understand how the values in video_crt_switch.c are calculated currently (and even haven´t compiles RetroArch myself yet on the Raspi), I would ask for some bugfix/adjustment regarding this. Should I open a ticket?
Sure. I think alphanu is the resident expert on this sort of thing, but having a ticket for it means it has less risk of getting lost.
Hi I’m trying to use crtswitchres in a crt pc monitor (so 31khz it is) with linux. As I can see in xrandr, when activating 31khz option retroarch creates a new modeline 2560x240@120.
Instead of using super resolutions and change the refresh rate… would it be possible to just double the resolutions? Something like this:
Ghost & goblins
Original: [email protected]> Doubled: [email protected]
Capcom CPS3
Original:[email protected]> Doubled: [email protected]
Mortal Combat
Original: [email protected]> Doubled: [email protected]
Sega Saturn (depending on the game)
Original: 352x240@60-> Doubled: 704x480@60
Original: 320x240@60-> Doubled: 640x480@60
I can play arcade games with groovymame like this and it would be great to do same thing with retroarch for consoles.
hi, does anyone have the config.txt file for lakka on pi4 ? I would like to use the hdmi2vga adapter and the rgb scart cable for a 15 khz tv. Thanks