Snes black version for 1680x1050, same settings http://screenshot.net/xkwd2f3 rename the image to snes.png and snes cfg snes.zip (174 Bytes), and if you want here is same blue version http://screenshot.net/d6xv5cl. Improved snes blue version, for me best version http://screenshot.net/wyynmb9. Sega mega drive blue version http://screenshot.net/v44k0aq
This is my templates for 1680x1050 for console games, for you who want to make your own borders Templates.zip (3.01 KB) and here is templates with blue background Templates Blue.zip (3.12 KB). Put it in photoshop and create overlay. Link for how to make overlay this is for mame but works also on retroarch, https://www.youtube.com/watch?v=rgHpODPe4LI just before doing this put my templates in photoshop not that universal.png
For sega mega drive, snes and nes games to work correctly with my overlays set in core configs integer scale true, aspect ratio index 22, and custom viewport_width 1280 and custom viewport_height 960 . For sega mega drive core genesis plus gx crop overscan off, for snes core bsnes balanced crop overscan on, for nes core FCEUmm crop overscan on, for nestopia you need to use crop overscan on and in core options make sure mask overscan horizontal and mask overscan vertical is enabled, for other systems needs to be tested.
I have a bunch of scanline overlays to add to the repo but I’m afraid I’ll break something. (do I publish a branch before creating a pull request?)
I was wondering if these could get added to the overlays repo, under “effects\scanlines”
These could also go under “overlays\rpi”
Here are the files:
This would make the following redundant/obsolete, so they should be removed:
Also, in \rpi, can we rename “scanlines1280x720” to “scanlines1-1280x720”?
Also, I think maybe the rpi directory should be merged with overlays\effects; is there a reason why rpi has its own directory? Shouldn’t overlays work the same on rpi?
They should work the same on RPi, but that doesn’t appear to be the case, which is why I separated them out in the first place. I forget who made the RPi scanline overlays, but his screenshots showed them to be pixel perfect and other RPi users verified, but when loaded on PC, they were an uneven mess (and vice versa; that is, PC scanline overlays looked awful on RPi).
I was the one who made the RPi overlays, years ago Man, time flies…
I think they should work the same on any PC. At least, I had no problem getting them to work right on this machine running Windows 10…
They have to be used with integer scale ON and the custom aspect ratio Y has to match the Y of the overlay. So a 1920x1120 overlay has to be used with a custom aspect ratio that’s (whatever)x1120.
video_fullscreen_x/y should be left at defaults.
Are they still acting weird for you?
oh lol ok.
Might be the custom aspect ratio Y requirement that was making it weird. I tried to keep them such that all you need is integer scaling to make it fit, but perhaps that’s what’s bringing in the various between PC and RPi.
How do you do that? I was under the impression that you had to match the size of the overlay to the custom aspect ratio (at least on the Y axis) to make scanlines align correctly with the pixels.
I just match it to a multiple of 240, which should be good for anything that used a CRT TV for display (doesn’t work for handhelds unless you use a least common multiple, which I guess would be a multiple of 480 for Game Boy Advance…?)
ah, but a lot of games/cores use 224 instead of 240 (this may be related to a crop overscan setting). If you use a multiple of 240 for those games/cores you’ll always get misaligned scanlines. That’s why so many options are necessary. I’ve made overlays for 3x-5x scale for both 224 and 240, with different levels of overdrive/glow effect, which is why there are so many options. I could have adjusted the overdrive/glow in even finer increments but it seemed excessive. Each overlay is a 50% reduction in brightness when opacity is at 100%.
Anyhoo, the overlays in \rpi\ appear to be working fine on this machine running Windows 10. Integer scale on the Y axis has to match the Y of the overlay being used. I made overlays for 3x ,4x and 5x scales for 224 and 240, so I think that covers all cores/games except for maybe some arcade games. There are a few changes I’d like to make:
Could we merge \rpi\ with \effects\scanlines\ ? I think that makes more sense.
Could we add these overlays to \effects\scanlines? (Dropbox link in post 25)
Could we delete ”scanlines1920x1080” and “scanlines1920x1080-5x” from \rpi? They are redundant with the new overlays; options 1 or 2 for 4x (896, 960) and 5x (960, 1120, 1200) do the same thing.
Can we also delete “scanlines1280x720” in \rpi? It’s redundant with the new 3x overlays.
Hi guys, I’ve used for a very long time scanlines1920x1080, scanlines1920x1080-5x and scanlines1280x720 and they all work pixel-perfect on my PC and Lakka/RPi.
Why are new ones necessary?
Never an issue for me.
@Nesguy I see the difference, it is between using
overlay0_full_screen = true
overlay0_full_screen = false
in the cfg file.
Great, that’s exactly what they should be doing and it’s why I’ve been saying that \rpi\ should be merged with \effects\scanlines.
The old overlays are included with these new overlays. Option 1 at 4x and options 2 and 3 at 5x do the exact same thing as the old scanline overlays located in \rpi. Not shown below, but option 1 at 3x is the same as the old 1280x720 scanlines.
I’ve already explained this but I’ll go ahead and try again.
I created new overlays to have different amounts of scanline overdrive/glow effect, and different levels of scanline beam width variation. I did this by altering the LCh lightness value in increments of 5 for each of the scanline patterns, raising the lightness of the outermost lines and lowering the lightness of the innermost lines. This results in the number of options that I’ve provided. Adjusting LCh in finer increments seemed excessive and unecessary. All overlays result in a 50% reduction in brightness when opactiy is adjusted to 100%. Here are all the patterns used; the numbers represent black% (100 is full black).
896/960 resolution (4x vertical scale): 1) 100 0 0 100 2) 50 0 50 100 3) 55 0 55 90 4) 60 0 60 80 1120 resolution (5x vertical scale): 1) 100 0 0 0 100 2) 100 0 0 100 100 3) 100 25 0 25 100 4) 95 30 0 30 95 5) 90 35 0 35 90 6) 85 40 0 40 85 7) 80 45 0 45 80 8) 75 50 0 50 75 9) 70 55 0 55 70
Yes, that’s great. It looks like the old overlays are doing exactly what they should be doing, which is what I said they should be doing, which is why \rpi\ should be merged with \effects\scanlines.
You can check out some examples using the new overlays here.
(seriously, how can I make this easier to understand? I’m at a bit of a loss, here. Am I providing too much information all at once, or am I not providing enough information? I’ve already answered your questions in previous posts but apparently I’m not being understood/not getting my point across, so how can I improve my communication? What am I doing wrong, here?)
First of all, I appreciate the work on the scanline overlays, thanks! My suggestion was to leave the RPi overlays as they are since they work well and are easy to find.
The post above is a good summary. After some thought I understand why using ‘overlay0_full_screen = false’ could be useful, it make the use of overlays independent of the users screen resolution. However, in my opinion it makes the selection rather unintuitive with so many options available.
If regular 720p or 1080p are assumed then using ‘overlay0_full_screen = true’ would reduce the number required to just the three basic ones 720p 3x, 1080p 4x and 1080p 5x (for each pattern).
Maybe each pattern could have a name for easier identification, for example option 1 could be ‘sharp’. Of course, it’s up to you.
Happy to hear that you’re finding them useful!
I’d like to remove them because they’re redundant with the new options, and then merge \rpi\ with \effects\scanlines\
I’d rather work on getting all of the existing overlays to work consistently with all platforms and avoid having a separate directory for each platform, just for the sake of simplicity, but I’ll leave this decision to whoever decides such things.
Okay, I’ll look into this and see if I can reduce the number of overlays that way.
I could add “(sharpest)” to option 1 and option 2, where necessary. I could add “(maxglow)” to the highest numbered options. Would that make things easier? It’s a bit of a pain to edit all the necessary files so I’d like to decide on some easy to understand labels before I go changing things.
Just wondering; can I use the instructions here to submit proposed changes to the overlays, cloning the overlays repo instead of the docs repo?
yeah, should be essentially the same process. I’m planning to add your overlays soon, but I wanted to wait until the release cycle is over and once we get all of the stuff from this thread settled (I think it pretty much is, but I’d rather do one commit when we’re sure than do a bunch of commits while we sort things out).
TL:DR; Using RA’s overlay system, is there a way to tile a .png overlay across the screen the same way GIMP tiles an image with filter->map->tile?
I’m having trouble following this. If I set “overlay0_full_screen = true,” then the overlay gets scaled to whatever the resolution is set to. So, for example, if I’m using a 4x overlay that’s 896 pixels tall, and the 4x custom ratio of the game is actually 960 pixels tall, then the 896 image gets scaled to 960 pixels tall, which results in uneven and misplaced scanlines. If, on the other hand, I’m using a 4x overlay that’s 960 pixels tall with a game that has a 4x custom ratio that’s 896 pixels tall, you still get weird and misplaced scanlines.
I’m not sure how to make just one overlay for each pattern for 3x, 4x, and 5x without tiling the image. If there’s some way to tile a png across the screen (the same as GIMP’s tile function), then I could make one overlay image for each pattern for 3x, 4x, and 5x. For example, you could just make one image that is 5 pixels tall and 1 pixel wide for each of the 5x scanlines patterns, and then tile the image, and it would work at any 5x vertical resolution (1120 or 1200).