CRT Overscan with RPi3 component connection
-
Try adding
overscan_scale
in addition to other overscan parameters you may have set.overscan_scale=1
-
I think @Sakitoshi solved this by editing autostart.sh for his Custom configs for CRT using the built-in composite out
Look here at the github page.
-
@Rion That would solve the overscan issue for Emulationstation, but what about the emulators ?
-
Here you have to fiddle around with custom settings in Retroarch.
@Sakitoshi uses shaders to fix uneven pixels and shimmering.
Here's a few threads i could find on the topic.
-
Interesting. I haven't heard about this new solution for RPi yet. I use Pi2SCART with Euro TVs but when I'm in Asia this could come handy for NTSC component sets. Is there no lag introduced by these converters though?
You can also try setting "disable overscan=1". We use it for RGB hats, it probably won't work if it's set to "0" in OP on shmups, but you never know.
-
I myself am using a no lag hdmi to vga that was recommended by Bob over at retrorgb.
-
@mitu as Rion says. retroarch can handle that part via custom configs.
and since op is using hdmi out he can (probably, it depends on the converter) output a very similar signal as original hardware to make trimming overscan and shaders unnecessary. remember that consoles use overscan since is something that couldn't be avoided at the time, so making the emulators display the overscan area is a better option when posible (not all retroarch cores support this) and will naturally center the image. -
Hey, just wanted to return this thread with some resolution and another not-quite-related issues as today was the first time I had the chance to get my setup going again and try some of the advice provided earlier.
Initially modifying the config file as @mitu suggested wasn't changing anything, but for the first time I decided to hook up a keyboard to my pi and alter the config file settings using
sudo nano /boot/config.txt
(as instructed by RetroPie Wiki) instead of using an SD card reader and editing the file on my Windows Laptop. When I did this and rebooted I found the overscan settings were working.I don't know why that would make a difference but it seemed to do so in my case, just wanted to put that up for anyone else who happens to have a similar problem and stumbles across this thread.
Now onto my other issue, there is a difference in picture quality if I compare running a game on the retropie to running it on physical (but not original) hardware, and it doesn't seem to come out in the Pi's favor.
Here is a screen from Final Fantasy 4 on retropie, using the component setup I described in the OP.
Here is a screen from the same area with a Final Fantasy 4 cartridge on a Retro Duo (an NES/SNES clone) connected to the TV with s-video.The second image seems much better, and i'm confused why that would be the case. The guards notably have more detail around their heads, and the color on the background seems less "washed out" than on the retopie somehow. But shouldn't I be getting a superior signal converting HDMI-to-component, or am I doing something wrong here?
The converter I got wasn't expensive and the difference is bothering me enough, so i'm wondering if I would get better quality using a Pi2Scart or a RetroTink Ultimate if Mike Chi has any left..
-
@Dezmancer the missing detail is naturally due to s-video superior quality (edit: s-video is superior to composite, but component is superior to s-video).
the colors are different because the pi is with a different gamma ramp not suited for a crt tv, there are some shaders you can use to correct that.
bsnes_gamma_ramp and gamma2 (choose only one of those, they are identical line by line) convert from lcd gamma to crt gamma while gamma converts from crt gamma to lcd gamma. I don't know any other way to correct this without shaders on the pi (at least when using the built-in composite out), so unless your converter can do it on its own you'll have to use those shaders.but since you are using hdmi maybe you can correct the problem adding hdmi_pixel_encoding=2 (force rgb full) to your config.txt.
-
@Sakitoshi interesting, I had been lead to believe component was the superior signal to s-video and functionally nearly the same as RGB for most purposes, guess i'll reconsider that going forward. I'll try your suggestions the next chance I get to set things up and see if it improves.
-
@Dezmancer you are correct in that component is superior to s-video, my bad, I read component as composite.
but in old consoles s-video can be enough to look very crisp unless you are using a state of the art tv.edit: also I have a retroduo too and the output is very crisp and clean in comparison to a regular snes.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.