1080p scaling and scanlines without borders from integer scaling

Welcome Page Forums RetroPie Project Video Output on RetroPie 1080p scaling and scanlines without borders from integer scaling

This topic contains 16 replies, has 3 voices, and was last updated by Profile photo of patrickm patrickm 1 year, 11 months ago.

Viewing 17 posts - 1 through 17 (of 17 total)
  • Author
    Posts
  • #101839
    Profile photo of dankcushions
    dankcushions
    Participant

    NOTE: when talking about console ‘resolutions’ below, I’m talking about the resolutions displayed by the emulators. Most old consoles have an amount of (usually) invisible ‘overscan’ which is a side-effect of CRT tvs, but it seems that most emulators crop that out automatically, leaving you to worry about the ‘visible’ bit only.

    Meaning no disrespect to patl and co for their excellent work achieving pixel-perfect scaling and scanlines in the other threads (eg http://blog.petrockblock.com/forums/topic/scanlines-overlays-an-configs-for-softer-look/), I’ve been trying to find a way to get a nice scanline effect, AND an image that fills the entire vertical of a 1080p screen, without minimal distortion to either, and I think I think I’ve finally got something that I can live with.

    THE PROBLEM
    Most console systems and arcade games from the 80s until the mid 90s, output in ‘raster’ resolution, which seems to almost always be 320×224. With a modern 1080p screen, you have an issue where there’s no way of dividing the vertical number (224) in to 1080.

    Your options are:

    1. scale each pixel to represent 4×4 1080p pixels (ie, 4*224=896 pixels high), BUT this leaves you with black borders on the top and bottom of the image
    2. scale each pixel to represent 5×5 1080p pixels (ie, 5*224=1120 pixels high), BUT this means you will cut off the top and bottom of the image, which often contain important score/credit info
    3. turn off integer scaling and let the emulator work it out, BUT this ends up with ugly thick rows of pixels where they’ve clearly been expanded at a different size to their neighbours, to make the maths work

    Option 1 is detailed in patl’s thread linked above. This works for many people and is absolutely the best way to get a 100% correctly scaled scanline image on a 1080p screen.
    Option 2 is sometimes acceptable – eg, some games will treat the top and bottom extremes as potentially being hidden on some TV sets, so crucial information won’t be displayed there (eg, Mario Bros on the NES)
    Option 3 bugged me. How come I’m noticing one row of pixels being 1/1080 bigger than another?! This set me off…

    THE SOLUTION (SORT OF!)
    By default in Retropie, Retroarch runs at 640×480, regardless of your video output setting. This explained the scaling issues to me – in trying to fit 224 into 480, it has to DOUBLE the size of the occasional row of pixels. If you change your Retroarch render resolution to ‘output’ in the launch menu (press ‘x’ on a keyboard when a rom is loading), it will render at your output resolution (1080p), and suddenly scaling is much better! I can’t notice any thick rows of pixels at this resolution.

    What about scanline overlays? These have the same issue. How do you create a scanline image which fits 224 scanlines, in 1080 pixel high image? The maths doesn’t work! What I’ve done is tested out a variety of image scaling techniques, and believe I’ve found the best fit with ‘linear’ scaling. I’ve generated a 1080p overlay .png, with 224 lines of scanlines. If you look closely at the screen, you might see a few instances where the lines aren’t exactly lined up with the pixel edge, but it seems very rare, and unnoticeable (to me!). NOTE: I always set my scanlines to .35 opacity. This keeps them visible, but doesn’t darken the image (much). You may want something else…

    This last bit is optional, but I’ve had good results with the dotmask retroarch shader. It gives a subtle ‘aperture grill’ effect on the image, softening the edges a little, without blurring. To add this, go into the the Retroarch menu (select + X for me), core options > video > shaders > shader pass to 0 > select the dotmask.glsl in opt/retropie/emulators/retroarch/shader/crt/, leaving both options as ‘don’t mind’

    RESULTS
    Here are a couple of screenshots. Will probably look weird at anything less than 1080p, but you can get the full thing if you download them.

    Sonic 1 (MEGADRIVE/GENESIS)
    Full download: http://s304.photobucket.com/user/dankcushions/media/sonic1080p_zpseozbwnax.png.html?o=0

    Windjammers (NEOGEO)
    Full download: http://s304.photobucket.com/user/dankcushions/media/wjammers1080p_zpsphu6m64x.png.html?o=0

    224 vs 240
    Whilst most systems will output 224 lines, some will use 240. Below is a list of systems I’ve tested, and their resolution. Use this when choosing what scanline overlay to use:

    • NES: 224
    • SNES: 224 (all games?)
    • Megadrive/Genesis: 224
    • NeoGeo: 224
    • Mame/FBA: 224/240/others (depends on game)
    • PlayStation: mostly 240, some different (depends on game)
    • (will add more!)

    INSTRUCTIONS

    1. Extract the 2 attached zip files file to /opt/retropie/emulators/retroarch/overlays
    2. launch any game on the system and hit X during load to get into the launch menu. Set ‘Retroarch render res’ to ‘output’
    3. Go into the retroarch menu (select + X by default)
    4. Frontend Settings > Video Settings > Turn OFF Integer Scale
    5. Frontend Settings > Video Settings > Turn OFF HW Bilinear Filtering
    6. Frontend Settings > Video Settings > Aspect Ratio Index to ‘config’ (not sure what this does but it helpfully refreshes the display)
    7. Frontend Settings > Onscreen overlay settings > Display Overlay ON
    8. Frontend Settings > Onscreen overlay settings > Overlay preset > select the one we uploaded in step 1 – choose the correct scanline for the system/game based on the ‘224 vs 240’ table above
    9. Frontend Settings > Onscreen overlay settings > Overlay Opacity 0.35 (try higher if you like darker scanlines)
    10. Frontend Settings > Onscreen overlay settings > Overlay scale 1.00
    11. Core Settings > Shader Options > Shader Passes 1
    12. Core Settings > Shader Options > Shader #0 > opt/retropie/emulators/retroarch/shader/crt/dotmask.glsl (leave both settings as ‘don’t mind’)
    13. Core Settings > Shader Options > Apply Shader Changes
    14. Frontend Settings > Configuration Settings > Save Config on exit to ON (this saves when we exit the game – might want to turn this off later, in case you mess anything up later by accident)
    15. Exit the menu (select + x again) and have a look 🙂

    NOTE ON MAME:
    Since Mame/FBA emulators don’t emulate one single system, there is a variety of resolutions being used. It seems like almost all Mame/FBA games are 224 or 240 resolution. The former is covered above, but I have created a 240 line 1080p scanlines for the latter. The instructions are the same, but rather than amend your core retroach.cfg, you will be better off just adding the relevant overlay cfg line in your custom rom config file (accessed in the launch menu) (there is currently a bug with this – https://github.com/RetroPie/RetroPie-Setup/issues/899#issuecomment-120598388).

    TO DO:
    – do similar instructions/scanlines for the vertical oriented systems, eg CAVE shooters, which need vertical scanlines

    #101854
    Profile photo of Floob
    Floob
    Member

    Thanks for putting so much effort into looking at a way of improving the video output. I’ll try them out soon.

    If you like, I could look to incorporate your settings as an option in the video manager tool I have, so that users dont need to make any changes in RGUI, and you can change the settings per system.

    You are welcome to test out the latest version here.
    BE WARNED it will overwrite custom settings you may have had, so dont try this on a setup you have spent weeks tweaking.

    Its set to work with RetroPie 3, not 2.6.
    https://mega.co.nz/#!2NAUwbAL!BrgkCCWMerAxKDDE_0LYtR2qKjkDN26QZbDrIuIJ_28

    When copied to your home directory

    unzip -o rp-video-manager-11-JUL-2015.zip
    cd /home/pi/rp-video-manager
    chmod 755 videomanager.sh
    ./videomanager.sh

    RetroPie help guides --> https://goo.gl/Yfy8kj
    Please read this before asking for help --> http://goo.gl/eLErnl

    #101868
    Profile photo of dankcushions
    dankcushions
    Participant

    Feel free! I’m afraid I don’t have the nerve to run it as I’ve made so many changes to my configs!

    Been trying these settings out in the imame4all libretro core. A few mame games seem to run at 240 resolution, so I’ve created scanlines for that also. I’ll upload those to my top post.

    #101880
    Profile photo of Floob
    Floob
    Member

    Can you confirm if your settings in the first post are geared to a particular system (is it just imame4all-libretro)? Then I can make sure I make it so it only affects that system.

    You should back up your image as you have made so many tweaks – you dont want to lose it!
    http://smartretro.co.uk/forums/viewtopic.php?f=3&t=58

    RetroPie help guides --> https://goo.gl/Yfy8kj
    Please read this before asking for help --> http://goo.gl/eLErnl

    #101898
    Profile photo of dankcushions
    dankcushions
    Participant

    I actually just backed up my SD card 🙂

    Yeah so these instructions are only for libretro/retroarch systems – they’re the only ones that support custom overlay images (as far as I can tell).

    I’ve added a table above to show what overlay should be used with each system – I’ll have to add to this as I test/research.

    #101987
    Profile photo of patrickm
    patrickm
    Participant

    With these settings, the overlay is being scaled with bilinear filter, which is blurring some of the scanlines and causing the moire effect you were describing. IMO this can be very distracting, particularly with vertically scrolling games.

    I’ve detailed a way to get pixel perfect scaling at 1080p while cropping both the letterboxing (the black bars) and the overscan, so that the picture fills the vertical area of the screen and the scanlines line up perfectly without scaling artifacts, cf., “how to get perfect video scaling” and “how to get scanlines.”

    There are a couple incorrect assumptions you’re making, one of which is that most systems put out 224 horizontal lines of resolution, which is not the case. If you’re losing important score/credit info, as you said you were at 5x scale, it’s likely because you are using 224 as the internal resolution instead of 240. What gets cropped at 5x scale corresponds exactly to the overscan area on an NTSC CRT TV. The remaining area is referred to as the “safe zone,” and game developers would always make sure that important game graphics were displayed within this zone (with a few rare exceptions), and they frequently made use of the overscan area to store information that the player wasn’t supposed to see (usually, to compensate for the variability in how CRTs were calibrated).

    Also, regarding opacity, IMO you’re better off setting your display’s “backlight” setting higher to compensate for the loss of brightness. (This is not the same as the “brightness” setting). For example, with 4x scanlines at 100%, you would lose 50% light output, so you compensate for this by increasing the backlight by the same amount (eg., if your backlight is at 50%, you would turn it up to 100%).

    Also, regarding the dotmask shader, it will cause a drop in frame rate and input lag, but it is slight. I’m sensitive to these things, so it ruins it for me, personally.

    With this said, could you please correct the misinformation contained in your post regarding the horizontal resolution of console systems? This kind of information can quickly and easily spread once posted, leading to more confusion and problems, and it works against the efforts of those who are working to preserve authenticity and accuracy. Thank you. 🙂

    The correct horizontal resolution is 240 for NES, SNES, Genesis, PS1, N64, PC Engine. This can be readily corroborated by using Google and searching “internal resolution (system name)”

    However, there are individual core differences and bugs where the internal resolution isn’t right, Picodrive being a notable example. So the correct resolution for a system may not be the “correct” resolution for an emulator. I’ve saved you the work by providing a list of resolutions to use in “how to get perfect scaling.”

    I haven’t tested Neo Geo, but I think it varied, with the most common being 264 with overscan (240 without)

    #101999
    Profile photo of dankcushions
    dankcushions
    Participant

    With these settings, the overlay is being scaled with bilinear filter, which is blurring some of the scanlines and causing the moire effect you were describing. IMO this can be very distracting, particularly with vertically scrolling games.

    nope, it’s not being scaled. my overlays are 1080p, so if you set your retroarch video output to 1080p, no scaling takes place. i have scaled the scanlines ahead of time in gimp, but it seems to be a subtler effect, and not noticeable (to me) – see my screenshots.

    the moire effect i’m describing is a feature of my TV (and others?) – i get it even when I’m using perfectly scaled 216 visible line games and 216 scanlines (5 x 216 = 1080 – I used a 1080p overlay of un-scaled 216 line scanlines, intiially), when the overlay opacity is too high. i think my panel doesn’t like concentric horizontal black lines and the brightness of them seems to waver (I have it set to ‘game mode’/post-processing off, of course).

    i recommend folk fiddle with the setting to see what they like.

    There are a couple incorrect assumptions you’re making, one of which is that most systems put out 224 horizontal lines of resolution, which is not the case.

    …hence i’ve got the breakout section detailing the resolution of each system, as I check 🙂 nes/snes, neogeo and megadrive are 224, which represents ‘most’ to me, but that’s my era I suppose.

    If you’re losing important score/credit info, as you said you were at 5x scale, it’s likely because you are using 224 as the internal resolution instead of 240.

    nope, I was using 216 instead of 224, in the scenario I was talking about (this is the visible area you end up with when trying to 5x integer scale on a 224 line system). you can’t show 224 lines on a 1080p screen in a 5x integer scale (5*224=1120)

    Also, regarding opacity, IMO you’re better off setting your display’s “backlight” setting higher to compensate for the loss of brightness. (This is not the same as the “brightness” setting). For example, with 4x scanlines at 100%, you would lose 50% light output, so you compensate for this by increasing the backlight by the same amount (eg., if your backlight is at 50%, you would turn it up to 100%).

    My TV doesn’t have this setting 🙁

    Also, regarding the dotmask shader, it will cause a drop in frame rate and input lag, but it is slight. I’m sensitive to these things, so it ruins it for me, personally.

    Do you have a way of measuring this? None of the retroarch emulators seem to be able to display framerate for me.

    With this said, could you please correct the misinformation contained in your post regarding the horizontal resolution of console systems? This kind of information can quickly and easily spread once posted, leading to more confusion and problems, and it works against the efforts of those who are working to preserve authenticity and accuracy. Thank you. :)

    The correct horizontal resolution is 240 for NES, SNES, Genesis, PS1, N64, PC Engine. This can be readily corroborated by using Google and searching “internal resolution (system name)”

    However, there are individual core differences and bugs where the internal resolution isn’t right, Picodrive being a notable example. So the correct resolution for a system may not be the “correct” resolution for an emulator.

    sure, I’ve added a note on what I mean by ‘resolution’ in this guide

    #102055
    Profile photo of patrickm
    patrickm
    Participant

    nope, it’s not being scaled. my overlays are 1080p, so if you set your retroarch video output to 1080p, no scaling takes place. i have scaled the scanlines ahead of time in gimp, but it seems to be a subtler effect, and not noticeable (to me) – see my screenshots.

    This is what I meant, though. You have scaled the overlay in gimp using linear filter. If you zoom in, you will see that this results in a blurring effect and alters the appearance of the scanlines in an irregular fashion. In addition, I think this darkens the image more.

    It may not be noticeable except when vertically scrolling, when it can be very distracting. The moire effect you describe is consistent with what occurs when you use linear filter on the overlay in gimp or photoshop. You want to use “nearest” or “none” to avoid this.

    The only other thing I can think of that would cause this is that your tv is not doing 1:1 pixel mapping, as in you are not in fullscreen mode but are zooming/stretching the picture somehow.

    nope, I was using 216 instead of 224, in the scenario I was talking about (this is the visible area you end up with when trying to 5x integer scale on a 224 line system). you can’t show 224 lines on a 1080p screen in a 5x integer scale (5*224=1120)

    The games were designed with overscan in mind- the safe area is 90% of the vertical area on an NTSC CRT. So if you integer scale 240 by 5x to get 1200, you lose 120 lines on a 1080p display, or exactly 10% of the vertical area. So what gets cropped corresponds exactly to the overscan area, which is perfect. You don’t want to see overscan, do you?

    Do you have a way of measuring this? None of the retroarch emulators seem to be able to display framerate for me.

    I think there’s an option to display frame rate under video settings, but I tested input lag and frame rate by just walking back and forth in Final Fantasy III. Every so often there is a skipped frame when using the dotmask shader. I’ve attempted to recreate the dotmask effect via an overlay, but the pi is doing something strange that causes bizarre artifacts when I attempt to add vertical lines that are 1px wide.

    Also, regarding the note you added, it isn’t quite correct. It just varies from system to system whether overscan is cropped or not; it causes a lot of confusion and is why crop overscan is probably going away in a future version. Crop overscan behavior is very core dependent, there’s really no generalization you can make, here.

    #102060
    Profile photo of dankcushions
    dankcushions
    Participant

    You have scaled the overlay in gimp using linear filter. If you zoom in, you will see that this results in a blurring effect and alters the appearance of the scanlines in an irregular fashion. In addition, I think this darkens the image more.

    yes, i understand how linear filtering works, thanks 🙂 I have shown screenshots with the end result. The scanlines are fine for me, especially at my preferred brightness.

    It may not be noticeable except when vertically scrolling, when it can be very distracting. The moire effect you describe fits the description of exactly what occurs when you use linear filter on the overlay in gimp or photoshop. You want to use “nearest” or “none” to avoid this.

    nope, as I say below, I got that effect when perfect 1px scanlines and integer scaling on – it’s totally a feature of my TV. using a ‘nearest’ filter would make it look awful – you get 2 pixel-thick scanlines every so often.

    The games were designed with overscan in mind- the safe area is 90% of the vertical area on an NTSC CRT. So if you integer scale 240 by 5x to get 1200, you lose 120 lines on a 1080p display, or exactly 10% of the vertical area. So what gets cropped corresponds exactly to the overscan area, which is perfect. You don’t want to see overscan, do you?

    you’re confusing ‘overscan’ with the recommended ‘safe area’. eg, snes output 240 lines (standard NTSC signal), which comes out as:

    0-6 (safe overscan area – can hide tiling garbage here)
    6-12 (most TVs will show this)
    12-228 (216 pixel ‘safe’ area – ALL tvs will show this. all important gameplay-critical stuff should be in here)
    228-224 (most TVs will show this)
    232-240 (safe overscan aree – can hide tiling garbage here)

    so most games show important graphics only in the centre-most 216, but they will normally still render the playing field up to 224. given that most consumer CRTS (especially as we edge into the 90s) showed the centre 224 with increasingly tighter tolerance, showing the full 224 is more ‘realistic’ than just emulating a rubbish TV 🙂 eg, see my sonic screenshot – there’s non-glitched graphics across the entire 224 lines.

    in the mame/neogeo/mvs area, this is very different – these games seem to almost always have important information running up to the edges of the 224 lines – my theory is that arcade CRTs were more of a known-quantity, so they didn’t have to worry about consumer TV variance. a 5x integer scale for these games cuts into the scores, credits, health-bars, etc. see my windjammers screenshot for an example.

    I think there’s an option to display frame rate under video settings

    the frame rate feature doesn’t seem to work – said this above.

    #102142
    Profile photo of patrickm
    patrickm
    Participant

    nope, as I say below, I got that effect when perfect 1px scanlines and integer scaling on – it’s totally a feature of my TV.

    It’s a feature of the image you’re using and the type of scaling that you’re applying. I just confirmed this by looking at the full size image you linked to- check the blue area in the Sonic screenshot. The scanlines in this area should be uniform at 800% zoom, but they aren’t- this can create the described moire effect.

    using a ‘nearest’ filter would make it look awful – you get 2 pixel-thick scanlines every so often.

    That isn’t related to nearest neighbor per se, it’s a function of how the image is being scaled. Nearest neighbor will result in the most accurate scaling with the fewest artifacts.

    so most games show important graphics only in the centre-most 216, but they will normally still render the playing field up to 224. given that most consumer CRTS (especially as we edge into the 90s) showed the centre 224 with increasingly tighter tolerance, showing the full 224 is more ‘realistic’ than just emulating a rubbish TV eg, see my sonic screenshot – there’s non-glitched graphics across the entire 224 lines.

    You seem to think that the padding is meant to be displayed, when it gets cropped on a CRT. Just because the graphics aren’t glitched at the top/bottom doesn’t mean it’s not padding. Notice how the score/time/rings display and the Sonic lives display is not right at the edge? That’s because some TVs would drop right up to those graphics. Heck, I’ve got a cheap Sanyo CRT that crops even more than this- the top two lines where it says “score.” This is not an old TV, but one from the mid 2000s.

    Since CRTs varied in how much they cropped, the game developers had to allow for this by placing all important graphics within the safe area. If they put those graphics right at the edge, they’d be cut off most of the time on a CRT.

    The safe area is not console dependent but depends on the CRT. It is defined as 90% of the total viewing area.

    I personally don’t see what is gained by displaying the overscan; it’s useless information that takes up display area and it isn’t authentic/accurate to how the games were displayed on an actual CRT. But whatever floats your boat. 🙂 some people just really want to see every line put out by a console, even if you didn’t see it on a TV…

    a 5x integer scale for these games cuts into the scores, credits, health-bars, etc. see my windjammers screenshot for an example.

    I haven’t looked at windjammers, but nothing important should be cropped at 5x integer if crop overscan is on the right setting for the core being used and you are scaling up from the right resolution.

    #102160
    Profile photo of dankcushions
    dankcushions
    Participant

    It’s a feature of the image you’re using and the type of scaling that you’re applying. I just confirmed this by looking at the full size image you linked to- check the blue area in the Sonic screenshot. The scanlines in this area should be uniform at 800% zoom, but they aren’t- this can create the described moire effect.

    yes, but as i said (4 times, now), I a similar effect because of my TV, even when using no scnaline. I do NOT get this effect when using lower opacity on the scanlines, scaling or not. Apparently you are unable to take my word for it, so here’s some screenshots (ignore the vertical white ‘ovals’ as they are just an effect of my phone camera):

    Wii.png scanlines, 1.00 opacity at 6×5 integer scaling (216 line image)

    Wii.png scanlines, .35 opacity at 6×5 integer scaling (216 line image)

    at 1.00 I get a strange variance between the scanlines that is distracting, to me. lower the brightness and it goes away. This was before I started messing with scaling or any scanline pngs. The scanlines are more visible in real life than the second screenshot, but I don’t get the effect.

    That isn’t related to nearest neighbor per se, it’s a function of how the image is being scaled. Nearest neighbor will result in the most accurate scaling with the fewest artifacts.

    clearly you haven’t tried it. here’s what nearest neighbour scaled (224 lines in 1080) scanlines look like close up:

    compare that to my scanlines posted in my screenshots.

    You seem to think that the padding is meant to be displayed, when it gets cropped on a CRT. Just because the graphics aren’t glitched at the top/bottom doesn’t mean it’s not padding. Notice how the score/time/rings display and the Sonic lives display is not right at the edge? That’s because some TVs would drop right up to those graphics. Heck, I’ve got a cheap Sanyo CRT that crops even more than this- the top two lines where it says “score.” This is not an old TV, but one from the mid 2000s.

    Since CRTs varied in how much they cropped, the game developers had to allow for this by placing all important graphics within the safe area. If they put those graphics right at the edge, they’d be cut off most of the time on a CRT.

    i say again, most TVs displayed the centre 224 lines. http://wiki.nesdev.com/w/index.php/Overscan: “Actual TVs show about 224 lines of the signal, hence the commonly reported 256×224 resolution. But the vertical position may be slightly off center.” – this is why almost all games will render the playing field for the full 224 lines, knowing that most users would see it, rather than show borders because some users wouldn’t. “In fact, even some CRT SDTVs made in the 2000s show more of the bottom than the top; this may be so that tickers on cable news channels aren’t cut off.” – this might account for your TV, but for those of us who want to emulate TVs from the era, showing the full 224 lines is accurate (and shows more of the game).

    I haven’t looked at windjammers, but nothing important should be cropped at 5x integer if crop overscan is on the right setting for the core being used and you are scaling up from the right resolution.

    i posted a screenshot, dude! All neogeo games are like this – go check for yourself. you even posted this earlier in the thread

    I haven’t tested Neo Geo, but I think it varied, with the most common being 264 with overscan (240 without)

    240*5=1200, which means a 1080p TV would crop out 60 pixels (12 lines) from the top and bottom of the ‘post overscan’ image.

    examples:
    windjammers (neogeo), integer scaled at 5×224

    sf3 (cps3), integer scaled at 5×224

    I’m about done with this conversation. If you’ve found a solution that works for you – great! For people who want to play neogeo or (many) arcade games, at full screen, without cropping information – this is the only solution. The rest comes down to personal opinion about what parts of the screen are important/not important, and what CRTs you are used to.

    Attachments:
    #102338
    Profile photo of patrickm
    patrickm
    Participant

    yes, but as i said (4 times, now), I a similar effect because of my TV, even when using no scnaline. I do NOT get this effect when using lower opacity on the scanlines, scaling or not. Apparently you are unable to take my word for it, so here’s some screenshots (ignore the vertical white ‘ovals’ as they are just an effect of my phone camera):

    All opacity does is adjust the darkness of the overlay. The artifacts are most likely there even at lower opacity; you’re just not able to notice them at that opacity.

    i say again, most TVs displayed the centre 224 lines. http://wiki.nesdev.com/w/index.php/Overscan: “Actual TVs show about 224 lines of the signal, hence the commonly reported 256×224 resolution. But the vertical position may be slightly off center.” – this is why almost all games will render the playing field for the full 224 lines, knowing that most users would see it, rather than show borders because some users wouldn’t. “In fact, even some CRT SDTVs made in the 2000s show more of the bottom than the top; this may be so that tickers on cable news channels aren’t cut off.” – this might account for your TV, but for those of us who want to emulate TVs from the era, showing the full 224 lines is accurate (and shows more of the game).

    the statement “most TVs displayed the center 224 lines” is misleading. The wiki page provides no source for the claim, and the claim does not account for the very wide variance in how CRT TVs were calibrated. There was no single standard, only a correct range. The safe area is 90% of the picture, and is where game developers placed important graphics. That’s all that really matters for the purpose of displaying games. The developers didn’t plan for a hypothetical average, they planned for the maximum amount that a TV would crop so that the games would look right on anyone’s TV.

    (http://www.nab.org/xert/scitech/pdfs/tv031510.pdf)

    One problem is that it looks like you are not taking into account how crop overscan behavior alters the internal resolution of the game. For example with SNES9x, turning it on alters the reported internal resolution, so when you scale up, more gets cropped off than when you leave it off.

    Furthermore, the number of lines displayed by the TV has no bearing on what the internal resolution of the system is, or what it should be set to. NES for example put out 240 horizontal lines, no exceptions. The TV would display anywhere from 90-100% of these lines so anywhere from 216-240 lines would wind up being displayed. There is no “more accurate,” here, since the amount that got displayed varied widely by manufacturer, model, and individual set.

    clearly you haven’t tried it. here’s what nearest neighbour scaled (224 lines in 1080) scanlines look like close up:

    Clearly I haven’t tried it?

    It looks like you’re scaling up from the wrong resolution and/or using bilinear filter on the overlay in Gimp. Here’s what nearest neighbor looks like with the 5x scanline overlay I’ve provided at 5x scale, using 240 as the native resolution. It’s fine. It seems like you’re doing something strange on your end that is causing the issues you’re describing.

    http://s1309.photobucket.com/user/Patrick_McCleery/media/image.jpg1_zpswuxdykgm.jpg.html

    For people who want to play neogeo or (many) arcade games, at full screen, without cropping information – this is the only solution. The rest comes down to personal opinion about what parts of the screen are important/not important, and what CRTs you are used to.

    It’s a fact that the safe area is defined as 90% of the screen- see the link I provided above. This is the area that console developers used when designing graphics. Of course, arcade games are going to be different because they were designed to run on arcade monitors which were better made and didn’t have overscan. In other words, most arcade games probably don’t use padding, which is why important stuff gets cropped off at the edges when you use 5x scale on an emulator. Another factor complicating this is that arcade monitors often used different resolutions than standard CRT TVs.

    If it really is 224 with no overscan (I think this is true for CPS) then the best you can do on a 1080p display if you want *perfect* scaling is scale up to 896, and have letterboxing equal to 184 lines, which is more than 17% of the total display area dedicated to letterboxing.

    I’m not familiar with the neo geo emulator (or the neo geo for that matter) but it’s also very possible that it’s doing something weird with crop overscan.

    However, these are unique cases- 5x scaling shouldn’t result in anything important being cropped on any other console system if the right settings are used.

    #102341
    Profile photo of dankcushions
    dankcushions
    Participant

    All opacity does is adjust the darkness of the overlay. The artifacts are most likely there even at lower opacity; you’re just not able to notice them at that opacity.

    exactly!

    Furthermore, the number of lines displayed by the TV has no bearing on what the internal resolution of the system is, or what it should be set to. NES for example put out 240 horizontal lines, no exceptions. The TV would display anywhere from 90-100% of these lines so anywhere from 216-240 lines would wind up being displayed. There is no “more accurate,” here, since the amount that got displayed varied widely by manufacturer, model, and individual set.

    what I’m doing is giving the settings for a CRT TV that would display 224 lines, whereas you prefer the settings for a one that would display 216. like you say, neither is “more accurate” so it’s personal preference/experience.

    clearly you haven’t tried it. here’s what nearest neighbour scaled (224 lines in 1080) scanlines look like close up:

    Clearly I haven’t tried it?

    It looks like you’re scaling up from the wrong resolution and/or using bilinear filter on the overlay in Gimp. Here’s what nearest neighbor looks like with the 5x scanline overlay I’ve provided at 5x scale, using 240 as the native resolution. It’s fine. It seems like you’re doing something strange on your end that is causing the issues you’re describing.

    http://s1309.photobucket.com/user/Patrick_McCleery/media/image.jpg1_zpswuxdykgm.jpg.html

    you’re not understanding what’s going on here. your screenshot is displaying 216 lines (you can tell by the amount of ‘ground’ is displaying – compare to my screenshots above of a 224 line in 1080p scaled version). your scanlines are displaying 1:1. you won’t see any scaling of the overlay unless you turn off integer scaling – ie attempt to stretch 224 or 240 lines on a 1080p.

    a nearest neighbour filter always produces the results i showed – that’s the definition of a nearest neighbour filter.

    It’s a fact that the safe area is defined as 90% of the screen- see the link I provided above. This is the area that console developers used when designing graphics. Of course, arcade games are going to be different because they were designed to run on arcade monitors which were better made and didn’t have overscan. In other words, most arcade games probably don’t use padding, which is why important stuff gets cropped off at the edges when you use 5x scale on an emulator. Another factor complicating this is that arcade monitors often used different resolutions than standard CRT TVs.

    If it really is 224 with no overscan (I think this is true for CPS) then the best you can do on a 1080p display if you want *perfect* scaling is scale up to 896, and have letterboxing equal to 184 lines, which is more than 17% of the total display area dedicated to letterboxing.

    …or you use my method. you’re welcome!

    #102379
    Profile photo of patrickm
    patrickm
    Participant

    what I’m doing is giving the settings for a CRT TV that would display 224 lines, whereas

    And I’m trying to get you to appreciate the wide variance with which CRTs were calibrated, which you don’t seem to understand. The 224 line thing is truly pulled from nowhere with no source to back it up (this is a criticism of the wiki you linked to, not you). You need to understand that CRTs were analogue- controlling the paths of individual electrons with magnets. It wasn’t an exact science. As such, even individual TVs of the same manufacturer and model number could vary widely in the amount of overscan they displayed. CRTs were calibrated by hand after they were put together. It wasn’t like there was a whole batch that displayed 224 or something like that. You couldn’t even generalize about a particular model. Each CRT is unique, like a fingerprint or something. I encourage you to actually look at a few different CRTs and measure the overscan they display- you will most likely find that no two measurement are exactly the same even when looking at TVs of the same model. Literally the only generalization one can make here is that “the important game graphics were displayed within the safe area.”

    u’re not understanding what’s going on here. your screenshot is displaying 216 lines (you can tell by the amount of ‘ground’ is displaying – compare to my screenshots above of a 224 line in 1080p scaled version). your scanlines are displaying 1:1. you won’t see any scaling of the overlay unless you turn off integer scaling – ie attempt to stretch 224 or 240 lines on a 1080p

    Nope, I’m afraid you are mistaken. The output seen in the screenshot is 240 lines with crop overscan off. That’s how many lines are being put out by the emulator in the screenshot I provided. 24 of these lines get cropped off by stretching the picture with 5x scaling so that the edge of the picture extends beyond the edge of the screen. So I’m displaying 216 lines but the output is the full 240.

    The scaling artifacts are resulting from something you’re doing in gimp most likely. Below is a screenshot taken with the internal resolution set to 224 and scaled up by 6×5. 224 makes no difference in the appearance of the overlay vs 240.

    http://s1309.photobucket.com/user/Patrick_McCleery/media/image.jpg1_zpsnt9eagkf.jpg.html

    …or you use my method. you’re welcome

    And it will result in artifacts. Sorry, but there’s no method other than the one I described that won’t result in artifacts. Bilinear filter results in artifacts by definition, that’s just a function of how it works. It takes the average of four adjacent texels and determines the color based on that.

    #102385
    Profile photo of dankcushions
    dankcushions
    Participant

    And I’m trying to get you to appreciate the wide variance with which CRTs were calibrated, which you don’t seem to understand. The 224 line thing is truly pulled from nowhere with no source to back it up (this is a criticism of the wiki you linked to, not you). You need to understand that CRTs were analogue- controlling the paths of individual electrons with magnets. It wasn’t an exact science. As such, even individual TVs of the same manufacturer and model number could vary widely in the amount of overscan they displayed.

    this is why nes/snes/md game developers always ensured they render 224 lines, as that catered for the average TV (that’s a mean average, not mode average, which is what you seem to be arguing against), and restricted gameplay-critical information to the centre 216, where they could make a reasonable assumption that this would ALWAYS be shown.

    this 224 number is important – almost every pre-HD consume console renders this amount of lines visible (their actual output resolution may differ, eg 240 lines for the snes), in most games. even PSX, saturn, etc. they’re not just putting borders beyond 216 lines, they’re outputting graphics. a great example is the PSX – some games let you adjust the video output position, but it’s normally a 224 line high image.

    what you seem to be arguing for is only showing 216 lines, which is almost a ‘worst case’ scenario for a CRT. i don’t see why you have a problem with me choosing to view all 224 lines of graphics! if you want to show just 216, ok!

    Nope, I’m afraid you are mistaken. The output seen in the screenshot is 240 lines with crop overscan off. That’s how many lines are being put out by the emulator in the screenshot I provided. 24 of these lines get cropped off by stretching the picture with 5x scaling so that the edge of the picture extends beyond the edge of the screen. So I’m displaying 216 lines but the output is the full 240.

    crikey. you’re displaying 216 lines on your TV – 216 divides into 1080, and you have one scanline per pixel line, so your scanlines cannot be stretched, so your point about nearest-neighbour filtering is not illustrated. if you do it correctly you get the effect i’ve shown – that’s how nearest neighbour works! it cannot work any other way!

    And it will result in artifacts. Sorry, but there’s no method other than the one I described that won’t result in artifacts. Bilinear filter results in artifacts by definition, that’s just a function of how it works. It takes the average of four adjacent texels and determines the color based on that.

    i’ve never said that it doesn’t – obviously it does. i just feel that for me (and I would guess others), the artifacts with a properly linear scaled 1080p scanline overlay, and a native 1080p retroarch output, are not severe, or worth letterboxing your output to avoid. i’ve got screenshots to illustrate this. it’s not perfect, but it works for me. if it doesn’t for you, that’s fine. other threads are available.

    can this please be all! 🙂

    #102387
    Profile photo of Floob
    Floob
    Member

    Its certainly making interesting reading!

    As has been mentioned a few times, people will often have their own preference of how to implement their memory of how it all used to look on their CRT, so its very hard to come up with a perfect solution.
    I’ll try to add more options into my video manager tool so people can quickly flip between different ways of doing this and choosing what they prefer.

    RetroPie help guides --> https://goo.gl/Yfy8kj
    Please read this before asking for help --> http://goo.gl/eLErnl

    #102402
    Profile photo of patrickm
    patrickm
    Participant

    and restricted gameplay-critical information to the centre 216, where they could make a reasonable assumption that this would ALWAYS be shown.

    That’s exactly the point I made two posts ago. Why are you concerned with displaying overscan? It’s almost completely irrelevant to the discussion what the number of lines rendered by the console is, since the final appearance was determined by the amount that the TV cropped, and this is what the developers based the graphics on.

    what you seem to be arguing for is only showing 216 lines, which is almost a ‘worst case’ scenario for a CRT. i don’t see why you have a problem with me choosing to view all 224 lines of graphics! if you want to show just 216, ok!

    It’s actually the completely opposite- what I describe is a best case scenario. Since the developers restricted important information to 90% of the screen, the rest was filled with padding (with the exception of arcade and neo geo) With the scenario I describe, 0 space is dedicated to padding/overscan.

    Of course, if you like overscan, then that’s a different story.

    crikey. you’re displaying 216 lines on your TV – 216 divides into 1080, and you have one scanline per pixel line, so your scanlines cannot be stretched, so your point about nearest-neighbour filtering is not illustrated. if you do it correctly you get the effect i’ve shown – that’s how nearest neighbour works! it cannot work any other way!

    I’m not even sure we’re talking about the same thing anymore- of course the image you’re using is going to look bad with nearest neighbor, because you’re trying to scale up 224 to 1080. Linear filter just happens to look better in this situation, but all you’re doing is hiding artifacts that are inherent in trying to scale up by a non-integer factor. If that’s good enough for you, then good for you. 🙂

Viewing 17 posts - 1 through 17 (of 17 total)

Forums are currently read only - please visit the new RetroPie forums at https://retropie.org.uk/forums/

Skip to toolbar