Forum Replies Created

Viewing 35 posts - 36 through 70 (of 149 total)
  • Author
    Posts
  • in reply to: Scaling, Aspect Ratio and Resolutions #98926
    patrickm
    Participant

    Test

    in reply to: Scaling, Aspect Ratio and Resolutions #98917
    patrickm
    Participant

    [quote=98914]Not sure why you cant upload pics here – are they over 2MB? Do you get an error message?[/quote]

    Keep getting a 413 error, but I know the pics are less than 2 MB.

    [quote]Not sure you can compare a CRT per se, as they all seem to differ a little.[/quote]

    If you read my posts, I explain this in detail. CRTs varied within a particular range. Anything within that range is within the specifications for CRTs. The range is from nothing cropped, to ALL overscan being cropped. Any image which crops less than or equal to the full overscan area is within range for CRTs.

    [quote]When you say 6×5 scale, can you confirm what you mean from a config file point of view so I can compare in my setup?[/quote]

    6×5 scale for NES and SNES would be the recommended resolutions that I sent you. I’m merely trying to demonstrate that the 6×5 scale image is not “cutting too much off” as was claimed in the OP.

    [quote]When you use a multiplier based on the integer scale, I think it will go to the max it can for the res, so if a SNES has native output at (height) 239 pixels, 4x integer scale would be 956 – which wouldnt fit on a 720p screen – so it puts out the closest to it, which would be 3x, which is 717 in height.[/quote]

    Well, as I’ve explained multiple times, you should not be using 239 unless you want to see the black borders which were part of the SNES output frame. It’s 224 lines, padded with 15 lines of black border. To re-iterate: the SNES and Genesis both put out black borders at the top and bottom as part of the image put out by the console- this is in addition to the letterboxing that occurs on a high-def display (720 or 1080). The black borders were put there so that the actual image didn’t get cropped off by the CRT- but many CRTs would crop off more than the black border anyway.

    There is no reason to display these black bars- they were not intended to be displayed and they were cropped off by the CRT.
    [quote]
    I’m assuming it falls back to a smaller res anyway, based on this:
    http://emulation-general.wikia.com/wiki/Scaling

    Therefore you could use more of the screen by specifing a precise ratio increase instead, although in the example above, 3x is only 3 pixels out :)

    It would be more apparent on 1080p. 239 x 5x = 1195, so it would fall back to 956.

    But if you did 1080 / 239 = 4.51.
    So you could do 239 * 4.51 for height, and 256 * 4.51 for width.
    That way you keep the native output ratio and use more screen area?[/quote]

    Why are you trying to replicate the native ratio? This has nothing to do with display ratio. Anyway if you want to do that just choose the 1:1 PAR option under “aspect ratio.” No need for all this math.

    [quote]
    I’m presuming you specify a large than 1080p res so a certain area falls outside the viewable area to emulate how it often appeared on CRTs?[/quote]

    Correct. The 6×5 scale is the closest to how the game was actually displayed on a CRT while maintaining perfect video scaling. A real CRT didn’t show letterboxing at the top/bottom of the image (overscan is designed to prevent that) nor did it display all the overscan.

    in reply to: Scaling, Aspect Ratio and Resolutions #98911
    patrickm
    Participant

    Why am I unable to upload pictures to this thread? I’ve tried unsuccessfully several times now to upload a comparison of a real CRT to the 6×5 scale emulated image showing that the 6×5 scale image is well within normal range for CRTs.

    in reply to: Scaling, Aspect Ratio and Resolutions #98785
    patrickm
    Participant

    [quote=98781]Ok, I could write profiles for 4x and 5x. Lets sort out the 5x settings first when you can check them and I’ll put that together.

    Do you mean this should also be added in your settings?
    # video_crop_overscan = true

    [/quote]

    For snes9x-next, crop overscan needs to be ON because there is a bug; ON is actually OFF.

    For all other systems, crop overscan should be left OFF.

    If you crop overscan you change the output frame size which interferes with scaling.

    However, some cores seem to not even have crop overscan, such that it doesn’t matter if it is ON or OFF.

    Since this is the case, I would just advise leaving it OFF for all systems so that the output frame is unaltered, with the exception of snes9X-next, where crop overscan must be ON.

    I’m double checking each system as I write this but I believe the above is correct.

    I’ll also send you specific resolutions for each system for the 5x and 4x profiles. A 3x profile would be nice as well, for 720 displays. I made a 3x scanline overlay that can go with it; I’ll work on getting all these overlays together in one package.

    Having this setup script is actually a very handy idea, I was thinking of something similar a couple weeks ago. Glad you made it :)

    in reply to: Scaling, Aspect Ratio and Resolutions #98776
    patrickm
    Participant

    [quote=98773]I’m trying to boil down the differences between the two approaches from a retroarch config angle (as opposed to personal opinions).

    One element seems to be:
    video_scale_integer = “true” / “false”
    video_smooth = “false” / “true”

    and separately the pixels specified in:
    custom_viewport_width =
    custom_viewport_height =

    What else am I missing?

    [/quote]

    That’s essentially it – I’d like to see separate profiles for 4x and 5x if possible. I personally use 5x but I understand if maybe some people want to see EVERY line put out by a console, even if it got cropped on a real TV.

    I’m recommending video-smooth be left off so that nearest neighbor scaling is used, but there’s nothing preventing someone from using video smooth with integer scaling if they prefer it for some reason. This will however effect the appearance of scanlines by causing some pixels to bleed over them.

    I’m still at work (lol) so I’ll check those settings you posted when I get home :)

    One important thing you’re missing is crop overscan: most of the time you want this left off, but sometimes it needs to be on- snes9x-next is one example that comes to mind. I have all this written down at home :)

    in reply to: Scaling, Aspect Ratio and Resolutions #98745
    patrickm
    Participant

    [quote=98741]I am well aware how to get to 1120 lines,
    But the fact remains that the emulators shows native resolution 239 lines in most games and an integerscale 5x 239 are 1195 lines.
    Only when the game is outputs 224 lines 5×224 are 1120 lines, but mostly not.
    That’s why too much is cutted with your settings.
    The best example you have shown yourself with Final Fantasy.[/quote]

    15 of those 239 lines were black, ie, blank space.

    I’m pasting this from the post you just replied to:

    The SNES is 239 when padded with the black borders. Minus padding, the SNES image is 224 horizontal lines or 1120 at 5x scale.

    Just for kicks though let’s say that the SNES was supposed to display the full 1196 lines.

    1196 – 1080 = 116, divided by 5 for 5x scale, is 23.2. As mentioned, the overscan area is 10%. 10% of 239 lines is 23.9. 23.2 is less than 23.9 so the amount that is cropped is within the overscan area.

    The image was only drawn to 1120 lines though. 1120-1080 = 40, or 8 pixels at 5x scale. So you lose 4 lines from the top and bottom- again, this is well within the range of what actual CRTs would have done.

    Again, you are also failing to appreciate that CRTs cropped different amounts off of the top and bottom. There was no single standard.

    The rest of your points have already been addressed in my first post.

    Re: accuracy, authenticty, etc I think this has already been adequately addressed.

    Again you aren’t adequatwly appreciating the degree to which CRTs varied in the amount that they cropped. It wasn’t a waste of cpu space to put those graphics there because some TVs would have displayed more or less ocerscan. Stuff was put in the borders so that you didn’t get a black border on TVs that cropped less. The overscan area acted as a buffer to compensate for the variability in how CRTs were calibrated.

    Those comparison shots are thus meaningless because they are either displaying the full frame or they are cropping an arbitrary amount of overscan.

    What continues to confound me is that I showed you a direct comparison with an actual consumer crt, but you’re still claiming that 6×5 cuts off too much. That picture got deleted, so maybe you didn’t get a chance to look at it?

    in reply to: Scaling, Aspect Ratio and Resolutions #98743
    patrickm
    Participant

    [quote=98739]Just looking into integer scaling. Would you agree with this?
    http://emulation-general.wikia.com/wiki/Scaling

    Integer scaling is scaling by a factor of a whole number, so 2x, 3x, 4x, etc. In RetroArch, the option scales the image up to the greatest integer scale below the set resolution. So for instance, if you set your fullscreen resolution to 1920×1080 and enable integer scaling, it will only scale a 320×240 image up to 1280×960, and leave black borders all around.

    Just read the monster thread you started here:
    http://nintendoage.com/forum/messageview.cfm?catid=31&threadid=135619

    To be honest, my conclusion at the moment is that you cant get exactly what a CRT would do, because 1) Many CRTs are different from eachother, and 2) Emulation is a compromise. Therefore whichever solution someone uses, will always be lacking a certain element of the original setup.

    Given that scanlines on overlays are a vast improvement over the default output, and I really cant tell much difference, I’m probably going to stick with what I have at the moment.

    [/quote]

    Tons of information in that thread, I learned quite a lot.

    Yep- that’s a good description of integer scaling and I agree with both points you made. Emulation is a compromise and you’re never going to be able to precisely replicate a CRT with an LCD. But, you can get *very* close to the actual output of a console on an rgb monitor (particularly a high end trinitron monitor) using integer scale with nearest neighbor filtering plus the appropriate scanline overlay. The one difference with the description you posted is that you can avoid the black borders with 5x scale.

    I agree that the scanline overlays are a big improvement over the default output- I’ll see about getting the corrected versions uploaded to the repository so that they’re included with RA. I already posted a topic on the libretro forums on this.

    in reply to: Scaling, Aspect Ratio and Resolutions #98737
    patrickm
    Participant

    [quote=98735]Ok, so I’m no expert on the video output, but I’ve been trying the overscan view on the 240p test suite:
    http://junkerhq.net/xrgb/index.php/240p_test_suite#Grid

    Sticking with SNES as the example, you can get it here:
    http://sourceforge.net/projects/testsuite240p/files/SNES_SFC/?

    Here is a screenshot of the settings from you both, both of which seem to show pixels in the overscan area – personally I like that, as there is valid imagery there, it certainly doesnt bother me. But thats a personal thing.

    Again, I’m not sure about the validity of the test (Plus my TV has a slightly odd setup due to the 768 pixels and Elgato setup), but its an interesting one to run through.

    patl settings
    patl-settings

    patrickm settings
    patrickm-settings

    [/quote]

    The console displayed pixels in the overscan area but that doesn’t mean they were meant to be displayed, and overscan was almost never displayed on a real crt.

    At 4x scale you are dedicating a huge amount of screen space to letterboxing and overscan- particularly on SNES and Genesis which displayed black bars in part of the overscan area. A real CRT never showed letterboxing (well, PAL ones did), and the overscan was supposed to be cropped. This is particularly apparent on some NES games- Check out Super Mario Bros 3 or Castlevania 1 for good examples. Or look at Contra or Adventure Island for examples that displayed junk pixels in the overscan area.

    As soon as I get home I’ll test the config, but it looks good.

    The main point I wish to get across is the importance of integer scale in avoiding pixel artifacts and getting an accurate picture to what a crt could actually produce. Some people might like seeing all of the overscan for some reason and so there’s 4x scale for that. Almost every system I’ve tried looks more accurate to what a CRT would do in 5x scale.

    Also, the only impact aspect ratio has on the pixel art is the degree to which it stretches the pixels, and I’ve shown via direct evidence and logical argument that a 6×5 scaled image and a 5×4 image are accurate to what a crt could produce.

    Floob- if you like the rgb look, remember that it was much sharper and showed the pixels in more detail than a standard composite ntsc TV. Rgb was the gold standard for gaming in the crt days and the reason why they’re still sought after. The closest you can get to the sharp rgb look is using nearest neighbor filtering with the scanline overlay.

    If you like the look of a more consumer crt using rgb, I created the aperture grill overlay specifically for that- it’s suppsed to replicate the aperture grill of a Sony Trinitron TV. The only problem is the weird bug that causes the diagonal line when using it.

    I think if the aperture grill overlay problem could be fixed, then my settings plus the aperture grill will get you very, very close to the sharp RGB look on a Sony TV with the right opacity and screen settings.

    Of course, the shaders look even better IMO but they aren’t exactly realistic, either- Hyllian for example replicates some aspects of a composite sinal which improve the picture while ignoring aspects that degrade it.

    Overall, when it comes to real signals on actual technology, nothing beats the RGB look on a trinitron type monitor. This is also what is replicated by an xrgb mini device.

    Also, the bilinear filter blurs the pixel in all directions, which is why it causes problems with scanline overlays- but, some might not notice these issues and prefer the smoother image even though it introduces artifacts.

    Some people might want to replicate the look of the poor quality CRTs they grew up with in order to achieve a sense of nostalgia, but gamers back in the days of CRTs almost universally preferred the sharp look of rgb arcade monitors.

    in reply to: Scaling, Aspect Ratio and Resolutions #98730
    patrickm
    Participant

    “Both SNES emulators cores have a native resolution 256 x 239.”

    I’ve explained this.

    The SNES is 239 when padded with the black borders. Minus padding, the SNES image is 224 horizontal lines or 1120 at 5x scale.

    Just for kicks though let’s say that the SNES was supposed to display the full 1196 lines.

    1196 – 1080 = 116, divided by 5 for 5x scale, is 23.2. As mentioned, the overscan area is 10%. 10% of 239 lines is 23.9. 23.2 is less than 23.9 so the amount that is cropped is within the overscan area.

    The image was only drawn to 1120 lines though. 1120-1080 = 40, or 8 pixels at 5x scale. So you lose 4 lines from the top and bottom- again, this is well within the range of what actual CRTs would have done.

    “Of course may be a CRT cuts off some lines from the picture, but I do not think that has anything to do with overscan.”

    Padding and overscan aren’t the same thing. Padding relates to the extra part of the image put out by the console that wasn’t meant to be displayed. Overscan had to do with the TV.

    I’ve also explained the following more than once:
    On an NTSC TV, up to 10% of the picture would be cropped from top and bottom. The amount being cropped on SNES and Genesis is well within these parameters.

    “Screenshots and especially when at FFV the Black / White / Grey frame with your settings 1536×1120 just missing the top and bottom.
    I think that was certainly not planned by the programmer.”

    I’m afraid you are simply incorrect in your assumption, here. The frame would indeed be cut off on many CRTs- as I’ve demonstrated via direct logical explanation as well as empirical evidence in a side by side comparison with an actual CRT (my Sanyo).

    What you need to look at are things like life meters, heads up displays, etc. These were never placed in the overscan area and thus will never be cut off with a 5x vertical scaling. There is no single correct way to display these games since the CRTs varied so widely in how they were calibrated- there is only “incorrect.”

    The programmer could only expect a certain range. Thus, occasionally on a real crt graphics would be cut off, but important graphics were always places within the “safe zone”

    “With Integerscale 5 : 4 you can see everything from the picture but the aspect ratio is not correct and against the image on a CRT TV, in which I assume that the image is stretched to 4 : 3, is too wide”

    I have also already explained this.

    The aspect ratio is an arbitrary consequence of the display tech being used. The actual output frame was never 4:3. It would be stretched to a 4:3 image in a variety of different ways by CRTs, which cropped widely different amounts off the sides and top/bottom. Thus, how “wide” or “thin” individual sprites or pixels were on a crt varies widely and there is no single standard here, only a correct range. And as I’ve explained more than once, the pixel dimensions in 6×5 on NES and SNES are well within this correct range. In fact, you said that Mario looked too fat in the 6×5 scale image when in reality he is thinner there than in the 4:3 aspect image.

    I posted a side by side comparison showing the super Mario bros title screen in 6×5 emulated on a PC and on an actual crt showing that the 6×5 scale image is completely within the correct range for CRTs.

    The fact is that the amount you saw varied on a crt. Some CRTs would show all the overscan. Most cropped this off. Some, like my Sanyo CRT, cropped off even slightly more than the overscan area. This is the reason why SNES and Genesis had those black bars at the top/bottom, so that the actual picture wasn’t cropped off. But sometimes, the crt cropped off a bit more than this and you would lose a couple lines off the picture.

    In fact, the developers did not intend for the overscan to be displayed, and they certainly didn’t intend for the game to be displayed letterboxed on your TV. They also did not intend for you to see the black bars/padding that were part of the SNES and Genesis output frame. If you’re playing at 4x scale you’re seeing a bunch of stuff that you weren’t supposed to see, while at 5x you crop off a few pixels on the SNES and Genesis and this is well within the normal range for CRTs.

    patrickm
    Participant

    There are in fact still some artifacts in the image you posted, though I will admit that they are hard to detect- the most noticeable are the tips of the hearts. However, I’m not able to get an image that looks as good as that. I’m using the “stock” shader with filter set to “linear.”

    patrickm
    Participant

    [quote=98659]Maybe you can write your exact settings that you used during each test?
    Also , the overlay would be interesting to recreate the problem .

    [/quote]

    I used 5x scaling as described in the thread “how to get perfect video scaling,” and the 5x scanline overlay as described in “how to get scanlines”

    I get the same results with 4x, though.

    in reply to: Scanlines overlays and configs for a softer look #98645
    patrickm
    Participant

    [quote=98618]I tried to add the HDMI settings as well in config.txt, but the line is still there. It’s the same problem that patrickm has with his overlay. I also noticed it in GB now, but never in any overlay with scanlines. Could it be the grid pattern?

    [/quote]

    I’m noticing the diagonal tear in any overlay that has a lot of vertical lines. Tried making a phosphor pattern last night, same thing.

    patrickm
    Participant

    What the crt shaders try to do is a little bit of blurring and scanlines at the same time, to overcome the limitations of bilinear filtering. But the shaders are too intense for the pi to run. So, one has to make a choice between accurate scanlines, a smooth image, or a smooth image with inaccurate scanlines.

    Personally, I think the inaccurate scanlines of the bilinear filter image look as bad as a misaligned scanline overlay and are very distracting, but some people might not be bothered by them.

    in reply to: N64 at 1080p? #98625
    patrickm
    Participant

    [quote=98617]Please tell me how. Clocked my PI2 and the n64 is still laggy.

    [/quote]

    What’s your memory split? I recommend 256 mb to GPU.

    in reply to: Overlays makes games crash #98614
    patrickm
    Participant

    [quote=98609]I think the problem is the file path information in your retroarch.cfg
    This entry in the config works for me:
    input_overlay = /opt/retropie/emulators/retroarch/overlays/wii/scanlines.cfg

    You cannot only write :
    input_overlay = wii/canlines.cfg
    or so.

    edit:
    I see there is also an entry in the config:
    overlay_directory
    But this don’t work for me if I only set a path here and select the
    image via input_overlay.
    Only a full File path as described above works for me.

    [/quote]

    I’m already using the full file path; it doesn’t work.

    this was not an issue until I reinstalled everything about 2 weeks ago.

    This is only an issue with SNES and NES as far as I can tell. I’ve been getting a segmentation fault in my error log with this, which I posted to the retropie github.

    in reply to: Overlays makes games crash #98608
    patrickm
    Participant

    [quote=97705]Hi

    When I set any overlay option in Retroarch.cfg games wont run, PSX games do run but overlays are not displayed and if I try to change any overlay option in the settings (for example if I try to turn them off or change the scale) in the retroarch menu it crashes the PSX emulator

    Just to be clear, this only happens when I set then by default in Retroarch.cfg if I run the emulator without any overlay option set in retroarch.cfg and then manualy add them in the setting menu of retroarch they do work fine.

    The Retroach.cfg I edited is the one at /opt/retropie/config/all/

    Any idea what could it be? having to add the overlays every time I start a game is a chore :(

    Im using a PI 2 with Retropie 3 beta 2

    Thanks

    [/quote]

    I can confirm the existence of this bug- overlays will crash RA if set by default, but can be loaded within RA.

    patrickm
    Participant

    Thanks for testing that! That helps narrow it down.

    It’s either a problem with the version of RA being used, or a problem with how the Pi handles video rendering.

    I’ll post an issue on the retropie github. Looks like there are several bugs still to be ironed out with the retropie.

    patrickm
    Participant

    bump, here is the scanlines plus aperture grill overlay that I made. You need to set integer scale ON and a custom resolution that is 5x on the y axis in order to use it, for the 5x version. The 4x version needs a resolution that is 4x scale on the Y axis (see: “how to get perfect video scaling”)

    Also, be aware that it causes a significant reduction in brightness- I would recommend setting overlay opacity no higher than 70% when using this (with backlight, NOT brightness of your display set at 100%).

    Can someone please confirm that this causes a diagonal line through the middle of the screen, with one side brighter than the other? This problem is most noticeable when opacity is set to 100%.

    I think this might be a bug with overlays within Retroarch. I hope that it isn’t a problem with the Pi itself.

    here is the 5x version of the overlay:
    https://www.dropbox.com/s/5avp93o0lo3jmy5/aperturegrill1920x1080-5x.png?dl=0

    here is the 4x version:
    https://www.dropbox.com/s/hvf5m9d2rzchbyx/aperturegrill1920x1080-4x.png?dl=0

    below is a screenshot showing the problem (enlarge to 100%).

    I tried making a 720p 3x version but I wasn’t happy with the results since it resulted in a 2/3rd reduction in brightness, so I removed it.

    in reply to: Scanlines overlays and configs for a softer look #98561
    patrickm
    Participant

    [quote=98516]I tried all the configs and it looked good, great work!

    Could you please explain how to get the green colors for the Gameboy? I placed the palette folder with the “default.pal” file into /home/pi/RetroPie/BIOS but I guess there is more to it.

    I also noticed a diagonal “/” line in the GBC overlay when playing the gbc super mario game. It was only seen in that game by the few I tested. The right side of the / was darker and the left brighter. It was fading away the more I lowered the input_overlay_opacity.

    [/quote]

    I am having a similar issue with my aperture grill/phosphor overlay that I’m trying to do. There is a static diagonal tear, starting from the lower left corner of the monitor and going to the upper right corner. The upper/left half is darker and the right/bottom is brighter.

    I think this might be a bug with overlays :(

    in reply to: shader: crt-hyllian with sharpness hack #98551
    patrickm
    Participant

    [quote=98549]In terms of a guide for this one, do you just select that shader, or did you specify a new viewport setting as well etc.. ?
    I think you had this in your original guide, but have deleted it now to show the overlay details instead?

    I guess I could just do a comparison of default settings, plus with this shader chosen? Or were there extra tweaks you wanted in there?

    [/quote]

    I deleted the original recommendations because I’m assuming that the vast majority of people are using 1080p displays, and shaders are really only good if you are on a 720 display (with the Pi).

    I think for all shaders the best results are had when you use integer scale. This will ensure pixel-perfect scaling and, most importantly, that the scanlines are evenly spaced and the same shape.

    There is also an option to adjust bloom strength and beam width/sensitivity, if you are interested in that.

    I’m actually kind of jealous of those with a 720p display as they’re actually kind of hard to find, now. I was considering buying one for the retropie, but I think it would be cheaper to just buy a slightly more powerful computer like the mini Intels.

    I’ll post steps to editing glsl shaders on the pi a little later- that would make a good video.

    patrickm
    Participant

    double post

    patrickm
    Participant

    I honestly think that people who complain about sharpness are sitting too close to their displays and/or are using overly large displays.

    Just curious, how large is the display you are using and how far do you sit from it? I’m using a 24″ HDTV, the equivalent of a 19″ 4:3 TV. At a distance of less than 4 ft, the graphics are indeed too rough, while a CRT at the same distance would look fine due to the much lower resolution. However, if I move to 4-5 feet from the screen, it looks awesome. That’s the way higher resolution images work; a higher resolution image at a greater distance will look the same as a lower resolution image at a closer distance. This has to do with limitations of the human visual system and the amount of detail the human eye is capable of resolving.

    Another thing to be aware of is that the “sharpness” setting on a properly calibrated display will be at or near 0, so if this isn’t set right, it could be having a detrimental effect on the game graphics.

    I realize that sitting further back from the TV may not be for everyone, but you might give it a try if you think 8 bit and 16 bit graphics look too harsh with nearest neighbor filtering and scanlines.

    in reply to: shader: crt-hyllian with sharpness hack #98522
    patrickm
    Participant

    [quote=98508]Thanks. I like this.
    I should really update my shaders video with ones based on hyllian.

    [/quote]

    It’s one of my favorites and what I would use with the pi if I had a 720p native display.

    The reason this one is so good IMO is because it doesn’t seek to replicate flaws like color bleed that degrade the picture quality, but just those aspects of the CRT which enhanced the picture quality, like the “blending” you got from a composite signal. This was actually used by some graphic artists to create special effects – the force field in sonic the hedgehog is a good example.

    On the pi, everything is a compromise. On a 1080p display the best compromise IMO is to use the scanline overlays, but if I had a 720p native display I would totally go for Hyllian. There are more options to tweak, if you’re interested.

    If I had a more powerful computer, I might opt for crt-royale or crt-easymode with modified settings. I’ve seen some really amazing shots of those shaders in action.

    in reply to: shader: crt-hyllian with sharpness hack #98521
    patrickm
    Participant

    [quote=98512]Yes, I also think that looks really nice.
    Also, because even with your hack the image is still minimal soft an not 100% sharp ?
    The problem is that the image (depending on the game) a little stuttering.
    The best way to realize it, is in Super Mario World 2 on SNES.
    – In generally, if you run just around the area look on blocks or something.
    When you set off the shader, the game runs much smoother.
    – In the beginning, while the island turns.
    – In the first level, in the first cave with the rolling stone.

    If you change the core to Pocket SNES, it is slightly better but still clearly visible.
    With an overlay image and Pocket, SNES Mario World 2 always as fast as if no shader is in use.

    I have overclocked my Pi2 to official max in the config.

    [/quote]

    Shaders in general don’t run well at 1080p on the pi, but setting your display to output a lower resolution will add input lag and scaling artifacts. The solution if you want to use shaders with the pi? Buy a 720p display :P

    Anyway, glad you like it.

    edit: also, just to be clear, I didn’t come up with this hack- it’s actually a parameter option, but it’s somewhat difficult to edit; you have to edit the .cg version of the file on a PC and convert it to .glsl using a python script.

    in reply to: Scanlines overlays and configs for a softer look #98503
    patrickm
    Participant

    You can use the scanline overlays I posted in “how to get scanlines” if you don’t want the TV border.

    patrickm
    Participant

    The standards I’m referring to are simple and universal: avoid flaws in the picture. Just like stretching a 4:3 movie image to fill the screen is not how the artist originally intended for the image to be displayed, the artists did not intend for the pixels to be stretched by varying amounts, and yes, this will have an impact on pixel art, particularly as objects scroll across the screen.

    The 6×5 scale thing I’ve explained numerous times and even included a side by side comparison with a real crt as evidence. In fact, my Sanyo CRT cropped slightly more than the emulated image at 6×5 scale, and yet still you claim that I’m cropping too much off the image!

    I will explain it again. An NTSC CRT cropped off up to 10% of the picture from the top and bottom of the picture. This area was called overscan and was not meant to be displayed. If your TV displayed this, it was calibrated outside of what the developers intended. The 90% of the picture that remains is what is referred to as the “safe area” and all television programs and movies were designed so that important graphics were not displayed outside of this area. And in fact, the overscan area would often have things you weren’t supposed to see; such as boom mics in television programs or junk pixels on NES games. So, the amount that is cropped at 5x scale is actually closer to how the game was displayed on a CRT TV than displaying the entire uncropped 4:3 image in a letterboxed window.

    In case you missed the calculations I provided earlier, here they are again: the safe area of an NTSC TV is 90% of the area, top to bottom. On the NES, 5x scale is 1200 pixels. So on a 1080p display, you drop off 120 pixels. But each NES pixel is 5 1080p pixels at 5x scale. 120 / 5 = 24 pixels, or exactly 10% of 240.

    With Snes or Genesis, what gets cropped off is so minimal its not even worth discussing (like 4 pixels)

    The pixel dimensions as well are well within the parameters set by CRTs- you aren’t really appreciating the degree to which this varied by individual CRT. CRTs cropped varying amounts off of the top, bottom, and sides and stretched the image by varying amounts to achieve this. There is no single standard here when it comes to pixel dimensions, only a correct range. Basically, any pixel height/width ratio that is above 1:1 (the pixels were never square on a CRT) but below 1:1.43 (the dimensions when nothing is cropped) is technically fine and is within the parameters set by CRTs.

    The aspect ratio is also arbitrary and a consequence of the display being used. The only impact this would have on the game graphics is that the artists would have expected a roughly 4:3 output that would have stretched the output frame by a certain amount. But again, because each TV stretched and cropped everything by varying amounts, the graphic artists could only expect a certain range, here.

    My personal preference is 6×5 scale but my suggesting settings will work at any scale, provided that the right overlay is used- 5x scale needs a 5x overlay while all scales below this can use the 4x scale overlay. The 6×5 scale image is more accurate IMO because it doesn’t show the overscan.

    “So I understand Your statement that a picture in which some stroke are very clear to see, but spoil the image in any case, is better for all people, as the same picture, in which these lines but can not be seen ..?”

    No, I’m afraid you didn’t understand the analogy; allow me to explain. I’m using a hypothetical example here to illustrate a point.

    The image is clearly flawed if a use a black pen to draw some random lines across the television. Or, better yet, suppose that there are several dead pixels on the lcd screen, so that they no longer produce any light or color. But suppose my grandmother is almost blind and can’t see the lines that I’ve drawn or the dead pixels. She thinks it looks okay.

    The point is that just because someone doesn’t notice flaws, doesn’t mean that they aren’t there or that they aren’t flaws. A dead pixel is a dead pixel and it’s a flaw. By analogy, the same is true of warped pixels.

    patrickm
    Participant

    [quote=98469]Thats right, you could argue an example of picture quality is 1080p, an example of picture settings is if someone wants to use the “zoom” mode on their TV to make a 4:3 film fill the screen of their widescreen TV.

    [/quote]

    this is actually a good example, because image fidelity in this example is being violated. The original image is 4:3 (unlike games on a 4:3 crt TV, which were arbitrarily stretched according to how it was calibrated).

    By altering the image from its original 4:3 ratio, the image is now less true to the original. So from the standpoint of picture quality, defined as image fidelity, the stretched image is objectively worse. The original artist(s) who created the content did not intend for it to be displayed that way. The same argument does not apply to displaying old games in a 4:3 aspect ratio, because all CRTs stretched and distorted the image by varying amounts, and there was only an acceptable range instead of one single standard.

    But, whether or not one thinks image fidelity or respecting the art is important is ultimately subjective. :)

    patrickm
    Participant

    To clarify what is meant by “best picture quality”

    Picture quality can be defined using a set of objective standards. So what defines picture quality is not necessarily subjective.

    However, whether or not one individual thinks that the picture looks best with a particular set of settings is always going to be subjective.

    This is how “picture quality” can be objective and subjective at the same time :)

    Also, just wanted to clarify that I am not against a softer look per se (although I personally do prefer a sharper image), but bilinear filter is not the way to do it, for the reasons I’ve given, and there really isn’t a good way to achieve this on the raspberry pi, unless, perhaps, you are using a 720p native display and shaders.

    patrickm
    Participant

    For me, the most noticeable and defining feature of retro graphics on a crt is the scanlines, so it’s all about getting the scanlines right.

    I do like the look of some shaders once they’ve been tweaked- crt-easymode and crt-royale come to mind, but both are too intense for the Pi. Caligari works but is just too light IMO, and hyllian-glow works but the blur is distracting.

    For 720p displays I have made some editied versions of crt easymode and crt hyllian. I removed the lanczos filter from easymode so that it will run on the pi without slowdown. I enabled the sharpness hack with crt hyllian to make it sharper.

    The weird thing is that once you enable the sharpness hack and darken the scanlines, crt hyllian starts to look very close to using the overlay.

    I’ll upload both of these when I’m back at my home computer.

    I would like to keep the conversation here on topic and civil, so no ad hominem attacks and let’s focus on the actual arguments. I think this has the potential to be an interesting discussion of we stick to these rules :)

    patrickm
    Participant

    [quote=98464] @patrickm
    If you could write up a step by step guide like patl for your preferred settings I could put a video together for that as well and then people can choose which they prefer.

    It really is a personal choice. Cigarettes are bad for peoples health – no question – but they still smoke. Its personal choice. Personally I really like the way that the overlays work in the config by patl, but I am more than happy to try your settings.

    Is it these 12 steps that are best for that?
    https://www.petrockblock.com/forums/topic/list-of-recommended-shaders-for-raspberry-piretropie-how-to-get-the-crt-look/

    Would you like me to update it so you dont need to do anything in RGUI?

    [/quote]

    Picture quality is not personal choice because we’re talking about an objective set of standards. For example, avoiding artifacts is one requirement. The fewer the number of artifacts, the better the picture quality is in this regard.

    One might say that using the best picture settings or not is a matter of personal choice, however. And there may be some considerations which may lead one to not want the best picture settings – see the example of my dad, above.

    Those twelve steps should do it, but I didn’t include how to save the settings. Some videos would be excellent :)

    patrickm
    Participant

    [quote=98427]Funnily enough, you had but just after this debate and my explanations revised your overlays.
    Just yesterday. I have posted my settings for a softer image, you’re talking about it just bad and ask again assertions that are simply contrived only to the hair, but änderst suddenly your overlays … haha[/quote]

    Let me first observe that you are quickly becoming very rude. If it’s too much for you to have this conversation in a civil manner, don’t participate.

    Now, on to your claim that image quality is a matter of personal taste.

    This is not true. As I’ve pointed out numerous times, a good quality picture does not depend on the viewer being unaware of flaws or not noticing the flaws. “Picture quality” actually refers to a set of standards which you might not be aware of. For example, when someone calibrates a monitor they have a specific color standard that they are trying to replicate, among other things.

    We can show that image quality is not merely dependent on the observer through a reductio ad absurdum. Let’s say I just scribble some lines on my tv with a pen. My nearly-blind grandmother doesn’t see that the lines are there and says “that looks so good!” We can see from this example that a good quality image is not a mere matter of opinion and is not really dependent on the viewer.

    Your settings add actual, technical flaws to the picture. Artifacts are technically flaws. Maybe you can just shrug your shoulders and say “oh I don’t see the flaws so it must be a good image.” That’s not how good picture quality works. A good picture stands up to scrutiny and does not contain such flaws in the first place. A good picture does not depend on the viewer being ignorant of the flaws in the picture. A good picture is one which can be heavily scrutinized by someone familiar with picture quality and stand up to such scrutiny. You are saying, essentially, “don’t look at my image too closely, it looks good until you really start to look at it.” A good picture is one which will stand up to the scrutiny of experts who are familiar with all the aspects of picture quality, not one which grandma looks at and says “gee that looks so good sweety.”

    I’m sorry but the personal preference of your wife does not determine image quality. Let’s use an analogy:

    My dad has pretty poor eyesight and needs to crank up the backlight/brightness on his TV. That’s what looks better *to him.* But objectively speaking the image is worse with his settings because when you crank up the brightness as he does there is a loss of detail. The TV had actually been professionally calibrated to the THX standard, so an change in the settings is an objective loss of image quality.

    So with your wife. Is she a professional calibrator or emulator author? How is she supposed to know what good image quality is? She’s like my dad in the above example.

    “That you do not know too much about resolution, you have shown, because you do not even knew why your first Scanlines the image only darkened. Why that was the case, I have explained to you in the thread as if you wanted me and all people realize the first time that can not be good only your picture settings handsome and all settings.
    I could go on to list examples which show that you have as you pretend less idea.”

    This paragraph makes almost no sense but I’ll try to reply anyway. Now you are trying to personally slander and insult me for some reason by accusing me of “not knowing about resolutions?” Huh? What happened is that I accidentally uploaded the included scanline overlay that came with Retroarch rather than the new one I made that had the same file name. You do know that the one that just darkened the screen was the one included with retroarch, right? And that the corrected versions are ones I made and uploaded? I guess those retroarch developers don’t know too much about resolutions, either. :)

    Anyway, it’s strange behavior that it should darken anyway- most computers will take a larger overlay and scale it down using nearest neighbor or something. So really, even if it had been my fault it would have been an honest mistake resulting from not knowing the eccentricities of the raspberry pi.

    So you can drop this attempt to slander and insult me right away.

    Let me say that you are taking this all way too personally. There are real flaws in your picture settings and this is not a matter of mere opinion. Me pointing out these flaws should not evoke this kind of reaction in you. It’s really not appropriate to be so defensive. Now you’ve gone to great lengths to draw my character into question, which is really crossing a line and quite ludicrous.

    As a final observation, my suggested settings look identical to using an XRGB-mini with an actual console on an lcd or plasma screen. The XRGB-mini is a $400 device that die hard retro gamers buy to make their retro games look better.

    patrickm
    Participant

    update; added a link to a new 1920×1080 scanline overlay. The old one was not correct.

    patrickm
    Participant

    If you just want simple bilinear filtering, this is enabled in the RGUI under settings -> video settings -> scroll to where it says point filtering and change it to bilinear

    You could also check out the blur shaders in the shaders/blur directory, but you will have to set render resolution no higher than 960×720 which will cause scaling issues on a non-720p native display. (See: “how to get perfect scaling and list of recommended resolutions”) You might not notice this, however, if using a blur shader.

    in reply to: video output is poorly configured by default. #98212
    patrickm
    Participant

    [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]

    Hi, I made an aperture grill/phosphor overlay for use on the retropie, since the shaders cause performance issues at 1080p.

    I created the overlay by drawing vertical black lines across the screen, 1 pixel wide and spaced 1 pixel apart. Combined with the scanline overlay I created, it should give a nice recreation of the phosphors on an aperture grill CRT.

    However, I’m noticing some strange issues when I apply the overlay. There are numerous artifacts when the overlay is applied. The most noticeable is a diagonal tear going from the bottom left to the top right, with the upper half of the screen being significantly lighter colored. There is also a vertical line extending from the center of the screen straight up.

    do you have any idea what could be causing these artifacts?

    patrickm
    Participant

    [quote=98195]The dropbox files worked, something probably got corrupted during attachment.

    Thanks!

    [/quote]

    Glad you got it working, I’ll add the links to the OP

Viewing 35 posts - 36 through 70 (of 149 total)