Help fixing a major flaw in Unity2D.

No matter what I try, it seems there is no solution.

I have a simple 2D map, which just has some sprites on it. These sprites refuse to render correctly, resulting in everything from flickering, line warping, to simple pixel distortion. Each failed "solution" causes a different effect. The best I can get, still results in pixel distortion. Here is exactly the problem:



^ This is the best solution. Other "solutions" display far worse rendering.
Even with this, when pixel perfect, everything shakes violent upon moving. I have to be x2 zoomed in (4x4 per pixel) for it to not shake and render seemingly well.

Obviously without POINT filtering, it renders perfectly. However, one cannot make a pixel art game with such incredible blur.

I have tried all known solutions to this.

Pixel Snap (Makes the problem worse in every situation)
Pixel Perfect Camera scripts (Is required to get a stable image some/most of hte time, but still not always stable pixels.)
Unity Pro Feature - Mesh Type: Full Rect (Does absolutely nothing.)
Y Offset of 0.001 (Fixes the problem when camera is at Location1, but the problem persists in a different Location2. Not a real solution.
POT textures Fixes pixel distortion caused by NPOT textures, but does not fix pixel distortion caused by Unity's rendering.
Point Filtering Required to not get blurry sprites. Required for pixel perfect rendering.
TrueColor Required.
Pixels Per Unit @ 1



Is this a bug Unity is aware of?
It's pretty bad to call yourself a 2D engine (as of 4.3) and still have such a major rendering flaw, that you cannot even render pixels correctly.

 

What about turning off Anti-Aliasing? Edit > Project Settings > Quality. Under rendering.

 

No Anti-Aliasing is enabled.


Pixel Light Count: 1
Texture Quality: Full Res
Anisotrophic Textures: Disabled
Anti-Aliasing: Disabled
Soft Particles: unchecked


This happens in both Editor running the game.

Tried all the different settings.


As much of a PoS PITA it was, I restructured all of my code to make Pixels Per Unit 100, instead of 1.
There is absolutely no difference.

 

This is just how point filtering works... It's not a Unity-specific issue. Back in the old days, sprites used to move by pixels, so you wouldn't see this distortion happening, but as the hardware got better, bilinear filtering was invented to combat the exact issue you're talking about. You're asking for sub-pixel screen-movement, while using a filtering type that says to not use sub-pixel filtering. That does not compute.

Your options are:
1.) Only allow the camera's movements to move a pixel or multiple pixels at a time, but never a fraction of a pixel.

2.) Scale up your sprites in Photoshop or w/e, using "Nearest Neighbor" or "Point Filtering", and save them out and use Bilinear Filtering in Unity instead. This way your sprites will be sharp enough, but they will also be able to blend between pixels.

 

Thank you for the advice. This sounds like it has a good chance to work.

I will post any updates.

 

Point 1x1 (Pixel = 1x1 - Original Default)
This is the default, with problem.

Point 4x4 (Pixel = 4x4, so the texture is 400% enlarged.)
Camera: Zoomed out x4. I set the Camera's script's PixelsPerUnit variable from 200 to 50 ( PixelsPerUnit / 4 to compensate for the 400% enlarged texture)
This looks identical to the default Point 1x1, but the problem is significantly better. Different pixel distortion occurs, but it looks less worse, and is less common, less noticeable.

edit: Completely unacceptable. This distorts pixels even worse at some resolutions.


Trillinear 1x1
This is so blurry, it is unacceptable.


Trillinear 4x4 (400% enlarged texture AND Billinear filtering instead of Point)

This looks pretty close to the original. It is still altered quite a bit- but it's actually still pixel art - looking like it uses half-pixels at the top.
You can tell there is a slight blur visually when zoomed out, BUT it is not very noticeable. Some gamers would never notice the difference between Trillinear 4x4 and Point filtering.

edit: Most acceptable version. This still has some shaking problems though, at least in my Scene. Not entirely sure if shaking issues would occur with other people's scenes (Might be my combination with Vectrosity).




My testing was inconclusive because I did not spend enough time on it (and would need to change a good amount of code in some classes functions) BUT it did seem to resolve the issue for the most part.


It is so silly, but if you take a 40x40 texture and shrink it via the Camera size being / 4, it renders closer to pixel perfect than 1:1 pixel perfect would.

I'd call this idiocy, "4:4 pixel perfect".

It is still entirely Unity's fault renderer, which is more competent when shrinking larger textures than display accurate pixels. Of course, this makes sense because otherwise Unity would have the same problem in 3D rendering with tons of 3D flickering.

This is Unity's fault, because this is not the case in any other renderer, game engine, or game framework. This is a Unity exclusive fault, not the fault of Point filtering or Texture size. I have used several engines (mostly 2D) which are much more seamless but have the same functionality (such as using float points for player movement). Unity is obviously very good at displaying larger textures in smaller pixel areas, and very bad at displaying exact pixels at exact areas.

Obviously Unity IS capable of the same functionality of other 2D renderers, but you have to handle it with 3D methods (shrinking larger textures results in more accurate pixel rendering than rendering smaller pixels in the exact same location). Take note, that it isn't because Unity is actually rendering larger textures. The camera adjustment results in Unity rendering the exact same number of pixels as 1:1 pixel perfect would. It simply chooses the correct location for each pixel with more precision.

Of course, Bilinear filtering mode does make it even smoother than Point 4x4, although both are very acceptable solutions. At least from what I noticed when spending a few minutes moving the player around in my scene. It is hard to say if this is a definite solution, or simply the best one so far.

 

Next, I will be rendering the same pixels using Color[] arrays and Vectrosity.

Vectrosity seems fully capable of rendering pixels 1:1, with absolute accuracy.

In the end, I might simply completely discard Sprites and simply use Vectrosity to render EVERYTHING.

The pixels in Vectrosity seem to be precise and never flick or change, no matter where the camera or player moves to.

This problem is exclusive to Sprites and 4.3 functionality. So far, anyway. I will conclude with Vectrosity's success after I implement it.

 

I used Vectrosity to render everything, eliminating the Sprites entirely.

Absolutely Perfect.

Pixel Perfect.
No flicker. No twitching. No distorted pixels.

Abso. Lutely. Perfect.


Thanks Vectrosity!!!

┌∩┐(◣_◢)┌∩┐ Unity2D!

 

I cannot thank Eric5h5 enough.

Zoomed in, it is even more flawless. So smooth. So perfect. So fulfilling of my perfectionist requirement to not have ANY pixels distort. *drools*

Zoomed out? Absolutely no shaking. No twitching. No problem.

I even get better scrolling performance!


I cannot express how flawless it is now. Before it didn't just distort, it also shook the objects, the screen had mini-seizures, weird scanlines warped over it sometimes, etc.
It was partially acceptable only at x2 camera zoom, with distortion of pixels and tiny shaking at BEST.

With Vectrosity, absolutely flawless in all zoom levels (1:1, 2:1, 4:1, etc.)
If I tried zooming out to 1:1 (true pixel perfect rendering) using Unity Sprites, it would shake everything violently (violently enough to make me scream like lemongrab "UNACCEPTABLE!!!!!!!!".) With Vectrosity it is so smooth.


Unity2d.....

 

Of course, if you're using a purely shader/code method that's using anti-aliasing as well, like Vectrosity does, it's going to avoid the issue -_-. The shader is generating an image for the given area of pixels it is appearing on, it is completely different from a texture/sprite, where the information is static. Recreate this demo in GameMaker for example, the same thing would happen. Perhaps a few engines use sub-pixel rendering to get around this issue, but most don't, since it incurs a larger performance cost. You could probably modify the Sprite Shader to do sub-pixel rendering to avoid this issue.

Even textures on a 3D plane will have this issue.
Here's a post detailing the issue, not related to Unity at all.
http://stackoverflow.com/questions/...distorted-when-making-a-sub-pixel-translation

 

I don't know how other engines handle the issue, but most don't have the issue because of either their limitations or the way the engine wants you to handle assets. You don't have to get technical, because they are practical. They just work. Some of them I know force you to work in integers (no sub-pixels allowed), which can often be why, but this is not always the case.

Out of the box, this has never been a problem with any framework or engine I have used except Unity.
All others don't distort their pixels like Unity does with its Sprites.

With Unity, it is quite a significant problem as you can find post after post with this issue, and only sometimes is it resolved enough for people to be satisfied.

You will not find this to be a massive problem on any other 2D game forum.
Hence why Unity's 2D rendering is flawed, no matter if this problem exists outside of Unity. Other engines/frameworks handle it, but Unity does not.

Like I said, there is no reason to get technical, when the reality requires an engine to be practical. Having such an awful problem is just unacceptable.

You can argue, facepalm, or -_- till you are blue in the face. I have worked with several engines, and basic rendering doesn't have such silly frustrations or enormous flaws when dealing with those engines. You cannot tell me this is a problem which (practically) exists outside of Unity. Even if it does exist, the problem only exists for people working with Unity, as other engines handle things in a way as to discourage people from creating or having this flaw, or they handle the issue so as to resolve the issue in most cases. I've never worked with GameMaker, but I wouldn't be surprised if this was not a problem when working with the engine. It is quite silly to have every user have such problems in Rendering- something that is probably the most important function of a game engine.

Especially when Unity is suppose to be a 2D supported engine after its 4.3 update.
It really is not ready to be called a 2D engine, as its 2D functionality is shoddy at best.
Argue semantics, but Unity is indeed trying to be both a 3D and 2D engine, and it is capable of both (obviously, any 3D engine is capable of 2D) but the 4.3 update was suppose to make it easier. The entire purpose of an engine is to provide functionality and various features. Having your 2D rendering functionality flawed like this is unacceptable. You might as well not have the functionality, so as to encourage users to choose another engine for 2D if applicable.

Fortunately, Unity's strengths more than make up for this weakness- and then some. It would most likely not be on my list of engines to use on most 2D games though. It really needs to strengthen its 2D functionality, as so many people make 2D games with Unity. I would also not recommend the engine to others who wish to pursue 2D development, unless they wish to learn some nice lessons in component-based design. Absolutely love the GameObject-Component relationship of Unity, the Editor, etc.



TLDR: Practical > Technical. Unity2D rendering (at least for pixel perfect or retro pixel art) is not practical. If an engine's rendering functionality is questionable, its usefulness is debatable. Unity is a great engine, but its 2D rendering blows hard lemon chunks.

 

Could you post what steps you are doing that is achieving these results?

I gather you have sprites on the screen, and then moving the camera? or the sprites? How are you moving what you are moving?

I am curious because I have only done a few projects with sprites/pixel perfect, and didn't have any issues. (or maybe I didn't notice them). I tried a quick repro of what you explained, and didn't see any distortion, but I may not be doing all the steps you are.

 

Sure, I will post what I can after work. I have worked with 2d in Unity in the past, and I didn't have as many problems or didn't notice them.

It might be more noticeable just bc of the art.

I also did not have this problem when I edited textures and used SpritETile.

Thr major change is the addition of many things as their own gameobjects and sprite renderer.

When rendering large textures (my previous Tillman), or using The sprite renderer with my characters, the problem was not there or not noticeable.

Perhaps it has to deal with the dots needing to be so small and so inanimate. Or maybe it was not noticeable until I obsessed over it.
I did notice that an IDENTICAL problem occurs in the Sega game STARFLIGHT. Yet I never noticed through hundreds of hours played.

So it could be gameobjects transforms (always integers), unnoticeable unless you obsess, or what I am rendering.

It is not tje camera, as the problem disappears when the camera moves (it followedbthevplayer slowly). The problem was primarily when the camera stopped on an integer transform on certain Y positions (depending on screen resolution too)

 

I don't understand why so many people MAKE pixel art. Compared to just drawing something with basic lines, shapes, and gradients, and then shrinking it, pixel art manages the impressive feat of being both more work and looking worse. A little bit of retro here and there is all well and good, but...

 

It's an issue that becomes a lot more noticeable with slower camera movements as well, which is what I'm guessing you're having happen here?

While it has definitely become over-done now over the past few years, to say it looks "worse" is false. It's a style, it's a unique look, it doesn't look worse, you just have less to work with. Do black white photos automatically always look worse than color photos, simply because there is less color detail? No. When executed well, any style can look amazing. Sword Sworcery and FEZ are great examples of just how well executed pixel art can be, but they are also sadly the main reasons why everyone has jumped on the pixel-art bandwagon... It's the latest fad.

 

In the time and talent it takes to make a piece of pixel art, a better looking vector art could have been made. I'm open to the idea that there might somehow exist an exception, but I'm certainly not aware of any, and I don't think it really matters. Odds are, if you find a terrific piece of pixel art, it could have been stunning otherwise.

But you don't have less to work with. These games are almost entirely being made for the same modern platforms. If you're making it actually run on an ancient platform, that would be one thing, but Unity, for one, doesn't publish to outdated consoles or MS DOS. Frequently, pixels aren't even rendered as pixels, which would be too small on modern displays, but as relatively large squares. Compared to the older platforms, this actually compounds the problem, making lines that used to look okay with the blurry pixels of the time, into jaggies. This isn't even retro; pixel art didn't look like that at the time!

An unnecessary and inappropriate metaphor. We are, at this time, perfectly capable of having pixelated photos, and aside from the occasional censorship or meta-photo, we essentially do not.

Absolutely, but that doesn't mean that tying one hand behind your back just because other people did good work even with that limitation, is a good idea.

And do you think they're improved by being pixelated? Or wouldn't be improved by being smoother? Because I don't.

I wonder if these people realize how much work goes into things like that?

 

Fez would not be improved, although it's not technically pixel art since it's 3D (calling it voxel art would be more appropriate). Anyway, it's totally a matter of opinion. It's pointless telling someone that it would "look better" if it wasn't pixel art, because that's just your opinion and not a fact. Deliberately adopting limitations and working with those is part of being art in the first place.

--Eric

 

Sure, it could have been stunning otherwise, but that's not the point when it comes to ART. Under these arguments you make, we should then logically take it further and say "well it would look stunning as a photorealistic 3D model! there's no point in making it vector art".
Also, vector art isn't actually that great for game art. And drawing a higher detailed sprite is going to take more time than simpler pixel art, I'm not sure why you would think not. More detail = more time. It also makes creating the animations immensely more complicated as you have to start taking into account a lot more detail.

It was implied that I meant you had less to work with in terms of resolution, in terms of color and detail,since in the context of the discussion, we were talking about art, not hardware...

No, it's a fine metaphor. A pixelated photo is not the same thing, because it's merely low resolution with no art-direction. Pixel art is low-resolution WITH art direction, you are controlling the look in a way that is visually appealing to most people (except you apparently). Pixel art is prevalent throughout media, so what you say is false.

It's not about what's a "good idea". It's about what a person likes, and how they want their game to look visually, every style gives a different feeling. Pixel art is a style, just as realistic 3D is, just as cartoony cellshaded 3D is, just as black white is, or hand drawn like SkullGirls, and so many other styles. You're not tying a hand behind your back, you're creating what your artistic vision is.

Why does it have to be "improved", for it to be an option? It's not improved, it's merely different. If you're not a fan of games like Risk of Rain, S&S, Fez, etc... Well, that's your prerogative, but it doesn't mean everyone else liking it is wrong.

Huh?

If you believe this style has no place, then you have a lot to learn about art design theory. Truly.

 

I know your pain. I have a couple of projects that require pixel perfect too.

But I don't think it's a flaw in Unity, it's more like a lack of features to conveniently automate things, so we have to do these by hand. And since 2D features are quite new it's probably safe to assume we'll have them eventually.

 

Yes actually, the camera is very slow, and before when I had a faster camera (for testing) it wasnt even noticeable.

 

Hi,

4.3.4 has a bug where by default meshes generated for sprites have sub-pixel errors causing the artifacts you are seeing.
In 4.5 we have eliminated these errors and all sprites should work correctly with the Pixel Snapping shader as long as you have your camera setup to be pixel perfect (ortho size = screen height / 2 / pixelsToUnits). It's coming out shortly.

IIRC you can fix this in 4.3.4 by changing your texture type to Advanced and selecting Full Rect mesh type.

 

Thanks for the heads up about the fix. I was starting to get worried about how I was gonna deal with this in my new 2D project, now it seems I don't have to worry at all. Lucky me.

 

Strange, I'm not having any trouble with Unity's Sprite system in my pixel art game ^^' I'm doing some hacking though to get it to work (adding a small decimal value to the coordinates to make it look right) so if that is solved in a future Unity update, I'll be even more happy

 

Awesome!

I am so happy to see it is an acknowledged bug. In every thread I found, I never saw it as acknowledged so I assumed it was unaware or ignored.

Unity Developers are quite awesome to be so on top of things!

 

I also am having the exact same issue CarterG81 is having with my pixel-perfect scene. I did not notice it at first but I am actually porting a game from XNA (with identical artwork) to Unity and while the controls and camera are identical, the rendering is strange. Like Carter said, I too am having very bad jittering from each object on the screen. They appear to "wiggle" at low speeds, often independent directions from each other. It is very noticeable upon deceleration. I have set the camera up to ortho / pixels per unit / 2f like recommended with pixelsnap and still have the issue. Compared to XNA, it's extremely noticeable and makes jumping from platform to platform much more difficult.

Looking forward to the 4.5 update though TomasJ. I appreciate the transparency.

And as for the discussion of pixel art, it's irrelevant what one's personal opinions are about whether it's a fad or garbage or Mona Lisa. The fact is there are many developers out there like myself that for whatever reason will need a pixel-perfect render mode that is buttery smooth. Until then, I will have to work on game menus or something. Hoping easier one-way platforms make it into 4.5 as well. Thanks!

 

I resolved a lot of my problem using Vectrosity to render the entire screen, which worked...until I decided to also use Vectrosity to make smaller objects (the planets in my game). I thought that the solution of skipping Unity's Sprite Renderer entirely would resolve all problems. It resolved most, but still a problem with a kind of warp/wave effect on the screen.

So I have a very large mesh, which works perfect, but the smaller ones (10x10 to 20x20) do not have the pixel distortion, but still have a sort of "warp" over the screen as the camera stops. The warp occurs over the entire screen from right to left (because there are so many planets on the screen, so it looks like it happens on the entire screen but seems to only happen to small objects, not my much bigger background texture rendered in the same way). I notice if I change the planet's coordinates by 0.00001, it will begin to eliminate one row of pixels (like, the entire Y axis of pixels at a single X coordinate. So if it's at 0.00002, all pixels that are 1,Y will disappear. At 0.00003 all pixels that are 2,Y will disappear. Etc. As you can predict, as the camera goes from 0.00002 to 0.00009, each row disappears/appears resulting in a "warp" or "wave" like effect on the screen.

Hopefully this next update fixes all rendering problems. So odd, because no other engine I've ever used has these problems. For example, XNA or SFML render 'buttery smooth'.

 

Yep, I get the warp effect as well. We will see what the update brings I guess. Thanks for your research and making me feel like I'm not the only one having these issues.

 

It's my pleasure.

I really want to document things like this, to make people aware.

Otherwise, they'd end up like me, and wonder if they are crazy to think theres a big flaw, lol. I researched this awhile, thinking that others got it fixed, only to find out that most of them just get it to become a bit better, but never resolved entirely. For awhile I thought I was alone and everyone else fixed the problem, lol.

 

Now that the 4.5 update has been released, has anyone noticed an improvement as far as pixel rendering is concerned?

 

I saw several posts saying that it's fixed. Can you guys give it a try?

 

Seeing the exact same problems with 4.5 and to be honest, no improvement at all. Sprites still jiggle independently of each other upon camera movement. All my sprites are PoT. Disabled pixel snap and it's worse. It seems like though if I put pixel perfect sprites in odd positions like at location 4.058673 etc instead of 4, they don't get cropped or stretched. My sprites are all 2 times larger than 1 unity unit but I have a hard time believing that is related. Still getting camera jitter and weird sprite stretching during movement, even with pixel snap, although with pixel snap after camera movement completely ceases, everything is perfect.

 

Please send me a repro project. I'd like to see what's going on and make a patch asap.

 

Sure, no problem. It might take me a minute to throw it together but I think you'll see what I mean exactly. I think I will have time this weekend to do so. Thanks for the help

 

TomasJ--

I have a repro project created and also a comparison video from XNA. How do you want me to get these to you? I don't mind uploading them as I've removed everything of concern to me. Some things I've noticed just from trial and error, trying to resolve this issue is that I think there's two problems going on here. They may or not may be related.

1) The first problem I've noticed I do not think existed prior to 4.5 is a severe jittering issue with sprites as they move across the screen, most notably, the character being controlled by the player. You can even see this problem in the Unity2D sample project on the asset store (London alien game) with no alterations to code. If the player jumps or moves in the X direction, it's not smooth at all, however either because of speed or some sort of friction/physics reason, the aliens are sliding along just fine. It seems like the velocity is oscillating +/- 4 pixels at random for the player's character. I thought maybe my keyboard was giving inconsistent input, but then I tried an Xbox controller and got an identical result. Just to rule out performance on my PC (a 3rd gen Core i7 w/ dedicated graphics) or Windows 8.1, I loaded Unity on my Macbook Air in OS X Mavericks and got the same exact issue. The game did not seem to be dropping frames (and it shouldn't, this is a very basic 2d game!). To me, it seems related to either input read-in being inconsistent, or rendering issues, or some sort of friction physics issues (which I highly doubt). You can also see this exact problem in my repro project, and it seems much worse on mine due to being pixel perfect. If you disable the camera scripts and just let the player move across the floor with the cam fixed, it becomes extremely obvious.

2) 2D sprite jittering issue. As you can see in my repro project, the pickup items seem to have a mind of their own as the camera slows to a halt. I thought this was related to pixel-snap, but actually the problem still exists when I uncheck pixel-snap. I think the most obvious item is the mushroom above the highest blue tile. I've never seen this behavior in XNA, and I also created an XNA repro video where you can see that everything is silky smooth from a rendering perspective. I could not get a good screen capture that wouldn't frame drop, so I used a camera. The only jitter is caused by camera-frame drops or camera wobble.

I don't think any of these rendering issues plague Unity 3D space rendering, but for some reason they seem pretty rampant in 2D, even in Unity's own example project. I know this 2D engine is relatively new but this is really something that should be addressed before a large number of people start releasing 2D games using Unity's native rendering methods. I still have a long way to go before thinking about releasing this game into the wild, so I'm sure it will be addressed by then. Please let me know what else I can provide you to get this solved, or let me know if I need to add/remove something in my code.

Again TomasJ please let me know how you want me to get these files to you. I've uploaded them both to onedrive and I can provide links even in this post if need be. Carter, let me know if you want to see these too.

 

Just use Unity's built in bug reporting tool (Help -> Report a Bug).

As for jittering - might be related to the physics bug shipped in 4.5. I'll let you know more once the project is uploaded.

 

Excellent. I've uploaded the project and the XNA vid successfully.

 

Hi Guys, I have been following this thread for solutions to the pixel flickering when panning a 2D sprite.

Here is what i did to replicate the problem and if anyone can post some solutions, that would be great!

I am using iphone 4 res (960x640) when testing the scene in the Unity player. I created a 960x640 image which contains gridlines that are 50pixels apart horizontally and vertically and using Point filtering. Next i set the orthographic camera size to 3.2 which is derived from 640/2/100=3.2 where 100 is my sprite's pixel to units ratio.

I set the image at pixel perfect location eg. x=-3.86, y=3.28 and when i pan i make sure my camera is moved at pixel perfect location as well. What i meant by pixel perfect location is when i multiply 100 to the location vector, there should not be any fractional part.

Having done all this, i still see the flickering while i pan the camera around. If i stop panning, some of the gridlines do disappear as well. Any ideas and suggestions on how to improve this ? Thanks!

 

TomasJ, thank you for staying on top of this. Hundreds of people are very grateful for your hard work. Very much so.

That is all.

 

I've been trying to break it and cause the distortion, but I can't. So it seems like it is fully fixed for me.

Take note: I bypass the Sprite Renderer and use Vectrosity to render everything pixel by pixel. This solved the problem the best before the update, but it still had the pixel distortion occassionally on odd resolutions. This was fixed during the update, it seems anyway. Not easy to tell because of how rare it was before, but I tried messing with the resolution while moving and everything still worked great!

So for me and my weird method, it's fixed. THANKS!

 

Hi,

We've investigated the jitter and found that it can be fixed by not only snapping your sprites to pixel grid but also positioning camera the same way. I found a script online to fix this: https://gist.github.com/pixelrevision/2981863/revisions

@jackalkane with this camera controller your project does not jitter anymore.

We'll think about how to best integrate this into Unity. Maybe this functionality can be built-in to the camera component.

 

@TomasJ,

Sure enough, from what I have found you seem to be right about that part. I've reviewed the code several times and I'm still not sure exactly how it works other than scaling the viewport to some percentage, but it seems to resolve the jittery wiggly object problem and everything seems bolted down now as expected. And actually Pixel Snap seems to make no difference whether it's on or off now. Can you tell the difference?

Like you said, I think it would be a good idea to build it into the camera, perhaps toggleable by a checkbox.

Also, I suppose I should be more specific now as to what the jitter I was describing is. It is definitely clear to me now that there are two separate problems (the first one now resolved). When you move the character in the X and Y direction you'll notice a very rough, seemingly random screen stuttering, like the turtle is running through rocky molasses. Again this is the screen and its entirety, and all objects do this uniformly now with the script attached to the camera. It is occurring regardless of the script, but is now more obvious with the script since the wiggle is no longer there. As you'll notice in the XNA video, there is none of this behavior. And again this problem is the same problem present in the Platformer 2D example unity proj. I believe, as I described in my earlier post. Is this the physics bug you mentioned that was shipped in 4.5?

I really do appreciate your help on this and the relatively tiny turnaround time. I'm impressed with the Unity community thus far and I think I made the right decision choosing an engine.

Update:
I see the difference now without Pixel snap on my non-repro proj. It does seem to make a difference for some objects placed in certain positions.

 

I had your same problem so I decided to develop a plugin to solve that. It's available in the asset store: https://www.assetstore.unity3d.com/en/#!/content/14498

I hope you like it!

 

@Ozetropo

That probably would fix the pixel snapping issue and jitter that I had then (not anymore) but now I am seeing some sort of physics issue not related to pixel snapping (evident without modification in the 2D platformer example).

 

I am losing my mind trying to wrap my head around why Unity Engine insists on being difficult, lol.

I tried to get pixel perfect with a texture. Remember, before it worked perfectly after 4.6 because I bypassed SpriteRenderer and used Vectrosity. Now I am once again trying to use Sprites (.png images).

If I position the GameObject which holds the sprite at 0,0 then it does not give pixel perfect. My camera is at 0,0.

Instead, I have to offset it by half a pixel. 0.5 pixels. This is regardless of pixel per unit. So at 100PixelPerUnit it HAS to be position at (0.005, 0.005) for it to be pixel perfect at 0,0.

Obviously, I have the correct filtering and all of those settings right. The scene is blank, just with my image.

The image is 204x204.
edit: changed it to POT2 256x256 but still requires the same 0.005 offset.

This isn't a problem, but it beyond annoying. How unintuitive is it to have to remember in my mind "Always add 0.005".


edit: Actually, since I zoom in... I have to offset by 0.0055 >_<

This is so ridiculous.

 

Having the physical pixels centered over the virtual pixels makes perfect sense to me.

 

How have you gone with you endeavours? I've been down the exact same path as you with just as much frustration. It's very hard to find information about this because the problem is difficult to look up. It seems there are many different interpretations of "pixel perfect" as well.

So far every solution I've found has had a flaw and all of them completely miss one key point: once you introduce motion, be it the camera or objects, there is distortion.

I'd love to have a solution to be able to have low-resolution 2d pixel art rendered correctly.

 

This script was wonderful, it did exactly what I need to do. One thing to note is your game objects must be aligned to x/y 0.01 or higher for this to work or the pixels will still jitter and warp.

 

You can use this script HERE, to make Unity auto-snap everything to the hundredths decimal place (100 Pixel Per Units). I've found it very useful.

http://answers.unity3d.com/questions/148812/is-there-a-toggle-for-snap-to-grid.html

 

For the record, I finally found a solution. (The above pixel snap helped with placement, but ultimately does nothing to resolve Unity's 2D rendering flaws.)

The following post, blasts Unity due to the fact it is absolutely unacceptable for these flaws to remain.
http://forum.unity3d.com/threads/pixel-perfect-2d-in-4-3.210497/#post-1806724

The only working solution I've found: https://www.assetstore.unity3d.com/en/#!/content/14498

So far, it actually works.

 

guys what i have found useful is using not an ints but using sbytes. It moves my game player about every 1 - 2 pixels per update. Just an idea you guys might find useful