[Released]Pixel Perfect Camera

You probably don't understand how PPC works. Please see the video and read the readme.

If you want to be pixel perfect, you can't force the resulting camera orthographic size. PPC calculates and sets the camera size, taking into account the current screen size among other things and tries to select one which is as close as possible to the target size you have selected.

The only way to get PPC to choose 135 would be to force the screen size (game window in editor) to have a fixed size of 480x270 or a multiple of it. However, if you were able to do this somehow, then you wouldn't need PPC in the first place

 

Just posting to say thanks for this asset, it's really useful!

 

Has this issue been resolved? Applying PixelSnap to my cameras appears to have no effect.

On smooth-moving cameras, sprites jitter back-and-forth between pixels while the camera is in motion, and remain off the grid if the camera resolves at a non-integer position. This can be solved by snapping the camera's position to an integer each frame, but my attempts at getting something like that to look nice haven't been very successful so far.

I have my Game tab resolution set to 320x180 (and I use the Game tab's Scale slider to bounce between 1.0x, 2.0x, 3.0x 4.0x) PPC's Height is set to 90, and PPU is set to 1 to match the PPU settings of my sprites. In PPU's inspector, this gives me Size: 160.00 x 90.00, Pixel Per Unit: 1.00, Pixels: 1x [320.00 x 180.00], Coverage 100.00%) Pixel Perfect and Retro Snap have been enabled and the game objects in question which appear to jitter have PixelSnap applied to them.

Thanks for any help, and for making this in the first place, and for releasing it for free!

 

@LittleCatman yes the issue is resolved. Please read the "readme" to see how to set-up the script correctly. My guess is that you have not enabled "retro snap" in Pixel Perfect camera. See how the retro-snap demo is set-up and toggle it from the UI to understand what the "effect" of enabling it looks like.

My guess is that if you get retro-snap working, the jitter will be reduced. The script alters the position of each game object relative to the camera and then restores it. Look at the .cs file for more details.

If you don't want retro-snap, but want to eliminate jitter, even for non pixel-perfect resolutions, use the retro-snap script, after enabling the "REDUCE_JITTER" mode (just uncomment the macro in the first line of PixelSnap.cs file). This will work for every camera, even if Pixel Perfect Camera script is not used.

From your description, you appear to have set-up the script correctly. even though it's not actually needed for the resolution you are working. You result to 1:1 sprite pixel to screen pixel mapping, even if you enable of disable "pixel perfect" mode. Thus, PixelSnap should make little difference if i'ts enabled or not. PPC and retrosnap work when the screen resolution is higher and a single sprite pixel renders to more than 1 screen pixels. In your case, you are more than "perfect". If you uploaded a video of the problem you are facing, it would help.

Perhaps the problem is caused by another script that changes the object's position. See the way PixelSnap.cs works. Perhaps changing the script execution order will help.

 

Adding the 'CanvasScreenSpaceScaler' component to my canvas completely messes things up. All of my ui elements get rescaled and repositioned.

This shows what it looks like with the component disabled



As soon as I enable the CanvasScreenSpaceScaler, I get this:



The camera settings look like this:

 

@Zenix, what PPC does is correct. You have set a target height of 1.5 units and 100 pixels per unit. This is: 1.5*2*100 = 300 pixels height.

This is the ideal height that you target. PPC chooses 261,33 pixels height and uses 3 screen pixels to render an asset pixel: 3 x [384 x 261.33].

However, waht you want is a height around 784. So, you need to increase PPC's target height.

You want to use something near: 784/2/100 = 3,9 units. Or play with the slider until the result looks as expected. Then, try it for different screen resolutions. Note that if you use a smaller resolution, for example 640x480, PPC will set a small camera height and thus your canvas area will screen. This is the correct and expected behaviour if you want to be pixel perfect.

 

Hello, thanks for the great asset!

It works great in the editor, or in an exported build when in fullscreen mode.
I have noticed though that when running a game in windowed mode, the reported pixel ratio isn't correct. (I have my game set to Pixels 3x ratio, but in windowed mode the game assets are drawn much smaller, more like 2x, even though it's reported to be 3x).

Maybe you have some idea what's happening?

 

How do you read the reported pixel ratio in windowed mode if you are not in the editor?

How did you set the pixel ratio to 3x? PPC does not support setting a ratio. It calculates it depending on the target camera width or height and a lot of other factors.

 

I'm using this with unity 5.6.2 and while it works for most sprites, I have at least two tree sprites (they're 4x larger than most other sprites) that are shifting differently than everything else as the camera moves. Every instance of these sprites behaves the same way. I've watched smaller sprites very closely and can't see any shifting effects so I'm not clear what its affecting my larger sprites.

All of my sprites are 16ppu (I have them defined with that, as well as 16px in the "asset pixels per unit" field). I have followed the project setup steps listed so I've checked my texture settings, etc.

All gameobjects are renderer to exact world coordinates so they should all be moved the same. My smaller sprites vary in size but are usually around 16x16px. One of my tree sprites for example is 114x168px. I can clearly see it shifting by 1px or so in various directions as I move the camera. Compared to everything else it's very noticeable.

I'm not sure what else might help you help me, so let me know what else you need to know.

What can I do to fix this?

 

You haven't explained your PPC set-up. My guess is that you are using PPC on your camera with pixel-perfect mode enabled. You are also using the PixelSnap script on your sprites with the "retro mode" option?

Do you have a gif or a video to demonstrate the different way the bigger texture react relative to the smaller ones? If you disable "retro mode", do the bigger textures move in a different way?

Also, watch out for the script execution order. My guess is that another script is messing with the position of these sprites. I don't think that the problem is related to the texture size.

 

Here's a gif: http://helion3.s3.amazonaws.com/Sep-12-2017 10-28-45.gif

Here are my PPC settings. This is attached to my Main Camera.



As the player moves, it looks to me like everything else moves without issue, but the tree shifts left or right by a pixel or so.

The retro snap option doesn't appear to have any affect that I can see.

No script is moving the position of my sprites, these are static world objects and don't move. The camera moves as it follows the player.

I see this behavior of other "tree" sprites which are a bit smaller than this sprite, but larger than other sprites.

 

You didn't answer if you have attached the PixelSnap script on your sprites, the smaller ones and the "tree" sprites.

If you don't enable the retro-snap options, do all sprites move smoothly as expected (my guess is that the tree sprite does not jump like in the gif)? If you enable it, do all sprites move in a "snappy" way?

Try creating a demo project that demonstrates the issue and attach it here so I can take a look.

EDIT: After examining the gif, I think that the position of the tree must have a half unit offset, which the other sprites don't have. So, they don't move at the same pace (the rounding happens at different times, so they appear to move in different speeds). Since you are using 16 pixels/unit, the initial positions must be multiples of 1/16 = 0,0625. My guess is that the tree or the background do not have a position which is multiple to that number.

EDIT2: Check that your sprites don't have weird pivot point. Try changing it to center or one of the edges and see if it helps (PixelSnap script takes this into account).

 

It was the pivot. The affected trees had a pivot of x:0.55, changing that to x:0.5 solved the issue. Can you give me some insight into how pivots are used? I want to make sure I better understand what about 0.55 was problematic.

 

You still haven't answered me.. Did you use the PixelSnap script on the sprites?

The pivot is the point of the texture that will be placed at the center of the sprite. You want the pivot to be at the edge of a texel (a texture's pixel). When the texture has an even size, you can just chose 0.5 .

The reason was that the pixels of the tree texture had a non-integer distance to the pixels of the background texture when laid out on the screen (this can happen because of the pivot or wrong position of the sprite as explained earlier). While the camera is moving, the pixels of the tree snap to screen pixels at a different time than the background texture. So, the tree moves on the screen for a different relative distance to the camera than what the background textures do.

 

Sorry for not answering, I'm a little confused. The instructions in the top of this thread mention only to add the Pixel Perfect Camera script to my main camera. I've done that. I have not added "PixelSnap" classes to individual sprites. Do I need that on every single game object? It seems to work now so I'm unclear what that's for.

Regarding the pixel distance involving pivot, you're saying that since my value was 0.55 and the sprite width was 114, that meant I had 62.7px which obviously is a non-int distance. Since I use 0.5, the value is 57 which is. So to avoid this, I should always make sure that my pivot leaves whole number distances.

 

If you read the instruction (and the headers of the script files, or the first post in this thread) you'll see that PPC enables pixel-perfect rendering but does not take care of the relative placement of sprites on screen. PixelSnap script , on the other hand, (when "retro snap" is enabled in PPC camera) affects the placement of sprites. You can see the difference in the included demo or the online HTML5 demo.

My guess is that if you used PixelSnap.cs on all your sprites and enabled "Retro Snap" in PPC, this problem wouldn't appear even if using 0.55 for pivot point. Try that and let me know.

Your understanding of the pivot is correct. The default pivot, 0.5, is always good for even sized sprites.

 

I started getting this warning and it points to the screen space canvas scaler script but i can't figure out what I did that triggered it as it didn't appear earlier. Any ideas?

SendMessage cannot be called during Awake, CheckConsistency, or OnValidate
UnityEngine.Canvas:set_scaleFactor(Single)
​

I've also noticed that it's dependent on my game view resolution as to weather or not it appears whereas if it's not scaled it doesn't appear.

 

I have no idea.
Could be a bug: https://issuetracker.unity3d.com/is...stency-or-onvalidate-prevents-ui-from-showing

Perhaps script execution order could have caused it?

 

Yeah, odd, thanks for the reply, haven't found any problems with my project because of it so i'll not worry about it for now.

Edit: Well, I guess it was the script execution order because I had the ScreenSpaceScaler script execute before regular time and the warning is gone, hope this helps someone in the future.

 

Given the issues with pivot, I'm stuck, because my game is an orthographic 2D game, so while I have a 2D tilemap, I have plants and structures that "stand" on these tiles. So a 16x32px "plant" should have it's "base" in a tile. To do that, I shift the pivot. For example, grass has a pivot of 0.5x0.1.

With what we just discussed, that means there's a non-int value of 3.2 which is obviously problematic. Even after adding PixelSnap to the grass game objects they still shift as I move the camera. Using the 0.5x0.5 pivot works fine, but that renders in-world items incorrectly.

So my choice seems to be: Resize my sprites or shift my pivot so that I get a non-integer value? I really wouldn't rather not have to re-evaluate every single sprite in my game. Is there a way I can modify the math of the PPC script to "round" for me?

If not, I might try for simply 0.5x0. If I keep my sprites even dimensions that should work as well as 0.5.

 

Try changing lines 101-102 to:

relPos.x = (Mathf.Round(relPos.x / assetUPP - offset.x) + offset.x + pivotOffsetFrac.x) * assetUPP;
relPos.y = (Mathf.Round(relPos.y / assetUPP - offset.y) + offset.y + pivotOffsetFrac.y) * assetUPP;​

and lines 108-109 to:

relPos.x = (Mathf.Round(relPos.x / cameraUPP - offset.x) + offset.x + pivotOffsetFrac.x + pivotOffsetInt.x) * cameraUPP;
relPos.y = (Mathf.Round(relPos.y / cameraUPP - offset.y) + offset.y + pivotOffsetFrac.y + pivotOffsetInt.y) * cameraUPP;​

Did this help?

EDIT: this change has been incorporated to the live version PPC in the asset store

 

Not that I can tell. I added PixelSnap to two specific sprites which are 16x32px, have a pivot of 0.5, 0.1. They still "jump" as the camera moves. The jump compared to the background tiles, which don't have the PixelSnap script, are 16x16px, and have a pivot of 0.5, 0.5.

I tried adding PixelSnap to the tile sprites too (with no luck) but judging by the comments in the file it's for RetroSnap or " eliminates jittering when traslating an object under a non pixel perfect resolution", and I don't believe that applies to my tile sprites.

 

It's a good idea to use the PixelSnap script to all your sprites because it would look bad to have it affect a subset of your moving sprites. In order for it to work you have 2 options: enable retroSnap OR remove the comment from `REDUCE_JITTER` flag.

PixelSnap script was in fact created for the 2 reasons mentioned there, but it can now help with your problem as well.

I managed to reproduce your problem and my proposal indeed manages to solve it. So, this is in fact the solution. I will update the version in the asset store soon enough.

EDIT: Also, make sure that the initial position of all your sprites is multiples of 0,0625 as explained before

 

Ok, I think my mistake was understanding what had to be a multiple of 0.0625. You mentioned the initial sprite position but my problem goes away when the pivot is. For example, a pivot of 0.5/0.1 causes jittering but 0.5/0.125 does not. All of my sprite positions are whole numbers right now so I had no non-int problems to fix.

0.5 is 0.0625*8 and 0.125 is 0.0625*2 and that appears to work perfectly. I don't even need the PixelSnap script when those values are used.

Also, just a note for anyone who might read this but the forum formatting of the code changes above includes a hidden/invisible character after the second line that breaks the c# compiler. In MonoDevelop at least, hitting backspace deletes the character but doesn't move the cursor, so it's an easy fix.

 

To avoid confusing anyone reading, I did mean the position of the object. The latest update of PPC is now available and solves the issue with the pivot points without needing to adjust the pivot yourself. The readme file and the description in PixelSnap.cs script have been updated with better instructions on the 2 ways to use it.

If you really want to tweak each pivot point by yourself, you want to use multiples of [1/width, 1/height]. Pixels per unit is irrelevant. So for a texture with size [32 x 32] you need to have the pivot in multiples of 1/32 = 0,03125. In your case, 1/16 happened to work because it's a multiple of 1/32 but you were just lucky.

 

Hi,
how i can reduct pixel size? actualy pixel are to big on screen, i want the same (number 2)
how its possible?

Thank you

 

You can try increasing the target width (or height) of PPC. You may have to disable or adjust the "max width" or "max height".

 

my sprite is 32x32px and i want the same size as the picture, but when i change size its not really pixel perfect. what number and where for perfect pixel with that size please?
Thank youu

 

Please see the asset's video (tutorial) and read the instructions in detail. You could also read previous replies in order to understand what being pixel perfect means and what are the shortcomings that come with it.

Pixel perfect camera does not work the way you probably think, so I can't really give a specific answer to what you ask.

The main idea is to chose a target camera width based on how much of your world needs to fit in the view. The script will adjust the camera's width a bit so that it's pixel perfect. The size of the sprite is irrelevant.

 

i have see video its really easy and PERFECT pixel ^^
Thank you!!

 

I started using this asset recently. I found that putting PixelSnap on each sprite and not enabling the PixelPerfect camera worked best for the project I had almost completed before implementing. I am having a weird problem, though.

My game consists of many tiles. Most tiles have at least a background and a foreground in different layers. Some tiles have three or four layers like this. I have attached PixelSnap to each layer in each tile. It works great, except for two cases I have found.

On these two tiles, one of the sprites in the stackup starts moving around very slowly, leaves the original tile bounds and just slowly floats around the screen. It seems to happen even when not on camera (I can observe it in the editor window while playing in an area outside of the camera). The weird part about it is that in one of the cases, the same tile prefab is used quite frequently, but only the one instance does this. The other case, is the only instance of that tile.

If I turn off PixelSnap on the layer that is moving, it seems to look OK and the behavior stops. I will probably just proceed by doing this, but I am worried a different tile will start doing the same thing later on.

Have you seen this before? Any ideas? I have looked through the PixelSnap code some and nothing looks like it would impact a sprite under different conditions. I am guessing it is round-off error somewhere, but I still don't understand why it would just be these two very specific instances.

If it isn't clear what I'm talking about, I can send you gifs in PM if you would like.

Thanks for any help!

 

In my case pixel perfect camera works only if 'Retro Snap' is enabled and PixelSnap script is added.

Moreover, if 'Pixel Perfect' only is enabled, game sometimes may look worse comparing to the situation when no checkboxes are checked.

Example how single sprite is rendered when 'Pixel Perfect' is enabled: https://gyazo.com/c902b853d4d6fc94619f2084ce36621d
As you can see, pixels have different size and there is strange glitch at the pixel's corner.

Doesn't look like an expected behaviour.

 

@whogas What do you mean that you have not enabled pixel perfect camera? Do you have the PPC (pixel perfect camera) component disabled? For, PixelSnap script to work, the game object needs to be rendered by a camera that has PPC attached to it and RetroSnap enabled. Otherwise, PixelSnap.cs does nothing. If you have uncommented the "REDUCE_JITTER" variable, it can work without PPC. What exactly did you do? Is "pixel perfect" enabled?

Regarding the moving tile, I haven't seen this problem before. My guess is that another script is also changing the position of this tile. If you see how PixelSnap works, it temporarily adjusts the position and then restores it. Also, PixelSnap script is based on the assumption that every camera that calls OnWillRenderObject(), will call OnRenderObject() before any other camera calls any of these methods. This is to temporarily set the snapped position and then restore the original one. My guess is that these calls are not made in this order for that tile. You can enable the `Debug.Log` calls I have in these methods to see what is actually called. Let me know of your findings!

 

@vinchkovsky PPC can't cause these artifacts. It's simply adjusting the camera size.

Read the instructions on how to set-up your project for pixel-perfect rendering. My guess is that the pivot point of the sprite is messed-up or the initial position is not an integer (or multiple of 1 / Pixels Per Unit). Are you sure that all your sprites have the same pixels per unit number? Is that the one you have set on PPC?

The fact that RetroSnap helps is because it adjusts the sprite's position correctly. If the sprite had the correct place to begin with, the problem wouldn't appear. So, check your game object's position and the pivot point

 

Works quite nicely. Thanks for the script.

Just some feedback; it would be cool if you could add the option of a border. At the moment, the script looks for the "closest" size for the camera, and expands to it. Instead of expanding, it would be nice to have a border option, and instead of expanding, it maintains the specified size, and fills in the rest with a border of our choosing (e.g solid colour or an image). Sometimes expanding dynamically to whatever the screen size is can break gameplay elements (e.g the player can see things they shouldn't). So a border option can correct this.

I plan on implementing this myself, but just thought I'd give some feedback as a potential feature you could add.

Thanks again for the script.

 

Thank you for your feedback! Notice that the camera size may expand or shrink, compared to the target camera size. If you enable "max width" and set it the same value as the target width, then PPC will only shrink the camera size and never expand. Note though, that this will result in more zooming in that you may like.

Adding border could be useful, however I think that I prefer the simplicity of the current implementation which just sets the orthographic's camera size and doesn't meddle with rendering.

If you are going to implement the border, check out the paragraph before the end in the readme regarding scripts that interact with PPC.

 

Thanks for responding, and sorry it's been a few days since I could take a look at this again. I am just using the REDUCE_JITTER option on all of my tiles. I used the debug lines from the OnWill... and OnRender... methods and everything looked as it should as far as I could tell.

These two sprites should not be impacted by any other scripts or physics. They do not have rigidbodies. I have re-verified that nothing is different between the particular instance of the tile with this issue and other instances. They all look identical, but the one instance is giving me this problem.

I don't know if the fact that I have REDUCE_JITTER on will help you think of what the issue could be. I am out of ideas. Looking through the code, I don't see anything that would cause this kind of behavior. It is pretty straightforward.

I am baffled...

 

PixelSnap (with REDUCE_JITTER commented out) works only if the game object is rendered by a Camera that has a PixelPerfectCamera component AND RetroSnap is enabled. So, I don't see how a sprite could move around when not visible by such a camera.

Using, "REDUCE_JITTER" however, works with every camera. Even the one used by the scene window. So, the problem must be related to the scene camera and some interaction with PixelSnap.cs .

I'm out of ideas. Perhaps the problem is related to a prefab bug? Or that specific tile is selected in the editor? Sending a mini project that demonstrates the problem, could help!

 

I don't think I can make a standalone project and recreate this since out of hundreds of tiles, it seems to be randomly happening on a couple. Thanks for the help, though. It seems like I can just turn off PixelSnap on those particular tile layers and avoid the issue.

 

Hi Douvantzis. Thanks for this wonderful script. Right now i'm not really sure how the Pixel Perfect method works (will read and study a little bit later on ti) but please can you tell me will it achieve my goal to make my game look identical no matter of the resolution?

I'm not sure in changing the orthographic size of the camera. Will it make my game look different on other resolutions? I tried to fiddle a little bit with it and when i change my resolution in unity player it will zoom out my game

Can you pls help me or point me in the right direction on how to achieve so my game and my map bounds will look the same on different resolution with the same aspect ratio? (i will go with 4:3 aspect)

Is this right tool for that? Can i just make it so it will just zoom in, not zoom out? Max width and max height will do that for me?

What about scaling the sprites with this - https://forum.unity.com/threads/pixel-art-scaler-smoother.487351/.

 

Hi @kneza23 . By identical, you mean to have the same field of view (in other words, the same orthographic size)?

Unfortunately, you can't be pixel perfect and stick to the same camera orthographic size. This is not a limitation of PPC, but it's just how things are :/

You can set maxWidth to the same value as targetWidth. This way, PPC will only zoom in. You can render borders accordingly in order to hide the extra area of the map.

If you intend to use the scaler script you mentioned, you don't have to be pixel-perfect, since the blocky looks of the sprites is replaced by a smoother one.

 

When i say identical it means that when i put some tree in the right upper corner that it stay's there, and ect.

We are using this for top down 2d pixel art adventure game. So we have some larger areas that require scrolling of the map. But also we have some scenes that are fixed and it would be good to not have the camera scrolled on the motion of the player.

We have decided to use 4:3 ratio and use the black bars on right and left side for ultimate retro look

So thing is, when we design the scene, how do we go with the camera if we are never sure will it be zoomed in or out? I sent it to few friends who have different screens and the whole map looked really small on some of them. It breaks the look and feel of the whole map.

So what are my options and your advice? This is really cool concept that you have, but is hard to design the maps because you never know what the zoom factor will be when player plays.

If i chose to limit the size is it better to limit width or the height if we are targeting 4:3 ratios?

Sry for too many questions and thanks for the reply.

 

As I said previously, what you want can't be achieved while being pixel perfect.

Since you are targeting PC (and not mobile where you normally don't want bars), you can place black borders (on the sides) if needed, in order to maintain the same viewable map area and be pixel-perfect.

You can see how the zoom changes, by changing Unity's game window size. PPC will adapt and you'll have a rough idea how it looks in different resolutions.

So, you can do the following:
Disable pixel-perfect mode and set the orthographic camera to what you ideally want. You can target width or height. Since you have a fixed aspect ratio, it doesn't matter which one you chose. Take a note of that value. Let's call it: ideal_target_width.
Set the target width (or height, whatever you chose earlier) to ideal_target_width * 3/2. Set the same value to maximum_width. PPC will choose a size that is between ideal_target_width and ideal_target_width* 3/2.
Create a script where you read PPC's cameraSize variable to get the actual camera size. You can compare that to the ideal_target_width and draw the borders.

You can find more information about reading that value after PPC is initialized, in the readme in the "Instructions for scripts interacting with PixelPerfectCamera" section.

 

Thanks, i will try that. But why do i need to draw black borders by myself? I have just limited my unity player resolutions to 4:3 aspect ratio. So when i run the game. in Screen resoltions section will be just resolutions that are in that aspect ratio.

 

As I have already explained, PPC will adjust the camera's orthographic size and depending on the screen size more or less of the world will appear. So, by drawing black borders on top of your world, you'll hide the extra view and you'll make sure that the same part of the world is seen at all times.

For example if your ideal camera width is 0.5 and PPC sets it to 0.7, you'll have to draw a black border of 0.2 units on each side (left, right) and top - bottom.

 

Is it possible to stretch the pixels from 320x200 to 320x240 ala Mode 13h? I'd like the rectangular pixels look of Lucasarts, Doom and other games of the 90s that designed games with a 16:10 aspect ratio so each pixel is 20% taller than it is wide.

 

@Zebbi Back in the day the monitors' pixels were wider and when the assets you describes were viewed, they had the correct aspect ratio, unlike what we see now when displaying those games in current monitors without aspect-ratio correction.

Having said that, PPC does not interfere with the way camera renders. It just sets the orthographic camera's size. So, you can implement this yourself with a render texture.

 

Yeah, in aseprite it's possible to view the canvas at any pixel aspect ratio whilst drawing, so you could draw everything with rectangular pixels shown and theoretically display everything in unity the same as it was drawn. What render texture/shader would you recommend for this kind of result that would work as efficiently as PPC appears to?

 

@Douvantzis This: https://github.com/SubjectNerd-Unity/UnityPixelCamera supports:

• Aspect Stretch - Apply a stretch to the output, allows the display to be non square pixels.

Could a feature like this be added to PPC?

Also, here's a good description on the specifics: https://www.gamasutra.com/blogs/Fel...idescreen_Tips_on_correcting_aspect_ratio.php

 

@Zebbi As I have already explained, I want to keep PPC as simple as possible and not interfere with rendering.