So what is the point of the integer option, and what does it need to be enabled to get the scanlines to look correct?
Will the scanlines not looking correct without integer be fixed in the next release of RetroArch?
No because itās not a problem with RetroArch. You have to account for it in the shaders themselves.
I mentioned a shader that has even looking scanlines with integer off at 1080 in this post. Iām not sure how hard it would be to adapt its technique to other shaders if you prefer them though.
Sorry BlockABoots, I misread you. Yes, you can notch up the values, but in the end you are aiming for a resolution. Itās not ā10:7 ratio and let RetroArch scale thatā, itās 3 times horizontal native resolution multiplied by 3 times original vertical resolution (disregards original native resolution aspect ratio).
Integer values is a must option, and is sensible specially on pixel level accuracy like with scanlines. Scanlines cover only 2 or 4 (not little much) pixels wide, so doing subpixel interpolation that looks good is hard on performance, and never will look as fine as with integer scaling. If you have a wide LCD (40" or more), and with integer ON image is not shrinking more than 30% I would keep that setting. With higher resolutions (1080p and above) most likely you are to find an integer resolution that is big enough.
With that said I think that custom dar should be that, custom dar, and not custom resolution. With strange ratios (10:7?) it can be hard to accomodate integer scalings, so Integer should be renamed to āinteger deviationā, 0 is integer scaling, and above that is the allowed deviation in order to fill the screen (fullscreen). So for example, for Sega Genesis I would set DAR to 10:7, and integer deviation to 0.05, and image will scale up to 1440x1080 automatically in a 1080p display. (set the lower deviation that gets size big enough to play)
I keep posting suggestions here and there and Iām not sure developers gets things noted to review, but no other than us here on the forums are the ones that use RetroArch day by day and find really what is faulty, feels odd or good. For example I was very sensible in a few revisions back when the shaders entry in RGUI was moved down to 3rd place, being the entry I use more (and more and more now with shader parameters from GUI) now itās less accessible than before.
Thanks for the informative reply dogway. I just want correct looking scanlines, aspect ration and an image that fills the height of the screen. Hopefully version 1.0.0.3 will bring some improvements, or though i dont know what fixes or updates they are adding
Thatās what we all want. For me next version is a wrap, meaning; set up what is possible and feasible and call it a day, since Iām not going to wait 6 more months tweaking and tweaking to make time only to find out whether they read what we say or not.
The good thing is that these issues are system independent, so they should go up in the preference stream, hopefully we donāt have to wait much.
Why do you feel like you need to āwaitā? All of what you want is already possible without much work. If the scanlines look bad to you, youāre using the wrong shader. Have you tried the āpixellateā shader from maisterās shader repository? It does subpixel interpolation of highly upscaled pixellated images the most optimally IMO. In full screen mode at a distance of more than 30 cm from your screen, the image just looks perfectly upscaled, as if integer-upscaled on the perfect display.
Hereās an example.
unscaled 1:1 PAR:
upscaled to 1920Ć1200 with pixellate.cg (right-click, āview imageā to see the full picture):
Hereās the same thing with 1920Ć1080 in case thatās what you have, which is more common. It still looks great.
By āit still looks greatā, I mean thereās no weird nearest-neighbor bigger pixel nonsense or blurring despite not being integer upscaled. You could apply a scanline shader alongside this shader (before or after? Iām not sure. Iām not interested in fake scanlines.) and the scanlines should look evenly-spaced.
Also, regarding the buggy behavior you found with Sonic 1, I just did some investigating of my own. It seems snes9x works properly, and so does gambatte, but if you set 1:1 PAR for Genesis Plus GX, thereās an incorrect result. Here are some screenshots demonstrating what I mean. Make sure your browser is set to 100% zoom to view these. Proper 1-to-1 pixel mapping is necessary to view these images.
As you can see, the Genesis Plus GX core seems to be bugged and reports an incorrect size (should be 320 width, I believe), so pixel perfection with this core requires a workaround. Someone should probably report this bug somewhere developers can see, such as on its github issue tracker: https://github.com/ekeeke/Genesis-Plus-GX/issues.
By the way, the reason those Genesis Plus GX images look blurry like that instead of missing lines is pixellate.cg. I always use it because I donāt want to see crappy nearest-neighbor pixel size fudging.
Thanks Lex, I guess the first part of your post goes to BlockABoots, I have no qualms on shaders.
About the Genesis Plus GX bug, itās good more people find it annoying and raise the voice. I am not going to file any ticket, IMO only developers should do that work. Developers should come here more often where the userbase dwells, report bugs, annoyances, needs and improvements. They need to keep more in contact. So if they donāt care for their work they can well leave it broken. I care for my work, not for others. This is of course, my opinion.
PD: btw, about āpixellateā, I think itās fine if you are not going to use any more shaders. You might not want to upscale in an almost nearest-neighbor algo a processed image with scanlines, for that bicubic is better. The opposite isnāt recommended either, applying shaders to a huge image can have an impact on performance.
I donāt agree with that attitude. As a user, if you care about how a program (especially a free one) works, it is a very good idea to do your best to make issues visible and easily-read by busy programmers who take time from their lives to lovingly share their work with the world.
Remember that maister and Squarepusher have been at this for years. Also, Maister has many awesome projects he spends his time on, and Squarepusher maintains and develops a ludicrous number of these libretro ports. Theyāre both extremely talented in their own ways and I feel like it would be very unfortunate and wasteful for them to spend too much of their time patrolling forums and communities when they have so many other awesome things to do. This is why I really encourage the non-programming users (testers, technically!) to make it as easy as possible for them to filter the BS and immediately reproduce the negative results the user found without trawling forums for signs of minor bugs. This is why bug trackers exist; to filter the social BS and get things going smoothly. Please use them! 
Our best is to register and be active on forums, their best is to get that feedback onto their development chain. If they donāt feel āqualifiedā for that intermediate ājobā, then they can take on somebody else. Ask yourself what is a specific emulator forum for, and you will find my answer there.
My findings are always very well explained and very graphic, and the nearest a developer I have seen around here frequently is hunterk and he is mainly knowledgeable in shader development. Maister and Squarepusher only have a peek about once a month or so, and very shallowly. Remember, we are not their guinea pigs, we are their target, without us, there is no them. Thatās how it has always been.
Squarepusher is very active in the IRC channel (#retroarch on freenode) and github.
The forum is for announcements and discussion surrounding the project. Discussion of potential bug reports can be held here, but bug trackers are for no-BS bug reports once finalized on the forums, so the coders donāt have to sift through social BS and waste their time and mental energy. IRC is for quick realtime discussion for rapid development or testing.
The developers peek shallowly because thereās a lot of BS and repetition posted here. New information is hard to come by here, but itās very easy to come by on a bug tracker.
I would guess Squarepusher would agree with me if I said non-coders who feel entitled to developers catering to them donāt deserve anything pleasant. Weāre all a community surrounding a free, open project trying to get things to happen, but the only things that really can happen are through actual testing, coding, code review, and re-testing. Sideways passive-aggressive mentions of issues instead of pleasantly clear testing and reporting in optimal channels are highly likely to result in resentment.
Maister made SSNES originally just for himself to be able to play video games how he wanted to play them, using the bsnes core with an interface he preferred. He didnāt have to release it to the public. He did it for the love of entertainment and the ideals of an open-source community, plus pride about his work. No developer of an open-source project is obligated to continue its development, nor do they deserve any amount of negative scrutiny. They should be praised, and without us, they are still there, doing their thing for themselves and each other.
Iām not trying to suck their dicks or anything. I just really admire various people who spend huge amounts of their time to develop things for free for the public, in any open-source project. They are like lab scientists, but as unpaid hobbyists; highly valuable to society, to be treasured.
So, in the end, the forum is for working together to form clarity, not demanding more of those who already freely give their time for your entertainment.
I wonder if you could add a pixellate pass to crt-hyllian-glow. I tried adding it as the 7th pass in the cgp and everything looked chunky. When I added it as the first pass the shader just didnāt work.
Yeah, I did some fiddling yesterday and figured out that pixellate is definitely bad after the 1st pass. Applying it after another shader is bad.
Ahh, too bad. I like getting as much vertical image as possible, so I just deal with the uneven scanlines with integer off. I generally only notice it on white logo screens anyways.
I was never into scanline filters until the advent of Maisterās CRT Glow shader, with its ability to retain most of the brightness youād usually lose with them. I did a screenshot comparison of Megaman X today with pixellate, crt-hyllian-glow and crt-royale. I felt the scanlines of Hyllian add some extra depth to the colors and make color transitions blend better. Pixellate looked flat by comparison. I messed around with Royaleās settings a lot, but ultimately I think it obstructs the game too much for me, so Iām sticking with Hyllian.
You talk as if I were a selfish prick that donāt care for anyone, but IMO yes, you are deifying a few folks that develop a software that simply I and a few more guys happen to like, nothing else. If we, the people who daily test this thing out donāt report or tell our experience then the program would be half good, they donāt have the horse power to test so many games and hours as we do. Not only that, without the great developers that actually made the original coreās emulators there wouldnāt be RA either. So this is not a one-way āthanksā. I also make āotherā (actually āmanyā) things for free, and I donāt keep expecting to be thanked, or approached in the way I feel. I do because I want.
An end user never should raise a ticket on a developer web, no matter how you put it, and issues/bugs never should be reported on a volatile media (chat, IRC), important things must IMO be always āwrittenā. By the way 80% the time I have gone to IRC channels, they are a group of friends telling jokes, moreover you canāt expect developers to be waiting for you at any time. End users should report in forums.
For the record I want to add that the 32x and Sega CD also suffer from this issue. I know that 32x uses another core, but it also presents the same stretched view. I am going to test next Master System and Game Gear.
This is DAR for Core Provided and 1:1 PAR (4:3 DAR), both wrong as you see:
Absolutely. If you care about the development of an application but are not in a position to contribute any code, the most valuable use of your time is functional testing and detailed bug reports. It doesnāt take a minute to register on github or whatever bug tracker the developers prefer. The more debug information the better.
If nobody has raised this under https://github.com/ekeeke/Genesis-Plus-GX/issues?state=open then I am happy to do so.
Modeler, before you do that, you should do your own testing. I canāt actually reproduce the issue Dogway is reporting, and the issue I was reporting is already reported here: https://github.com/ekeeke/Genesis-Plus-GX/issues/24 . Ekeeke explains in replies the reason Genesis Plus GX acts that way, and the aspect ratio itself seems fine anyway, so thereās nothing strange visible when upscaled.
Plus, there was a recent commit (3 days ago) which changed the way Genesis Plus GX reports its geometry in libretro: https://github.com/ekeeke/Genesis-Plus- ā¦ 7cf14523ff . There may be nothing to report.
Iām reporting an issue/annoyance, not a bug. The bug is explained here. To keep it clear, I havenāt tested which ratio corresponds to 1:1 PAR. All Iām saying is that neither āCore Providedā nor 1:1 PAR are geometry correct. Many people think that 1:1 PAR means correct geometry, and this is wrong, it only means square pixels.
For Sega Genesis 1:1 PAR is 8:7, and correct geometry is 10:7, I havenāt tested but I would bet is the same for 32X and Sega CD.
This exposes another problem on the RetroArch side. Aspect Ratios are resolution independent while āCustom Ratioā option is not. It asks you to input a width and height resolution, rendering it unusable for cross platforms (Monitor, TV, etcā¦), it should be labeled instead āCustom Resolutionā, or my recommendation, make a proper āCustom Ratioā option.
Thatās not true for the particular scenes youāve quoted, at least. Sonic The Hedgehog 1 and 2, for example, both have an internal screen resolution of 320Ć224, which is a 10:7 width:height DAR. Displaying this with a 1:1 PAR results in the characters being circular when they jump in these games, which is arguably correct. There are many who would argue that 4:3 is the correct DAR for these games because of the televisionsā shapes in the late 80s and early 90s, but I like 10:7 because the art seems to have been made for that. 8:7 never enters this, so Iām not sure why you mention that ratio.