Yes, but it doesn’t work well for every system. I tried it on Neo Geo and it was cutting off too much of the top and bottom.
I tried only on NES.
It works well for anything that was designed around consoles+consumer TVs. Neogeo games were designed around arcade monitors and would have that same area (sometimes more!) cut off if connected to a consumer TV.
Good point. I suppose I could do a core override for Neo Geo and leave the others at Custom. Thanks.
I play Neo-Geo on integer 5x and 1080p without having anything important cut off from the screen. The trick is just to actually deactivate integer scale and put the values manually. If you raise Y position 20 pixels above where it would normally fall, the information at the bottom (credits, level) will reappear entirely without cutting off anything important from the top of the screen.
Try these settings:
Aspect Ratio: Custom. Integer Scale: Off. X Pos.: 160. Y Pos.: -40. Width: 1600 (5x). Height: 1120 (5x).
Why do CRT shaders look bad without integer scaling to begin with? Aren’t they aware of the target size of the image? Why would they scale their scanlines instead of rendering them at the target resolution?
In other words, isn’t it the shader that does the upscaling? Or is it RA that does it?
They don’t look bad in general. They are aware of the target size of the image, but without integer scaling sometimes a line ends up 4 pixels thick, sometimes 5 pixels etc. which can lead to an uneven look. With integer scaling it’s made sure every line has the same thickness, which leads to an optimal look, if you don’t mind some black bars at top/bottom of the screen.
Using a display with greater vertical resolution i.e. 1440p usually solves the problem. Even when using integer scaling, the shrink becomes very small.
@RealNC The sahders must draw their magic taking in account the pixels of the original image. For example, if you have a 240p image in a nes game, the sahder will have to create scanlines between all and every single of those 240 lines… But, later on, the final image will have to be drawn to your screen, being 1080p, 4k, or whatever. If your screen output resolution (1080p for example) is not a multiplier of the original image output, that scaling the sahder is doing will never be perfect, because not every scanline will be able to use the same amount of pixels of your tv. Sorry if I’m not explaining well myself, but it’s a simple concept. Your screen can only output a single color for every single pixel. So, to draw the nes image with all of the sader additions (scanlines and other effects) equally between all of the lines, it needs to use the same amount of real pixels on your tv. If you are not using integer scaling, it will not be able to do it, and so it will have to use some of the pixels (on your tv) to draw a blend, like hunterk showed on previous post.
Recently I upgraded my gaming TV to a 4K screen, and the artifacts caused by non-ionteger scales are less visible (practically invisible on lowres ~240p content.
Of course, if you have a lowres TV or monitor, and you don’t like the integer-scale option and don’t like the artifacts on scanlines, you could still use an overlay instead of a shader. You can make an image (png) on photoshop or gimp, with black lines between transparent lines, and apply this image as overlay on your RA. It will make scanlines perfect, but they will not be synced with the lines which separate vertical pixels in your games (some black lines will be in the middle of a pixel for example).
Greetings.
I do use a 1440p display, but emulating systems like the Gamecube results in huge black bars with integer scaling. Or when cropping the “garbage pixel” areas on the NES or SNES then you don’t have 240p anymore. It’s impossible to get a usable screen size. It seems that the most logical thing to do in this case isn’t possible: supersample/downscale then feed that to the shaders.
DOSBox ECE does this. Although only on the CPU (there’s no shaders) so it’s slow. But basically, you get results that look very close to integer scaling. Example:
Integer scaling: https://i.imgur.com/eWNFvUG.png
Supersampling: https://i.imgur.com/dIQOuwf.png
If RA could do this (on the GPU though), then you could supersample a 256x224 SNES source (cropped) to 320x240 and feed that to the shader, which would then produce the final 1440p integer scaled result. That would give you a fullscreen 4:3 image.
So basically take 256x224, integer scale it to 1024x896 (or whatever works best,) then use a suitable downscaling filter (something that has good sharpness) to reduce it down to 320x240, and then give that to the shader. The resulting image quality would obviously not be exactly the same as integer scaling, but probably much better than the current plain non-integer scaling.
I understand what you mean, but it’s still a compromise. It can cause some native pixels/lines to get bigger, but not all of them. Sometimes it’s interesting to use another form of superscaling which i found to give good results with WinUAE. The idea is to increase vertical target resolution and then downsample. Due to discrete nature of displays there is no general perfect solution.
Example how to modify the preset:
scale_type0 = viewport
scale_x0 = 1.0
scale_y0 = 2.0
It should play well with most masks like in crt-geom, hyllian, aperture…the drawback is the speed gets worse as we increase the supersampling resolution.
This may sound a bit of a raw measure to some, but I found out that tweaking monitor settings - even just slightly - can substantially help in reducing/getting rid of visible, horizontal artifacts, while using shaders with integer scale turned off, on a 1080p display. Although it’s impossibile to compile a guide - due to different brands (I own an AOC G2590PX monitor), calibrations, factory settings, etc… - and the results are viarable, according to each shader, I’d suggest you to give it a try: I managed to get crt-geom.glsl to look pretty much 100% clean on solid colors, by fiddling around black levels, brightness and contrast balance, starting from a clean - as in, non ‘gaming’ - profile.