Open Gryzor1363 opened 1 year ago
I confirm this issue on KDE/X11 with Ares 130.1. The distortion/scaling issues are interesting.. it affects window sizes 2X,3X,4X differently.. a given shader might have the scanlines disappear entirely or become vertical, etc. depending on the sizing. If one goes fullscreen, then it really goes off bigtime. Quilez shader as an example in fullscreen will stretch to the edges of the screen, others will have scanlines appear unevenly and with uneven thicknesses.
No issues with these shaders with bsnes in Windows of course. I did not test Ares there. bsnes in KDE/X11 has the same issue as Ares does with the shaders, so this is very much a platform issue.
Quite interesting indeed, thanks for sharing . Everything you describe regarding bsnes on KDE being exactly in line with my version of Ares running on a Windows 7 x64 OS, including the disappearance of horizontal scanlines "dominated" or replaced by the vertical lines in some specific cases and shader/mask type combination (like with aperture grille with Lottes Multipass), and others being somehow crushed/shrunk as opposed to others being overblown and completely out of scale depending on windows size or it being in fullscreen.
Now I can confirm that we have Ares 130.1 behaving in the same anomalous way in KDE and W7, and so irrespective of platform. At least it seems that way. I reminds me of the benefit of being able to adjust Shader parameters "live", in-game in the future à la Retroarch or Mame, and not through manual editing of their files requiring to reload them, would be a huge boost for such experiments (and even fine-tuning when everything is fine), but that's more fodder for a feature request I suppose.
As per testing, dysfunction seems to be impacting most CRT shaders of the "quark" pack, with the notable exception of CRT-Geom and CRT Simple, following the same pattern as described above : uneven/incorrect scaling of shader texture with scanlines, resulting in vertical and/or horizontal blocking that grossly distorts the intended effect in fullscreen.
Noteworthy is that every single of the impacted shaders seem to scale correctly in windowed mode, with scaling + aspect correction, adaptive sizing and auto-centering options enabled.
For the few working ones in fullscreen such as CRT-Simple or CRT-Geom, switching from scaling to centered similarly break them in fullscreen mode, and get distorted just as the others.
I have attached the Super Mario Bros in its original NES edition as an example, since its dominantly bright and light-green tones are a good benchmark to whatever can be wrong in shading in general. Shader used in that particular sample was CRT-Royale.
As a side note, on every SNES/Sega CD/Genesis game I have tested so far (about a dozen of them), some of the shaders such as CRT-Royale render in a nearly unwatchable, anomalous, strongly flashing/flickering interlacing even in windowed mode. Maybe something to do with their palette/resolution or some other common characteristic emulated in those 16-bit machines' display ?
Shaders other than Royale behave in the same way as with NES games : render correctly in windowed, broken in fullscreen.
One final remark, even in windowed mode and a "playable" result, scaling seems different on 16-bit machines, with scanlines almost invisible and only vertical lines from the Aperture-grille mask (when applied) are visible, and the overall picture is significantly darker than it should be, which does not happen with the NES, which might be due to differences in their respective resolutions/refresh rate or per-pixel display changing one core the other, again I'm no expert, sadly. Shader used in the fullscreen images : CRT-Lottes-Multipass.
Originally posted by @Gryzor1363 in https://github.com/ares-emulator/ares/issues/541#issuecomment-1340150458