So, I am on a 2D project, where all the sprites are hand-drawn irl, then scanned → imported.
However, I am seeing quite the discussions and hype (even Unity made an Pixel-perfect package recently) and I would like to ask, if it does affect my game (one that isn’t focused on pixel-art, and has big sprites)
After all, I don’t want installing/configuring stuff that may worsen the visual experience in the future, so any insight would help
Yes, but on a game that is extremely zoomed out and detailed (with probably VectorGraphics implemented), does it matter? I just cannot see the point of using Pixel-Perfect in a non-retro pixel game, and I’m asking because I may be wrong (aka to make sure xD)
Pixel perfect is for a specific retro (blocky) look. Very specific, like 8 or 16 bit 2D games with low resolution. It’s not for every other 2D game and would just (slightly) make your game slower.
Yeah, all the fuzz is about lowRes. The most pressing problem for me there is warping which i see often in games and i hate it. You can see it here, i zoomed in for visibility:
You can try to enable the Red-Buttons on this Pixel-Perfect build to see some of the problems for yourself:
Some of the expandable smoothing-Settings are not refined yet but as long as the camera is set to “sticky”, everything is as pixel-perfect as it gets.
Reviving this thread from the dead as I have a good case use for pixel perfect.
For everyone who is new, Pixel Perfect is a bool checkbox setting on a Canvas component to tell the Renderer to not fuzz out on the smaller details.
So, to the good stuff.
I have a Grid Layout Group on a UI panel for an inventory.
Without pixel perfect the border of each inventory slot may… or may not get lost. Can you spot the missing edge?
And with pixel perfect… well, its perfect.
Thank you all, and goodnight. Hope this helps the understanding of where the “Pixel Perfect” case use is actually needed and why its never noticed for most games, 2D or otherwise.
Aaron Bergquist
Sr Unity Developer & 3D Art Director
Oasis Robotics Inc.
Actually I can’t see why someone would prefer NOT pixel-perfect while available.
Roughly speaking, pixel perfectness means every pixel drawn matches every texel in size and thus in color. So black is black, white is white etc, all colors and images are shown as they should, as they were designed, drawn by artist.
Pixel imperfectness on the other hand means texels not necessarily matching screen pixels in size. This wouldn’t be a problem on CRT monitors as there are no “pixels” there, but they are nearly extinct nowadays, everyone is using TFT ones.
So let’s imagine there’s a one black texel thick border on a white background that needs to be drawn on a screen in not whole pixel numbers, say in 0.5. What you will actually get here is two gray (a middle between black and white) pixels get drawn instead of one black. In other words the thin black border will become thick gray one. And I’m not saying about funky “effects” when animating and moving such crisp objects around.
So, basically speaking, pixel imperfectness means neither the size nor the color will match the design.
Well, now… All this is actually only applicable to 2D objects which aren’t going to be rotated on X and Y axes (that is, not going to be “perspectivized”). As for the 3D world, pixel perfectness is nearly always completely irrelevant because of the 3D nature (everything is rotated, scaled etc, making pixel perfectness senseless almost everywhere except maybe UI).
Of course, there are many factors influencing decisions. Pictures themselves may be drawn in a manner that don’t require pixel perfect rendering. Colors may be such that imperfectnesses are not easily perceived. Etc etc.
What I am talking about here is that there doesn’t seem to be a reason to prefer pixel imperfectness where perfectness could easily be achieved.
When your game is targeting a low-resolution rendering target, one where individual pixels are easily visible, it is increasingly important to have pixel-perfect support. If you don’t, it is common to see obvious errors in rendering where pixels are getting stretched improperly, background scrolling layers are shimmering, and the low-resolution makes all of these issues quite obvious.
With higher-resolution titles that use assets designed for those higher resolutions, pixel-perfect support is considerably more optional. The kind of errors that result from those sub-pixel calculations aren’t nearly as visible or prominent at higher resolutions. If you aren’t going for a retro-themed aesthetic style, pixel-perfect isn’t worth worrying about.
I would point to Rogue Legacy as an example of a modern game that doesn’t bother with pixel-perfect scaling. While Rogue Legacy apes some aspects of retro titles, it definitely doesn’t bother with limiting itself to a low-resolution standard, and it doesn’t bother with pixel perfection. There are numerous examples of scaled sprites in that game where the developer clearly didn’t mind if the pixels didn’t 100% line-up. Those instances are fairly few and far between, and generally don’t take you out of the experience too much. With the right game and art style, you can easily get away with ignoring pixel perfection. It isn’t required for every title.
Basically, the rule is that the lower-resolution you go, the more that pixel-perfect becomes needed. If you’re targeting the 640 pixels and below range, you’re probably going to want to stick to pixel-perfect. The further you go above that threshold, the less you need to worry about it. If you’re targeting 1080p native, you can pretty safely ignore it.
What? Dude, if i am not wasting time on striving for pixel-perfect excellence, how can i justify tinkering on my pixel-art game for several years without the remote possibility of it getting finished?
Self reflecting joke aside, Yeah, finish your game, worry about the pixels later.
Just keep in mind that some choices like smooth zooming and the size of your characters and viewport in pixels might be incompatible with pixel-perfection when added in hindsight