[quote=98036]There is no upscaling if display and render resolutions are equal. Be aware your display resolution could be some pixels smaller if overscan (config.txt) is enabled. So if render resolution is 1920×1080 and your display resolution is 1910×1070 (overscan) there could be scaling artifacts.

If performance is ok i would recommend render = display resolution. If performance is to low (shaders, emulation speed) a mix of hardware upscaling and lower render resolutions should be used. Hardware upscaling is for free and needs no processing power.

I have not seen any input lag with hardware upscaling. Thought threaded video causes a small input lag.

[/quote]

I’ve noticed additional input lag setting the render resolution to 960×720 on my 1080p monitor, although it is slight. I’m playing a lot of fast-twitch games, though, so it might not be noticeable in most situations.

Logically, there is going to be an extra delay due to the additional processing that the gpu has to do. Whether or not this is noticeable depends largely on the individual and the game being played.

I wasn’t aware of the performance limitations of the raspberry pi 1, I can see now that the default video settings make sense.

I thought it might make sense to add something like “video profiles” to the launch menu, sort of like preconfigured video modes, but then I realized that each system would need its own custom resolution, and the idea started to seem too complicated.

[quote=97434]Excuse me if I wrote something that was not meant that way. I’m german and don’t always know the right wording. I did not want to upset you. ?

You’re right , on the hill , you can see very few emulated pixels that are a little less wide.
But you have really search for it and you notice it only if you know what to look .

Also in SNES Zelda the first dungeon.
But with smooth and my overlay, it falls on even less.

For you it’s necessary that every pixel look absolutely identical.
For me it’s necessary that the overall image simply looks good.
But that’s a matter of opinion, any way he likes.
Similarly the darkness of the scanlines, to me it looks to darken, no matter how I adjust the brightness.
With the sharpness of your image there looks to me to blocky.

You might also right about the high end TV, but i never played any console on a high end TV. Did you?
99,99% of all people only played on a consumer grade CRT with this “softness”.
All this is the reason why the overall image of a console like SNES, Genesis… looks more uniform and better on a CRT than on a LCD without filter or shaders ….to me ?
Sure, there exists better CRT shader as an overlay image, but the pi can’t handle these.

Actually it was originally indeed about why the whole picture is very dark with your overlay images, it’s because of your resolution settings and the resolution of your overlay image. ?

Sorry but neither with the sharp-bilinear shader nor with the pixelate shader
I see any difference, no matter what settings…?
Maybe you can post a picture on you see the differences?

I now have my original SNES connected and then I realized that I had totally forgotten about the PAL borders. ?
Thus, the aspect ratio at all is no longer correct (1.63) and the individual pixels are also wider to see it there.

More example pictures:
Example Images Dropbox

[/quote]

Don’t worry, you didn’t offend me, it’s just that this whole topic is very contentious and people have a tendency to argue about it for pages and pages :) don’t worry about your English, either- it’s certainly better than my German! This post is going to be long, so I apologize in advance :)

You say you have to really look for the warped pixels. This might be true if you are sitting far enough from the display/have a small display. The warped pixels look especially bad when objects are scrolling, but you might not notice this on a crappy LCD with a lot of motion blur (as most LCDs have). I have a tendency to really scrutinize images because I’m obsessed with picture quality. Once I see these things, I can’t unsee them, and they become a real distraction.

Most image purists/ videophiles will agree that scaling artifacts are the cardinal sin, to be avoided at all costs. This is because, aesthetically, it is worse to warp sections of an image by different amounts than it is to warp the entire image by one amount. But you’re right that this is not 100% objective.

As far as the image appearing too dark, it is probably a problem with your display if it hasn’t been properly calibrated. EDIT If you aren’t used to viewing a calibrated image, than it might appear too dark. Also, you might be forgetting how dim CRTs were. An LCD is more than bright enough to have 100% black scanlines (reducing the effective backlight by 50%) and still be brighter than a CRT was.

The way scanlines work is that the higher the contrast between the scanline and the “drawn” lines, the greater their effect. Scanlines work like a pointillist painting: at the right distance, the human visual system blends the image and it results in a smoother image than actually exists. This effect is achieved more easily when the “gaps” are more easily recognized as such. I’m fairly certain that this could be confirmed via psychological experiment, if it hasn’t been already.

Another thing to consider is that each improvement to CRT technology brought images that were sharper, brighter, and had darker scanlines. First you had regular shadow mask CRTs. Then dotmasks came which allowed more light to pass through and had a less noticeable mask. Then you had aperture grills, which allowed even more light to pass through and were even sharper, with an even less noticeable mask. Then you had the king of CRTs, the Sony BVM, which had an almost invisible aperture grill, 900 lines of horizontal resolution (close to today’s 1080p displays), and was even brighter and sharper. The result is those perfect scanlines that die-hards covet.

The overall point is that CRT quality has always varied very widely, so the graphic artists didn’t have a single use case that they could base their designs on. Sure, most people didn’t have BVMs, but a lot of people had Trinitrons, which were significantly brighter and sharper than standard shadow mask CRTs.

Another point is that trying to replicate the eccentricities of a CRT on an LCD is just hard to pull off without looking fake. The CRT shaders are computationally demanding and won’t run on the raspberry pi, and they require a lot of tweaking to look right IMO. Even then, they are going to add an amount of input lag dependent on your processor speed.

I guess I only like scanlines because they filter the image while still looking authentic to me. All the other effects look like an LCD trying to be a CRT and it feels inauthentic. The worst offender in this regard IMO is the screen curvature effect. I played on all kinds of TVs with curved tubes, and I never recall any curvature like what I’ve seen shaders do. This is because a curved CRT was calibrated so that the image looked square/flat when viewed from a normal angle. A lot of the CRT effects look like an artist’s interpretation of a CRT to me.

Now, back to the original topic (!) :)

You said the darkening problem with the overlay was due to the size, that’s also what I suspected, so thanks for confirming that.

I’m sorry, I neglected to mention that when you choose sharp-bilinear you need to set shader filter to “linear” for it to work. Pixellate won’t run on the pi because it is too demanding.

Yup, PAL games all had those black borders on all systems. This is because PAL TVs were better, having 576 horizontal lines of resolution vs. NTSC’s 480 lines (a 20% higher resolution). The console only puts out 240 lines so everything over 480 winds up as a black border.

[quote=97390]You should not set up a Y resolution higher then the screen resolution.
I use 1080p because then i have 4 pixels for each scanline and additional enough pixel for the TV border itself.
I still don’t know what you mean with warped pixels on the X axis.
I can’t see any difference between 1194×896 and 960×720
You’re right the exact aspect ratio is 1194.66666 in the X axis but with 1194 every emulated pixel is 4,6640625 pixels on screen, not 1, in practice i can’t see the difference, especially with the scanlines[/quote]

Having spent a LOT of time with this, and talking with various RA devs, I thought I should share what I’ve learned.

Why should you not set a y resolution higher than the screen resolution? As I said, what gets cropped off is so minimal on SNES or Genesis that it would have been cropped off by a CRT anyway. With NES, it may seem like you’re losing a lot, but actually, the “safe zone” for CRTs was 90% of the total picture. With going to 1200 on the y axis, you lose 120 pixels, which at a scale of 5x translates to 24 NES pixels. The NES put out a total of 240 lines. 240 – 24 = 216, or 90%.

You might not notice the artifacts on the x axis because they are small at the resolution you’ve chosen, but they are there. Look at the mini map in the upper right of the screen on Super Metroid. You will notice some individual pixels are wider than others. You probably didn’t notice because most of the warping occurs at the edges as you get closer to integer scale. Scaling artifacts completely ruin the image for me, so getting rid of them is my top priority. Or check out the first hill in super Mario bros at the title screen, at the diagonal edge line. You will see inconsistently-sized pixels.

Would you mind providing a screenshot?

[quote]Also most shader have either more or less recognizable effects on the emulator speed. For example SNES Yoshis Island first level, first cave.
The sharp-bilinear.glsl do nothing at least on my tests.
Instead i use the video_smooth option in the retroarch.cfg.
The same with the pixellate filter.[/quote]

The very purpose of the pixelate shader is to allow you to keep your 4:3 aspect ratio while eliminating scaling artifacts. Sharp-bilinear adds a very slight horizontal blur to deal with artifacts on the x axis. You wouldn’t notice them doing anything if you already are not noticing the artifacts in your picture.

Video smooth should be avoided as it just adds bilinear filter, which causes blurring and a loss of detail. You would need a broken CRT for it to look like the picture with bilinear filter. Most videophile retro gamers will advise you to avoid using it.

[quote]In my opinion the pixel edges and the scaliness itself in your example looks too sharp and too dark for me, it looks not really realistic.[/quote]

I don’t want to get into a battle over opinions, if you have found a look that makes you happy, great.

I don’t really see what you mean by too dark, are you sure your display is properly calibrated? I put the scanlines at 50% for an effective 25% reduction in brightness, so you need to turn the backlight up to 100% on your display for an effective 75% backlight.

Realistic isn’t really possible without CRT shaders, but even those just wind up looking fake to me most of the time, and most don’t work on the raspberry pi. For the pi, I just go for a clean emulated look with scanlines to soften the edges a bit. Actually, this picture is almost indistinguishable from a high end Sony BVM :) It’s also very similar to using an upscaler with original hardware. The “softness” of a consumer grade CRT was due to flaws in its manufacture. An ideal “perfect” CRT with no manufacturing flaws would indeed look like the above shot, but brighter, and the scanlines would be 100% black and sharp.

Most of the time when people go for “authentic” it just looks fake and distracting to me. I’m going for overall picture quality over authenticity. I never really understood why people went for authenticity over quality. If you want authentic, why not just play on an old CRT? Can’t get any more authentic than that, and you can get one for free these days. Trying to replicate all the flaws of a CRT on an LCD is silly to me.

[quote]My TV border isn’t 100% finished yet, it’s a bit too much curved, so in some games too much of important image details are lost, but i like it ?

Here you can download some fullscreen scanline overlays and another with a TV Border
https://www.dropbox.com/sh/sicv3m5yp7ztg7u/AAAoJH6AxlKmvWKyAAMGSu8ja?lst

And here is the Youtube Video:
https://www.youtube.com/watch?v=Xu5lLfJmJVY

[/quote]

Thanks! I’ll check those out, as I’m still having trouble getting my overlay the right size. I figured out how to do transparency, at least.

I fear my idea is far more complicated.

I’m not thinking one theme that is only one genre oriented.

I’m asking about one theme where instead of you seeing individual systems shown, you see the different franchises shown.

And to make it more difficult, each franchise would have many games from many systems being playable….

Hopefully I am making since.

Its just a thought I had.

Hi Dpicc

Thanks for your reply. I dont see any “hats” :-) Which one of these are we talking about:

# Keyboard input, Joypad and Joyaxis will all obey the “nul” bind, which disables the bind completely,
# rather than relying on a default.
input_player1_a = x
input_player1_b = z
input_player1_y = a
input_player1_x = s
input_player1_start = enter
input_player1_select = rshift
input_player1_l = q
input_player1_r = w
input_player1_left = left
input_player1_right = right
input_player1_up = up
input_player1_down = down
# input_player1_l2 =
# input_player1_r2 =
# input_player1_l3 =
# input_player1_r3 =

# Two analog sticks (DualShock-esque).
# Bound as usual, however, if a real analog axis is bound,
# it can be read as a true analog.
# Positive X axis is right, Positive Y axis is down.
# input_player1_l_x_plus =
# input_player1_l_x_minus =
# input_player1_l_y_plus =
# input_player1_l_y_minus =
# input_player1_r_x_plus =
# input_player1_r_x_minus =
# input_player1_r_y_plus =
# input_player1_r_y_minus =

# If desired, it is possible to override which joypads are being used for user 1 through 8.
# First joypad available is 0.
# input_player1_joypad_index = 0
# input_player2_joypad_index = 1
# input_player3_joypad_index = 2
# input_player4_joypad_index = 3
# input_player5_joypad_index = 4
# input_player6_joypad_index = 5
# input_player7_joypad_index = 6
# input_player8_joypad_index = 7

# Joypad buttons.
# Figure these out by using RetroArch-Phoenix or retroarch-joyconfig.
# You can use joypad hats with hnxx, where n is the hat, and xx is a string representing direction.
# E.g. “h0up”
# input_player1_a_btn =
# input_player1_b_btn =
# input_player1_y_btn =
# input_player1_x_btn =
# input_player1_start_btn =
# input_player1_select_btn =
# input_player1_l_btn =
# input_player1_r_btn =
# input_player1_left_btn =
# input_player1_right_btn =
# input_player1_up_btn =
# input_player1_down_btn =
# input_player1_l2_btn =
# input_player1_r2_btn =
# input_player1_l3_btn =
# input_player1_r3_btn =

That’s great, thank you! I figured it had to exist somewhere in SkyNet, but I’ll be danged if I could find it (need to use the right terminology).

Here’s what I ultimately envision… I have the TankStick, which is nice, and I love the trackball, but some console games, say the NES and SNES can be more fun (and easier) to play with the original controller than ‘arcade’ controls.

So, I added a dual-USB port to the front of my cabinet where I can plug them (generic Buffalo SNES controllers in this case) into, and without unplugging my TankStick, they become J0 and J1 (if two are installed). Then, as part of the runcommand.sh script, I determine which controllers are on J0 and J1 and use specific configuration files merged together. This would allow 1 player with SNES controller, or 2 player with 1 SNES controller (and p2 on tankstick) or 2 player with 2 SNES controllers.

Having said that, inputstation sounds like it could cover a lot of what I’m working towards – I’d just have to switch between several config files.

Thanks, again!

Coretx,

Yep, doing that definitely made the left stick work in all emulators. I’m still not getting any luck past the Dual Shock detection screen in Ape Escape.

The only way I can get past it is by adding [pcsx_rearmed_pad#type = “analog”] to my retroarch-core-options.cfg file, but when that value is in there my controllers stop working in the rest of my PSx games.

Totally ready to chalk it up to the game itself, not too worried about it, but was using that game since it sounded like that was the one to use to test out analog stick functionality.

By adding the following lines to my retroarch_core_options.cfg (/opt/retropie/configs/all) I was able to bypass the Dual Shock warning:

pcsx_rearmed_pad1type = “analog”
pcsx_rearmed_pad2type = “analog”

Mind you the game I’m using this as a test for is Ape Escape. It seemed to work, with the exception of being up to get the character to react by moving the right stick forward. Also, when I now try any other games, none of the control works.