Increase your camera size to that value, and boom, we're back to a nice neat integer pixel-to-texel ratio, without changing any of our texture assets or gameplay scripts. Running the math with these numbers, we get a camera size of 5.333333. Rearranging: camera size = 1440 display pixels of screen height / (5 pixels per texel * 2 * 27 PPU) 5.3333 is pretty close to 5, so let's see what happens when we adjust our camera cropping to make our pixel-to-texel ratio that nice integer: 5 pixels per texel = 1440 display pixels of screen height / (camera size * 2 * 27 PPU) Now if we display on a 2560 x 1440 monitor without changing anything, our formerly 148-pixel-tall character is now drawn 197.333 pixels tall, a 5.33333 pixel-to-texel ratio, and that trailing decimal is going to cause unsightly distortions.īut we don't want to change the logical size of all our game content by changing the PPU - then we have to re-calibrate all the distances, velocities, and forces used in our gameplay scripts, so it would be a terrible mess.
Okay, now let's lock-in that PPU, and use it for all our assets, so everything has the same degree of "chunkiness" to its pixels for stylistic consistency, at a constant 4x display-pixel-to-source-texel ratio, a nice integer that helps us avoid rounding artifacts. To draw the character at a 4x scale, 140x148 pixels, then it needs to be 1.370370. As you worked out, that means each unit of world space maps to 108 display pixels. Let's start with your 1920 x 1080 example with camera size 5, and call that our baseline. To adapt to different display sizes, the main thing you want to change is your camera. If you later go and make an "HD" version of your game with 64圆4 tiles, you can replace the assets with PPU 64 versions, and none of your gameplay logic has to change, because the logical coordinate system is still the same: 1 unit = 1 tile. Then it's easy to write say a dash move that travels 3 tiles: it moves 3 units in world space. It's the conversion factor between the texture resolution and the coordinate space of your gameplay logic.įor example, if you're making a tile-based game with 32x32 tiles, a PPU of 32 would make good sense. Generally you want to keep your Pixels per Unit setting constant for a set of assets you use together. Is there some concept I am not properly grasping about Units and Pixels? Since this setting is not automatic, and cannot be changed on runtime (I think), does this mean that I have to duplicate the same sprite and set every file with different PPU, depending on all the resolutions I want to support, and then in runtime select the appropiate sprite? Because that doesn't seem right. So in this case set the "Pixels per unit" to 108.īut then, if I want to allow to have different resolutions in my game, say 1440p, this means that the "Pixels per unit" for my sprite must be 144, instead of 108. Which means that I have to manually the calculation between the resolution of my display and the size of my camera. There is a field calles "pixels per unit". To do this, I would like to upscale it 4 times, meaning that instead of 35x37, I want to draw 140x148 pixels, right?īut if I go to the settings of my sprite, I find the following settings: Since I want my game to be a pixel art, I want the pixels to be more prominent. Now, I have my sprite, a 35x37 pixels image. On the other hand, if I set the resolution of "Display 1" to 2560x1440, this would mean that every unit would draw 144 pixels, right? If the height of the screen in pixels is 1080, and there are 10 units, this would mean that every unity will be 108 pixels, right? This means too that the total height of the camera are 10 units.Īt the same time we have a "Display 1" set to 1920x1080. This means that there are 5 units from the center of the camera to either the top or bottom border. I don't get how units and pixels work in Unity.