Raspberry Pi Resolution settings advice

[Skykid]

Fudoh, I got it all going, thanks for your help with this.

Now, you mentioned tweaking shaders to my liking - how would one go about this? I tried CRT-Caligari and the effect isn't particularly desirable. On its own the scanlines are extremely faint and the softening doesn't look very good. I had better results with crt-royale-vertical-interlaced, or bsnes-gamma-ramp + scanline overlay at 40% (the latter is particularly nice).

I'm assuming there's more than meets the eye with Caligari if you're recommending it, so if you can help me figure out adjustments that would be great.

Thanks again

[Fudoh]

Many shaders including CRT-Caligari are done for 720p resolutions and won't look good on 480p output.

Unfortunately you can't tweak most of these using Retropie (or at least not using Recalbox). You can tweak them by using Retroarch on a PC (which gives you an interface to do so) and then just replace the GLSL files on your Pi.

On 720p CRT-Caligari looks very nice. If you increase the scanline density a little you get a very PVM-like look.

[Skykid]

Right, but those scanline tweaks are only possible on a PC? (Bar me using an overlay on top of the shader of course - that's an option. But I feel as though Caligari really doesn't look right at 480 regardless).

Either way I really thank you for helping me once again Fudoh, at least now I know how to add and test new shaders. I feel like the Bsnes gamma boost + overlay is really nice, so failing anything better I discover I'd be happy with that.

Out of interest, does crt-pi have visible scan lines at 720p, because at 480 it's literally just an even cross hatch effect, and adding a scanline overlay doesn't do anything except dim the image.

[Skykid]

Right, the SNES scanline banding is definitely down to the overlay regardless of it being the correct sized overlay and regardless of the SNES being at native resolution or integer scaled.

The same overlay works flawlessly on other consoles tho, go figure.

So I'm looking for a shader combo to solve this one. I've already got one applied for general aesthetic, but is there a recommended lightweight scanline shader (that does little more than apply a fairly solid scanline) I can use to replace the overlay?

[Skykid]

Bumping with new hair tearing and hoping for forum love.

Trying to set up Raspberry Pi on a 17" 800x600 Res, 60hz LCD. Set up the Pi config file to output at 800x600 and 60hz. For the first time since ever, shaders appear to be displaying correctly (which would correlate, since the config output matches the screen resolution) but not without some caveats.

See figure one: my retroarch configuration.



If Integer isn't set to ON, then the shader or scanline overlays will appear with moire effects and artefacts. Sadly when the Integer is on the resolution can only be set to a standard x3 to fill the screen - but this cuts off the top and bottom of the screen. See figure two, which has CRT-PI shader on:



How can I bring this in without massively reducing the size? X2 on Integer is a teeny square. If I manually try to bring the top and bottom of the screen down, the shader/overlays go out and moire effects return.

Bizarrely and additionally, if Bilinear Filter is set to off when using a shader, I get moire effects - ripples when in motion - but they disappear when switched on.

Finally, I'm using retrorama on Emulation Station. The UI all appears in order, but the selection screen text on the right side (speech bubble, 1-2 players) and at the foot (Game producer, date etc) are out of position and partially unreadable. I have no idea why and can't see an option to adjust positioning/size etc. See figure three:



Would love you like I already do if I could get some help with any of these perplexing issues so I can get on with normal things like curating rom lists and setting controller preferences.

Thanks so much for your help!

[Fudoh]

short version: your monitor's resolution is simply too low to handle proper shaders.
And the same is likely true for your front end which was certainly designed with 720p or 1080p in mind.

Basically all scanline related shaders require integer scaling to be active. You could try a shader without scanlines that's easy on the CPU and add the scanlines using an overlay, but usually the scanlines then don't match the graphics in terms of sharpness and you will be hard at work to get that scanlines properly matched up with the pixel rows.

[Xyga]

As far as I've experienced, smoothing filters and shaders break the actual integers for some reason, not by much, just a line or two, but that's enough to make it impossible for the .png overlay to align to the source (well, in most cases i've experienced) very annoying.

[Skykid]

short version: your monitor's resolution is simply too low to handle proper shaders.
And the same is likely true for your front end which was certainly designed with 720p or 1080p in mind.

Basically all scanline related shaders require integer scaling to be active. You could try a shader without scanlines that's easy on the CPU and add the scanlines using an overlay, but usually the scanlines then don't match the graphics in terms of sharpness and you will be hard at work to get that scanlines properly matched up with the pixel rows.

Yeah, if it's not integer matching the scanlines to the image is a nightmare.

But I'm confused: the shaders do appear to be working fine. With the pi set to the right screen res output they actually apply properly over an integer display - the only issue is I can either have integer x2 which is way too small, or x3 which is slightly taller than the actual monitor, meaning I'm losing top and bottom sections. The shaders apply fine at either of these resolutions. In-fact if I didn't care about losing half a score line I'd say it was perfectly playable and looking good - but it's certainly not very cool left in that state.

I hear you re: the UI being designed for 720p and up, and that makes sense. That said I actually can push the pi resolution settings all the way up to 1024 x 724 and everything displays fine on the monitor, and much crisper than it does at 800 x 600. No idea why the monitor carries a signal for that setting, but it works - only issue is that shaders won't sit properly with it and that's why I'm trying to configure for native resolution. And the UI text stuff is broken in both the same.

[Skykid]

As far as I've experienced, smoothing filters and shaders break the actual integers for some reason, not by much, just a line or two, but that's enough to make it impossible for the .png overlay to align to the source (well, in most cases i've experienced) very annoying.

But for me it's turning the smoother off that messes up the shader alignment - bilinear filter OFF. Or is that what you meant?

[Fudoh]

But I'm confused: the shaders do appear to be working fine. With the pi set to the right screen res output they actually apply properly over an integer display - the only issue is I can either have integer x2 which is way too small, or x3 which is slightly taller than the actual monitor, meaning I'm losing top and bottom sections. The shaders apply fine at either of these resolutions.

what I said, wasn't it ?

Hmm, if your display supports higher resolutions, would 1024x768 with a 3x integer make the most sense ? You would end up with 672-720 lines filled (88-94% fill rate vertically). Certainly better than 75% in SVGA mode with 2x.

[Xyga]

@SK: When it's - not sure if the right term - 'embedded' into the source like in the case of shaders, the smoothing kinda evens things out indeed, more or less hiding the moire effect etc.
the overlays on the other hand are aligned to the display's resolution, so it's the source that has to align properly, they're fixed and can't adjust.

If you were using MAME many years ago before the video part was rewritten (0.107), maybe you remember the built-in scanlines options, those were applied directly to the source then the picture was zoomed/stretched to fill the screen. It was kind of dirty (probably using bilinear by default also) but worked pretty well actually.

@Fudoh weren't there a couple of crt shaders that did quite well in hiding the expected unevenness even in full screen scaling? I think crt-geom of hyllian, dunno it's been a while. But I doubt the Pi can work such relative heavyweights...

[Fudoh]

I think crt-geom of hyllian, dunno it's been a while. But I doubt the Pi can work such relative heavyweights...

yeah, the Pi is very limited in choices when it comes to scanlines though shaders. Most aren't optimized for Pi and the ones that are rely on integer scaling.

[Skykid]

@SK: When it's - not sure if the right term - 'embedded' into the source like in the case of shaders, the smoothing kinda evens things out indeed, more or less hiding the moire effect etc.
the overlays on the other hand are aligned to the display's resolution, so it's the source that has to align properly, they're fixed and can't adjust.

Yes, and the first thing I normally do is switch off bilinear filtering and then forget about it, so the issues with moire effects have probably been even more frustrating than they should be had I known otherwise.

You live n' learn.

If you were using MAME many years ago before the video part was rewritten (0.107), maybe you remember the built-in scanlines options, those were applied directly to the source then the picture was zoomed/stretched to fill the screen. It was kind of dirty (probably using bilinear by default also) but worked pretty well actually.

@Fudoh weren't there a couple of crt shaders that did quite well in hiding the expected unevenness even in full screen scaling? I think crt-geom of hyllian, dunno it's been a while. But I doubt the Pi can work such relative heavyweights...

Hylian doesn't work on RPi, it slows everything to a crawl, which is a shame because the scanline effect is more what I wanted than the more 'dotty', 'crosshatch' look on CRT-PI.

But I'm confused: the shaders do appear to be working fine. With the pi set to the right screen res output they actually apply properly over an integer display - the only issue is I can either have integer x2 which is way too small, or x3 which is slightly taller than the actual monitor, meaning I'm losing top and bottom sections. The shaders apply fine at either of these resolutions.

what I said, wasn't it ?

I thought you meant the display res was too low to allow shaders to render properly at all, apologies if I misunderstood.

I can try your suggestion of 1024x768 with a 3x integer, but from what I remember having been there first and fiddled around with it, the shaders didn't apply properly as they do in 800x600. I have no idea why higher res outputs work BTW, because the monitor info only states 800x600 60hz. I have a feeling... that it might be to do with the HDMI to VGA converter I'm using to connect; I recently found a piece of info on the net that says you must add "hdmi_ignore_edid=0xa5000080" to the config file to truly get it to ignore the converted source otherwise it will always default to 640x480.

I'm not sure that that correlates with my past experiences, but I've added the code to my config.txt now and I'll see if I can get something proper on that higher res.

Appreciate your input guys!

[Fudoh]

Hylian doesn't work on RPi, it slows everything to a crawl, which is a shame because the scanline effect is more what I wanted than the more 'dotty', 'crosshatch' look on CRT-PI.

CRT-Caligari is the one you want to use. The default scanlines are bit light, but you can edit the file to make them stronger if required. Caligari with increased scanlines density has a nice PVM look, while CRT-Pi looks like a low TVL Commodore 14" monitor.

I can try your suggestion of 1024x768 with a 3x integer, but from what I remember having been there first and fiddled around with it, the shaders didn't apply properly as they do in 800x600.

that depends on the quality of the display's rescaling. It's very well possible that the display basically destroys the shader's efforts by doing a poor job on the down scaling.

In the long run I would really suggest to pick up a higher resolution display. I mean, I don't know about your space restraints, but 20" and 21" 4:3 LCDs are dirt cheap.

[Skykid]

Hylian doesn't work on RPi, it slows everything to a crawl, which is a shame because the scanline effect is more what I wanted than the more 'dotty', 'crosshatch' look on CRT-PI.

CRT-Caligari is the one you want to use. The default scanlines are bit light, but you can edit the file to make them stronger if required. Caligari with increased scanlines density has a nice PVM look, while CRT-Pi looks like a low TVL Commodore 14" monitor.

Yes, I thought the same!

So here's a bit of a pain in the ass. RPi only recognises GLSL shader files and not CG. I have GLSL Caligari and others installed, but when you open the file in a text editor it's a mess. Very difficult to figure out where the settings are after the conversion. The only thing I can do is apply settings changes to the CG file and then convert after, except I don't understand how to run the conversion script at all!

that depends on the quality of the display's rescaling. It's very well possible that the display basically destroys the shader's efforts by doing a poor job on the down scaling.

In the long run I would really suggest to pick up a higher resolution display. I mean, I don't know about your space restraints, but 20" and 21" 4:3 LCDs are dirt cheap.

Yep, it's not that unfortunately. I have a little project cab going. It's like a mini-cute, but a mini woody stand up instead. I've done tons of work on the external appearance because when I got it it looked like shit, but it has its own LG monitor installed and the space can't house bigger than 17". I really want the RPi running in there because the Pandora's Box 3G is subpar and doesn't even have active V-SYNC.

[Fudoh]

So here's a bit of a pain in the ass.

open the GLSL file. There's a line

Code: Select all

_v_weight_10 = _dy/6.49999976E-01;

if you change the value to something lower the scanlines get stronger 5.000 looks pretty good and that's what I use. I guess you can even go a little lower, but I found that going to low, the scanlines tend to get uneven.

And your 17" screen is an actual 4:3 screen ? 1280x1024 (as in 5:4) was the common resolution for 17" LCDs back in the days.

[Skykid]

Okaaaay

The monitor certainly isn't locked to 800x600 - I realised the information in the monitor's OSD was simply reflecting the output of the PI. Since the screen is just the panel there's no information on it internally or externally about its actual display resolution.

So using the guide here:

https://www.raspberrypi.org/documentati ... t/video.md

I've run through just about every meaningful option, right up to 720p and 1080p and they all show up.

The problem is absolutely none fix the issue. Here are my findings:

1080p - this displays the UI the best, with all the text just about fitting properly on the screen with the exception of longer genre descriptions. However the UI imagery is a little pixellated and jaggy.

720p - similar to above, maybe the UI is slightly less jaggy.

1280x768 60hz - This is one of the best options with the least amount of screen real estate missing from the edges at integer x3, but the entire display is slightly off screen to the left, and I have to use the monitor OSD settings to reposition it. The UI is full HD here and clean as a whistle, no pixellation.

800x600 60Hz - Only the higher res settings actually display the shaders properly. This one won't seem to work properly even at an integer scale. And the UI is pixelly again.


I tried other ranges like 1280x768 70hz, 75hz and they all have slight variations on what's already here.

The biggest problem I have is no matter what I do and no matter which output resolution I set, the screen is ALWAYS cut off on the top, bottom, left and right when set to integer x3, which also seems to be the only setting that displays the shaders accurately. x2 is too small to display the shaders properly.

The monitor is 4:3, but has an option for 16:9 in the OSD. Switching between these makes no visible difference to the screen at all.

I'm tearing my hair out

[Fudoh]

no matter what I do and no matter which output resolution I set, the screen is ALWAYS cut off on the top, bottom, left and right when set to integer x3

Just an idea: you know that setting a resolution for ES (the front end) to run it, does NOT affect the resolution the emulators run in, right ? Sounds to me as if you're changing the front end resolution, but still ending up with your reduced resolution for the emus themselves. Otherwise I wouldn't know why you're losing any screen area while running in 768p at 3x. This should always leave you a good portion of unused area around the active game area.

[Skykid]

no matter what I do and no matter which output resolution I set, the screen is ALWAYS cut off on the top, bottom, left and right when set to integer x3

Just an idea: you know that setting a resolution for ES (the front end) to run it, does NOT affect the resolution the emulators run in, right ? Sounds to me as if you're changing the front end resolution, but still ending up with your reduced resolution for the emus themselves. Otherwise I wouldn't know why you're losing any screen area while running in 768p at 3x. This should always leave you a good portion of unused area around the active game area.

That's a possibility, but then why do the shaders only seem to apply properly at certain output resolutions?

I'm open to any ideas. We know that the screen will handle up to 1080p, and I'm willing to totally wipe the install to fresh again (although that shouldn't be necessary because certain emus haven't been tampered with at all).

If you give me a set up to run with, I'll test it immediately. I'm willing to try anything.

[Fudoh]

hmm, ok. If your LCD's OSD give you an information about the incoming res, does it read the same for the frontend and the actual games ?

Another possibility is that your LCD adds overscan for HD resolutions, but doesn't for VESA resolutions.

It usually doesn't make any sense to run anything but the native resolution (unless that res is so high that you get performance problems), so your best approach would be to figure out what the native res is (maybe google the model ID, if you can't tell from the image itself). If you say 768p is crisp and it's 4:3 after all, then the native resolution is likely XGA (1024x768) and then that is what you should be running for your frontend AND your emulation.

The horizontal offset you're experiencing is likely a cause of the timings your HDMI to VGA converter does output. You could try a GERT666 VGA adapter instead (which gives you VGA from the Pi's GPIO port). These are just a few $ - maybe worth a try to fix that problem.

[Skykid]

Ok Fudoh, thanks much. I'll try your suggestions and see if I can figure out what the panel's actual specs are somehow. If all else fails I'll try the VGA board you suggested. There's a possibility that the converter is affecting the information on-screen somehow, although it's all very confusing as to why.

[Skykid]

Found the model:

http://www.panelook.com/LM190E08-TLJ6_L ... _4821.html

Got the size wrong, seems it's 19". Going to test at 1280×1024 then and see what happens.

[Fudoh]

sounds good. Only problem is that the Pi might fail running the actual emus at 1024p with various shaders. Its sweetspot right now is really 720p or XGA, not SXGA/Full HD, so you'll have to see how it performs.

[Skykid]

sounds good. Only problem is that the Pi might fail running the actual emus at 1024p with various shaders. Its sweetspot right now is really 720p or XGA, not SXGA/Full HD, so you'll have to see how it performs.

Ok, here's the thing at 1280x1024 60hz



Ignoring the rainbow effect caused by the camera, the shader (or at least CRT-PI) actually displays properly. The problem is this is x2 and it's widescreen, with large borders top and bottom, while the image meets the left and right edges.

x3 is exactly as before, much larger than the display despite the x3 resolution being lower than 1280x1024. Otherwise everything else appears ok. The monitor setting is 4:3, although changing it to 16:9 makes no difference anyway.

Unless... this widescreen effect is CPS1 displaying natively? I had no time to check other consoles at the minute.

Perplexing.

[Fudoh]

Perplexing.

indeed. Did you check the OSD of your monitor to confirm that your emus are running in the same res as your frontend?

[Skykid]

Perplexing.

indeed. Did you check the OSD of your monitor to confirm that your emus are running in the same res as your frontend?

Yes! And they are. When checked over Cadillacs the OSD reads "1280x1024 60hz"

[Fudoh]

I have no idea then. With a 1280x1024 output your integer factor should be set to 4x. This gives you between 896 (for 224p) and 960 (for 240p) pixels in vertical height. The horizontal size should be set by the AR, not the integer factor. I would have to try a VESA resolution like this on my setup to see how the games actually behave using this output resolution.

[Xyga]

On a 1280x1024 display the integer factors for cps hardware should be either 3x4 (1152x896) or 4x5 (1536x1120).

I say should because although it's been a few years I remember having the surprise of seeing the integer settings of RA not necessarily achieving the size I expected (contrary to genuine MAME where things end up exactly as they should).
Maybe it's some RA OSD video oddity, dunno...

[Fudoh]

On the Retroarch version I'm using here on the Pi (one from last year), you only get one integer factor and that's to define the vertical size. You can get a matching factor by setting the AR in the right way, but that wouldn't really help him here on a 5:4 display with the wide CPS1/2 resolutions.

[Xyga]

Really? Whoever has removed the ability to set both H and V integers separately in that RA build clearly wasn't aware of how essential it is.

Maybe it's still possible to create a mame.ini and force there then ?

EDIT: ah sh* iirc the mame core is too old, dating from before the introduction of integer scaling, isn't it ?