Kill "pixel-perfect" mode with fire 🔥🔥🔥🔥🔥
johnnovak opened this issue · comments
It is evil, so it must die.
If we let evil flourish, what makes that of us?
Summary
Pixel-perfect modes (output = openglpp and output = texturepp) prioritise 100% sharp pixels without any interpolation whatsoever over aspect ratio correctness. If the pixel-perfect scaler cannot hit the necessary integer scaling ratios to achieve an aspect ratio correct image, it will pick another pair of integer scaling factors that are close (resulting in an aspect ratio incorrect image).
This is based on two fundamentally misguided assumptions:
- The most important goal when upscaling low resolution graphics is to achieve the sharpest upscaled pixels possible on a flat-screen.
- Achieving the sharpest pixels possible is more important than aspect ratio correctness.
Both assumptions are quite wrong. Images on VGA CRT were never as sharp as on LCDs (but still quite sharp), so some very mild interpolation artifacts are more than permissible. The "bilinear sharp" shader used by default in DOSBox Staging achieves very good results with the interpolation "band" being no more than 1px wide around the "upscaled pixels", making the pixel-perfect shader not only redundant, but actually harmful (more on that below).
Make no mistake, integer scaling is still a good solution and is actually desirable for high-res content on a 1080p screen (e.g., 640x480 looks best when upscaled with a 2x scaling ratio, otherwise the interpolation artifacts will become a bit jarring even with the "sharp bilinear" shader). The big problem here is the "variable, semi-random aspect ratio" that the so-called "pixel-perfect" scaler generates (we should rename it to "aspect ratio imperfect"...)
What's wrong with it
The good part is that resolutions with square pixels, such as 640x480 or 320x240, will get upscaled to 1280x960 (assuming a typical 1080p monitor, which is still the most common type). That's nice, no doubt.
But let’s consider 320×200, the most common resolution used by DOS games. The smallest integer scaling factors for this are 5x horizontally and 6x vertically. Problem is, that won’t fit into 1920×1080… So the pixel-perfect shader will cheerfully pick the “closest” integer scaling factors that would result in an image that fits. That will be 4x horizontally and 5x vertically, resulting in a 1280×1000 image. That's bad; now the image is stretched by 25% vertically instead of the correct 20% stretch (because 6/5 = 1.2, but 5/4 = 1.25).
Now switch to windowed mode and start resizing it. As we keep changing the window’s dimensions, we could end up with a whole variety of different PARs for our 320x200 image, e.g.:
- 960x800 (1:1.333 PAR)
- 640x400 (1:1 PAR)
- 1920x1400 (1:1.167 PAR)
- 2560x2000 (1:1.25 PAR)
Imagine random people posting screenshots of 320x200 games upscaled with semi-random PARs, then entering endless debates about which is the correct one...
Solution
The solution is to completely eradicate every trace of the "pixel-perfect" mode with extreme prejudice. This means the total removal of the openglpp and texturepp output modes.
However, "snapping" the image to an integer scaling ratio in one of the dimensions (so either horizontally, or vertically, but never both) is actually desirable, and that's something that the "pixel-perfect" shader actually gets right for screen modes that have 1:1 PAR (e.g., 640x480 and 320x240).
Moreover, even for screen modes with non-square pixels, snapping the image size to the closest integer factor only vertically is often desirable and even necessary to avoid interference (moire) artifacts when using CRT shaders that produce scanlines (e.g., snapping to integer vertical scaling ratios is a must even on 4K, especially with 350 and 480-line resolutions to avoid moire).
Therefore, this useful subset of the "pixel-perfect" functionality will be retained under a different setting:
[render]
integer_scaling = off | horizontal | verticalShould be self-explanatory. none is the default—that's what you get currently with the default config. For example, when using vertical on a 1080p screen in fullscreen with 320x200 content, the resulting image will be 1333x1000 with the default sharp scaler (5x vertical scaling factor, then whatever fractional horizontal ratio we need to produce an aspect ratio correct image). We'll get "pixel-perfect" scaling vertically, and horizontally we'll get the occasional 1px wide interpolation band which is hardly noticeable. Also, in general horizontal sharpness is a lot less important than vertical sharpness for computer generated images (e.g., think about text modes).
Very nicely explained, @johnnovak !
As a long time fan of integers, as I have been using Lossless Scaling and testing it for the dev since it came out on Steam, which is by the way developed by my dear Ukrainian friend THS, I approve of @johnnovak 's solution. I think it would be optimal in fact.
Thanks for taking this on @GranMinigun! 🎉 Let me know if you want to discuss anything, I have a fairly clear idea about the implementation, but of course I'm happy for you to tackle it! Then I can focus on the screenshot ticket myself in the meantime: #2081 Teamwork! We want both to go out with the 0.81.0 release and put the whole aspect ratio fiasco behind us for once and all! 😎 🤘🏻
Just one thing that might not be completely obvious: the viewport_resolution setting should always be the limiting factor here, of course. So the integer scaled results (in only one direction) must fit within the viewport_resolution rectangle, then the other factor becomes w = h * 4/3 or h = w * 3/4.
Throughout SDL main, there's if/else exception to handle pixel-perfect separately. It would be nice to finally eliminate all those code branches.
If we still keep some form of integer scaling, handling it like bog-standard scaling would be idea (perhaps with a varying viewport_resolution to mop-up any extra between the window-size versus integer-scaled canvas, like @johnnovak mentioned).
If we still keep some form of integer scaling, handling it like bog-standard scaling would be idea (perhaps with a varying
viewport_resolutionto mop-up any extra between the window-size versus integer-scaled canvas, like @johnnovak mentioned).
Stuff like viewport_resolution = 80% sets the resolution relative to the desktop size, not the window size, so yes, that could technically work at the implementation level.
Just to confirm @GranMinigun, I think the guy who raised this issue #915 you referenced wanted totally independent per axis scaling. E.g. you could end up with a half-wide or double-wide picture in the incorrect aspect ratio. We most definitely don't want that; the goal of this change is to make it impossible for DOSBox to generate an AR-incorrect image with aspect = on.
- If it is a separate setting, what should it be called? Proposal:
integer_scale = off | horizontal | vertical - How this setting should interact with the current behaviour of double-scanned display modes? Just use the original size in calculations?
- How this setting would interact with possible future pre-scale/oversampling feature?
- That's fine too, maybe better than my initial suggestion:
[render]
scaling_constraint = none | vertical-integer | horizontal-integerI think I like your idea more.
-
It cannot use the original size because then the shaders won't work properly. E.g. 320x200 hardware-accurately "upscaled" to 640x400 must be vertical-integer-scaled to 800, 1200, 1600, 2000 etc. Using the original 320x200 in this case is not an option as it would yield incorrect results if vertical integer scaling is enabled, because you'll get moire quite easily. With
force_vga_single_scanyou'll get 320x200, and that you could upscale to 200, 400, 600, 800, etc. -
Input texture size is always fixed, e.g. 640x400 for double-scanned VGA. What this setting controls is the output size, effectively (
rubyOutputSize). So I'd implement oversampling as oversamplingrubyOutputSize. Mind you, typically people use vertical oversampling to make non-integer scaling ratios a possibility. But doing it this way would be consistent and logical.
EDIT: Could be I'm wrong about this. Maybe you'd really want to run the shader at integer vertical scaling ratios when oversampling, then scale back to whatever output size we have. Will need experimentation, and let's defer that decision until we can play around with it.
EDIT2: Okay... after coffee I'm pretty sure what we want for the oversampling is to render at an oversampled integer factor, then downsample to whatever our output res is (with bilinear). But let's shelf it because I'm pretty sure in the RA pipeline you can oversample per pass as well... It gets complex, so I'd defer this until the RA pipeline is in place. We might not even need to do anything extra on top of what the RA pipeline is doing to get oversampling support, that's my hunch.
So you are going to entirely drop such an important and fundamental feature as pixel-perfect scaling basically just for simplifying maintenance and simplifying handling window size in windowed mode. Pretty impressive.
You cannot be serious about this as a reason:
Imagine random people posting screenshots of 320x200 games upscaled with semi-random PARs, then entering endless debates about which is the correct one...
@Marat-Tanalin -- our implementation was not your implementation.
Our prior implementation allowed the resulting rendered output's aspect ratio to actually differ from the source platforms actual aspect ratio, in exchange for being able to multiply the width by an integer and the height by (possibly a different) integer.
The result was an image that was (typically) stretched vertically or horizontally - and often severe enough that I had longtime DOS experts, like eXo, telling me "Surely, you can't be serious that this result is perfect".
Obviously what we want is integer scaling that achieves the same aspect ratio as the source. And that's what has been implemented by @GranMinigun in his follow-up PR (and yes, your implementation would have done the job as well).
So you are going to entirely drop such an important and fundamental feature as pixel-perfect scaling basically just for simplifying maintenance and simplifying handling window size in windowed mode. Pretty impressive.
"Just for..."? No; the purpose is indeed not to simplify the code.
The purpose is as @johnnovak wrote in the issue body, and I summarized above in my response to you, because I'm not sure you read the issue's body.
Simplifying the code is merely a knock-on benefit, while still gaining correct-aspect integer scaling. 🎉
our implementation was not your implementation.
I am aware that you used an implementation by @ant-222.
The result was an image that was (typically) stretched vertically or horizontally
This is not an issue, but an intentional result. Fwiw, high-resolution displays such as 4K provide much more precise aspect ratios than low-resolution FHD.
your implementation would have done the job as well
If you are talking about my algorithm, or my library, or the implementation in bsnes-mt, my implementation, while using my own algorithm, is similar to the @ant-222 one in terms that it uses integer scales both vertically and horizontally with an intentionally approximate aspect ratio as a result.
So you are going to entirely drop such an important and fundamental feature as pixel-perfect scaling basically just for simplifying maintenance and simplifying handling window size in windowed mode. Pretty impressive.
Please point out in the above issue comment where this is mentioned as the reason.
This is just a conclusion I made after reading the explanation. Another possible reason might be an unknown drama related specifically to @ant-222.
Simplifying the code is merely a knock-on benefit, while still gaining correct-aspect integer scaling.
Correct aspect ratio at the cost of image quality? Pixel-perfect scaling is for those who knows why they need it and who is willing to deal with resulting approximate aspect ratio.
Sharp bilinear has quite low quality on FHD which is affected by the approximate aspect ratio the most, and is unneeded on modern 4K+ displays where aspect ratio is precise enough.
Fwiw, true X/Y (like in MAME and bsnes-mt) integer scaling was basically the only feature I was interested in in DOSBox Staging. Once the feature is dropped, I’m probably going to learn how to use shaders in original DOSBox and use a shader for true X/Y pixel-perfect scaling by @tyrells.
"Surely, you can't be serious that this result is perfect".
This is a rhetorical manipulation. Pixel-perfect does not mean the result is perfect in all other senses.
I suspect it would be enough just not to use pixel-perfect scaling in DOSBox Staging by default while still allowing to use it for those interested in it.
This is not an issue, but an intentional result. Fwiw, high-resolution displays such as 4K provide much more precise aspect ratios than low-resolution FHD.
My view is "pixel-perfect" mode is mostly unnecessary on 4K. Integer scaling has a place, e.g. to achieve even scanlines by using integer vertical scaling factors, or when the upscale factors are less than about 3, then bilinear sharp starts not to look that good... But on 4K bilinear scaling "artifacts" are essentially invisible (unless you're very close to the 2x factor, but that's very atypical as DOS games don't really use higher than 640x480, except for some FPS games maybe).
That's what the new integer_scaling = vertical option does; vertical scaling will always snap to an integer factor, and the horizontal scaling will be potentially non-integer, but interpolated via either bilinear sharp with very minimal "artifacts", or becoming a complete non-issue with CRT shaders that never achieve "sharp pixels" anyway.
I put "artifacts" intentionally in parenthesis; CRT monitors were never as sharp as flat-panel displays with "pixel-perfect" integer upscaling. I strongly think this extra unnatural sharpness is a rather unfortunate side-effect and breaks pixel-art (source: having grown up in the 80s and currently owning seven VGA CRT monitors, I rather dislike "sharp pixels").
If you are talking about my algorithm, or my library, or the implementation in bsnes-mt, my implementation, while using my own algorithm, is similar to the @ant-222 one in terms that it uses integer scales both vertically and horizontally with an intentionally approximate aspect ratio as a result.
We don't agree with that approximation part; if you're of the opinion that "integer scaling" should have a hard precedence and be perfomed at all times even at the detriment of hitting the correct aspect ratios, I must strongly, vehemently disagree with you in this particular topic (but we can still be friends otherwise, hey 😄 )
So you are going to entirely drop such an important and fundamental feature as pixel-perfect scaling basically just for simplifying maintenance and simplifying handling window size in windowed mode. Pretty impressive.
Please point out in the above issue comment where this is mentioned as the reason.This is just a conclusion I made after reading the explanation. Another possible reason might be an unknown drama related specifically to @ant-222.
I have no idea what you're talking about, neither do I wish to learn about any "drama" you're referring to. If you're coming to this discussion based on some background knowledge of some "drama" we have no idea about, please stop. We were making these decisions solely with the goal of promoting authentic, aspect-ratio correct output for emulated DOS games, that's it. The maintenance aspect was never a consideration when deciding to drop this, but yeah, a beneficial (but minor) side effect.
Correct aspect ratio at the cost of image quality? Pixel-perfect scaling is for those who knows why they need it and who is willing to deal with resulting approximate aspect ratio.
We seem to have a disagreement then on what constitutes "image quality". Image quality starts with displaying the art correctly, not squashed and not stretched. Would you like to see a reproduction of the Mona Lisa printed squashed in an album because [insert weird technical reason about the pigments not aligning with the fiber of the paper or something]?
As I see, if we can't maintain correct AR, we've failed right at the start line... what comes after doesn't really matter. As noted previously, no CRT can display as sharp "pixels" as LCDs with integer scaling. Personally, I quite hate that sterile look, and objectively, that's not how these images look on real CRTs. Therefore, I would not even call the "artifacts" of bilinear sharp "artifacts"; if anything, I'd like more blur and pixel roundness, which you can actually nicely achieve with accurate VGA shaders on 4k (but sadly not on 1080p).
Moreover, "pixel-perfect" is unfortunate suggestive language; if average Joe sees that DOSBox Staging supports a "pixel-perfect" mode, naturally, he will enable it!
"You don't want pixel-perfect mode, bro? Huh? Do you want pixel-imperfect or what? Are you dense or something?"
I've seen PP mode cause a lot of confusion, and I can't count the number of times I had to explain it to people in great detail how PP prioritises integer-scaling over AR... 90% of people don't expect that at all, in my experience (and many don't even get the explanation why it changes the AR depending on the viewport size and become even more confused...)
Sharp bilinear has quite low quality on FHD which is affected by the approximate aspect ratio the most, and is unneeded on modern 4K+ displays where aspect ratio is precise enough.
I would flip this around—why would you even care about bilinear sharp on 4K, it's not even noticeable? Even nearest neighbour does a respectable job on 4K...
320x200 art upscaled to 960x720 or higher looks fine to me, would not call that low quality. Upscaled to fullscreen, it's basically perfect. Where we agree is that 640x480 must be upscaled by a factor of 2x. When your non-integer scaling factors are less than 3-3.5x, the bilinear artifacts are too noticeable (because then the 1px wide interpolation band takes up about one third of the "interpolated pixel").
Therefore, again, at 1080p you get this with integer_scaling = vertical in fullscreen:
- 320x200 -> upscaled by 4.1657 x 5 (integer vertically, bilinear sharp horizontally)
- 640x480 -> upscaled to 1280x960 (2x both vertically and horizontally)
That covers 90%+ of all DOS games right there and I strongly think it's the best possible result you can get on 1080p; PP is inferior in this case, especially if you go windowed and start changing the window size... then there's chaos and madness... AR keeps changing "semi-randomly".
Fwiw, true X/Y (like in MAME and bsnes-mt) integer scaling was basically the only feature I was interested in in DOSBox Staging. Once the feature is dropped, I’m probably going to learn how to use shaders in original DOSBox and use a shader for true X/Y pixel-perfect scaling by @tyrells.
Oh, but you should check out the numerous audio improvements! 😎
Also, I was gonna suggest the shader route. Tyrell's repo has a shader implementation of PP which works well (I played around with it). Feel free to use that, but I recommend to try integer_scaling = vertical first.
Also, I'm dead serious about the screenshot issue. That's something we'll rectify soon too (and yes, screenshots by might include bilinear sharp interpolation for more esoteric PARs, but you should be pleased to hear that 320x200 will be always integer-upscaled to 1600x1200 by default). I am rather dismayed by the sorry state of aspect-ratio incorrectness everywhere on the internet, MobyGames, random websites, YouTube, etc, when it comes to DOS-era content. It's a disease. Our team here has strong opinions about AR-correctness and want to do everything in our power to improve the situation to preserve DOS-era content in the correct AR for the future. Conversely, we're actively trying to avoid features and options that would confuse the already confusing situation even more.
Hence, PP had to die, and it was good riddance 💀
Btw @Marat-Tanalin , skimmed through your webpage (nice description of the algo, btw), and this is a major source of disagreement between us:
Umm, nope 😄 Get a CRT and play some games side-by-side with an LCD running the PP scaler...
Pixelation is an intended effect for modern pixel-art styles, which is a completely different story to what artists had to deal with in the '80-'90s. This is true not just for computer games but for consoles and arcades as well.
Pixelation is an intended effect for modern pixel-art styles, which is a completely different story to what artists had to deal with in the '80-'90s. This is true not just for computer games but for consoles and arcades as well.
Yes, that's true. Personally, I find the "blocky fake retro pixel art with HUUGE sharp perfect squares" quite hideous; it's a "romantisation"/exaggeration of a style from a non-existent past... I'm quite certain if we never had flat-panels with fixed "real pixel" grid structures, this style would never have emerged. Simplistic integer upscaling of content designed on and for CRTs also contributed. And yeah, hate to admit but probaly the hardware 2x upscaling of VGA adapters too in sub-350-line modes...
Here's some actual, authentic "pixel art"... Oh wait, where have the pixels gone? (source)
Those screenshots are being generous, too, by using the exact original aspect ratio.
Imagine the right hand images were squashed wider or stretched taller, enough to be obvious.
Which would the original artists' pick as the best preserved?
Those screenshots are being generous, too, by using the exact original aspect ratio.
Oh, actually the right hand ones use 1:1 square pixels in the Eye of the Beholder examples. The middle (CRT shader) and left (photo of actual CRT) images use the correct 1:1.2 NTSC aspect ratio.
It's a 320x200 NTSC game. Exact same deal as the 1:1.2 PAR we have with DOS.
Thanks @johnnovak - I'm "taking in" the full gestalt of the pictures now, and yes: the (right hand) gray and green stone guy's nose and brow look wider, eyes look smaller, and mouth also wider than the left two.
(Same with the red flying mouth, who now looks heftier and carrying more bodily mass on his side's 😅)
Same with the red flying mouth, who now looks heftier and carrying more bodily tissues on his side's
Yeah, the beholder looks quite squashed on the right with the wrong 1:1 PAR. They're supposed to be quite rotund; essentially they're big, evil, floating spheres! E.g.
Watchers are 6-foot-diameter spheres with three central eyes arranged around the circumference of the sphere.
My view is "pixel-perfect" mode is mostly unnecessary on 4K.
I rather dislike "sharp pixels"
Personally, I quite hate that sterile look
Yeah, it’s your view. 😉 But there are people who like square/rectangular pixels. For example, I created my bsnes fork called bsnes-mt exactly to add true X/Y integer scaling free of any distortion/shimmering. I literally couldn’t play until I wasn’t sure pixels are uniform.
if you're of the opinion that "integer scaling" should have a hard precedence and be perfomed at all times even at the detriment of hitting the correct aspect ratios, I must strongly, vehemently disagree with you in this particular topic
No, integer scaling is not something that should be forced, it should just be available as an option. Afaik, DOSBox Staging does not even use pixel-perfect scaling by default.
but we can still be friends otherwise, hey 😄
Sure. I’m totally friendly and pragmatic. 🙂
This is just a conclusion I made after reading the explanation. Another possible reason might be an unknown drama related specifically to @ant-222.
I have no idea what you're talking about, neither do I wish to learn about any "drama" you're referring to.
I have no idea whether a drama exists. I simply suspect(ed) that given that there is no any serious reason for dropping pixel-perfect scaling provided, while there are multiple signs of some emotional background:
- “Kill "pixel-perfect" mode with fire 🔥🔥🔥🔥🔥”
- “with extreme prejudice”
- “No he couldn't.”
The only “reason” for dropping pixel-perfect scaling you provided is that resulting aspect ratio is not precise, but this is how the feature works by definition, and this is how it worked when you originally added the feature.
Correct aspect ratio at the cost of image quality? Pixel-perfect scaling is for those who knows why they need it and who is willing to deal with resulting approximate aspect ratio.
We seem to have a disagreement then on what constitutes "image quality".
In terms of the difference between integer scaling and fractional scaling via nearest neighbour, image quality means perfectly uniform pixels, no distortion, and no shimmering.
Would you like to see a reproduction of the Mona Lisa printed squashed in an album because [insert weird technical reason about the pigments not aligning with the fiber of the paper or something]?
I would certainly not like to see Mona Lisa with shimmered pixels of different sizes.
if average Joe sees that DOSBox Staging supports a "pixel-perfect" mode, naturally, he will enable it!
If the problem is specifically the “perfect” word in “pixel-perfect”, “pixel-perfect” could simply be renamed e.g. to more specific “X/Y integer”, and voila, it’s not perfect anymore. 😀
why would you even care about bilinear sharp on 4K, it's not even noticeable? Even nearest neighbour does a respectable job on 4K...
Not for a perfectionist. 😉
Oh, but you should check out the numerous audio improvements! 😎
I couldn’t if there is no true X/Y integer scaling at the same time.
I recommend to try
integer_scaling = verticalfirst.
I tried it enough in bsnes’ “Center” mode before I made bsnes-mt with true X/Y integer scaling.
I'm dead serious about the screenshot issue.
Then it probably makes sense just to (solely provide ability to) take screenshots at original unscaled resolution. If not, it’s up to the end user to decide how to take screenshots and what to do with them.
Or disable pixel-perfect scaling at all specifically in windowed mode. In full screen, pixel-perfect scaling of 320×200 with AR correction results in a pretty negligible AR error of just 4% on both FHD and 4K monitors, and below 3% on QHD monitors now becoming popular among gamers.
skimmed through your webpage (nice description of the algo, btw), and this is a major source of disagreement between us:
Whether noticeable pixelation is appropriate depends on the type the original image: e. g. for pixel art, pixelation is an intended effect, so blur distorts the author’s intent.
Umm, nope 😄 Get a CRT and play some games side-by-side with an LCD running the PP scaler...
I am aware of CRT specifics. But as @GranMinigun basically said, pixel-art games are not necessarily old games. There are modern pixel-art games not intended/supposed to be played via CRT. My article you provided a quotation from takes this into account. Note that my article is about integer scaling in general and not just about old games or DOS games.
As for the way pixels looked on CRT displays (with specific smoothing, scanlines, and different pixel size depending on the color/brightness of the pixel), it can be considered a limitation of the CRT technology that was simply uncapable of displaying perfectly sharp pixels. Smoothing, scanlines, etc. and resulting increased perceived detail were just side effects of that limitation.
Modern displays are capable of displaying sharp pixels. CRT-like and pixelated representations are not mutually exclusive, both have a right to exist, and it’s up to end users to freely choose what they like.
Thanks for sharing your views @Marat-Tanalin. Yes, taking raw screenshots (the current behaviour) will continue to be an option (not enabled by default).
The "strong" (and to many of us here, rather amusing) language around the removal of the feature is rooted in our enthusiasm to correct past wrongs when it comes maintaining correct DOS AR ratios, and our strong dislike of the PP mode altering the AR even in 1080p fullscreen for many common DOS resolutions. We dislike the feature, but NOT the people who wrote or ported it -- hope that's clear 😄
What's important when it comes to graphics, how these DOS era games are supposed to look, what constitues "quality", pixelisation, etc. -- let's just say we have very different views on all that 😄 The good news is, we don't have to agree, and you can continue to use the PP shader with DOSBox Staging if you wish to do so. You seem to be uninterested in CRT shaders anyway, so the current limitation of not being able to "stack" multiple shaders (e.g. a CRT shader after the PP shader) won't matter to you.
And yeah, still inviting you to try the new integer_scaling = vertical feature; who knows, maybe you'll fall in love with it and will adjust your opinion. You'll never know until you try 😉
Have a nice day! 😄
So why not just rename to “X/Y integer” and disable it in windowed mode? 😉 It is a really smart feature added a great value to your fork.
still inviting you to try the new integet_scaling = vertical feature; who knows, maybe you'll fall in love with it and will adjust your opinion. You'll never know until you try
As I said, “Center” mode in bsnes is exactly vertically integer, and I already tried it enough.
So why not just rename to “X/Y integer” and disable it in windowed mode? 😉 It is a really smart feature added a great value to your fork.
Main reason: aspect ratio consistency across features. What if x/y mode is enabled, then should the screenshot and video captures reflect the slightly (or more than slightly) incorrect AR, or should we use the 100% correct AR in the captures anyway by default? I'd strongly think the screenshots must be always 100% AR correct by default -- but this creates a discrepancy, and comes with the very real danger of further confusing the whole AR incorrectness issue on the internet. We don't want that, and this would confuse matters too much.
Also note that in other modes such as 640x350 the AR error is way too high even on 1080p fullscreen. Same for the default 720x400 VGA textmode. In fact, none of the graphics modes before the 640x480 mode introduced by VGA in 1987 have square pixels -- yes, none of them. This would add too many errors and confusion when using these pre-VGA standards in virtually any screen mode.
As I said, “Center” mode in bsnes is exactly vertically integer, and I already tried it enough.
Okay, kinda missed that :) PP shader for you then :)
@kcgen
integer_scaling = vertical is “Y [vertical] integer, X [horizontal] fractional”.
“X/Y integer” is “Both Y and X are integer”
Oh, thanks for clarifying.
“X/Y integer” is “Both Y and X are integer”
Off topic, but merely a gentle suggestion -- the slash used in this context will be interpreted as meaning 'either-or' (and never 'and') for native English readers:
https://www.grammarly.com/blog/slash/
To indicate "or"
Often, when a slash is used in a formal or informal text, it is meant to indicate the word or. The examples below illustrate this meaning of the forward slash:
@kcgen
No problem, it could be “X+Y integer”. But in the context, it’s obvious that renaming “Pixel-perfect” couldn’t result in changing its behavior.
What if x/y mode is enabled, then should the screenshot and video captures reflect the slightly (or more than slightly) incorrect AR, or should we use the 100% correct AR in the captures anyway by default?
If the user explicitly and deliberately chose a specific scaling mode and explicitly and deliberately chose to capture the scaled image, it should be captured as is, exactly like the user sees it.
This would add too many errors and confusion when using these pre-VGA standards in virtually any screen mode.
Confusion is a buzzword used when there are no real arguments and there is just guesswork. 😉
The discussion from my end is closed; our decision is final 🤷🏻
Just a few screenshots how bilinear sharp scaling looks on 4k with integer_scaling = vertical on 320x200 content upscaled to 2667x2000 (10x integer vertical, 8.3344x horizontal)—not to continue the "argument", just to provide some tangible results to interested parties reading this thread. As expected, and as I previously mentioned multiple times, the 1px wide "sharp bilinear interpolation" band in the horizontal direction only (and only on some edges of some pixels) is virtually invisible and completely unnoticeable.
the 1px wide "sharp bilinear interpolation" band in the horizontal direction only (and only on some edges of some pixels) is virtually invisible and completely unnoticeable.
Just like the AR difference with X+Y integer.
Thanks for your comments @Marat-Tanalin, from your perspective and priorities. I feel it was constructive: understanding your perspective in more detail further clarified and cemented our projects' decision.
There are many more issues and regressions we need to knock down and drive toward a release. I feel the signal to noise has crested here (my own comments being guilty 😅), so locking it for the sake of the project efficiency only.
If more detailed discussion is desired, please carry on outside of this project.