PIXEL PERFECT 2D
来源:互联网 发布:阈值分割算法 编辑:程序博客网 时间:2024/06/08 16:47
JUNE 19, 2015 IN TECNOLOGIA
How do I make a pixel art game that looks great? We get that question a lot. If you start your pixel game with all the default settings in Unity, it will look terrible! But the current version of Unity can be made to render pixelated games that don’t suck. Read on for a rundown of do’s and dont’s.
Image on the left is rendered on a poorly calibrated camera while the one on the right is properly calibrated. (click on image to see full-res)
The Secret Sauce
The secret to making your pixelated game look nice is to ensure that your sprite is rendered on a nice pixel boundary. In other words, ensure that each pixel of your sprite is rendered on one screen pixel (or any other round number). The trick to achieving this result is tweaking the camera’s orthographic size (and live with the consequences).
The Basics: What Is Orthographic Size?
On an orthographic camera, the orthographic size dictates how many units in world space the screen’s height is divided into. So on a screen height of 1080 with orthographic size of 5, each world space unit will take up 108 pixels (1080 / (5*2)). It’s 5 * 2 because orthographic size specifies the size going from the center of the screen to the top.
Therefore if your Sprite’s Pixels Per Unit (PPU) settings is 108, it will be rendered nicely.
Practical Approach To Achieving Pixel Perfect.
To apply this on an actual project requires a bit more considerations and planning ahead. Since you can’t tweak the physical resolution of the target device and you only have a very limited range of PPU (by way of asset bundle variant), the only real number that you can play with is the orthographic size.
Changing the orthographic size will have the effect of increasing or decreasing the visible world space. This impacts your game code directly and need to be accounted for. Here’s a table with various scaling scenarios
Vertical ResolutionPPUPPU ScaleOrthographics SizeSize Change768321x12100%1080321x16.875140%1080481x11.2593.75%1080322x8.437570.31%1440322x11.2593.75%1536322x12100%* Orthographic size = ((Vert Resolution)/(PPUScale * PPU)) * 0.5
There are three well known techniques to handle the scaling and it is quite plausible that you will employ all three in your project.
Technique #1: Thick Borders
For a small difference, a simple ‘thick border’ will suffice. Depending on your game’s design, a few percentage bigger or smaller than your reference screen size can be easily filled with the thick border.The overall screen size grows but the art size stays the same. This can be easily dealt with by increasing the thickness of the floor/roof.
However, when the screen increases beyond a certain size, a thick border will no longer be practical.
Technique #2: Increase Asset Resolution
If you start out with a reference screen height of 768 and PPU of 32, going to 1080 is going to be troublesome as your assets will not scale nicely.
The table above illustrates scaling a game starting from 768 all to way to 1536 with three alternatives on how to deal with 1080. The most interesting number to look at is the orthographic size. The ideal situation is that as your screen size grows, the orthographic size remains the same. This will ensure that your assets will take up the same amount of screen space as they do with your reference resolution.
From the table above, using an alternate sprite at PPU 48 would create a visible world space that’s only 6.25% smaller than your reference size. This could be easily dealt with using the thick border approach.
PPU 32 vs PPU 48 at 1080 with ortho size 11.25. Notice the terrible looking PPU 32 sprites on the left. Color shifted on the right to clearly show swapped asset variants.
Swapping the sprite assets can be easily done at runtime using AssetBundle Variants. See a demo here.
Technique #3: Halving Orthographic Size
If your screen grows big enough, we could display your sprites at 2x by applying a scaling factor to the calculation of the orthographic size. For the case of 1440, we could keep using the PPU 32 sprites but calculate the orthographic size as such (1440/(2*32)) * 0.5 which gives you 11.25.
This means, each world space units will contain 64 screen pixels. This effectively tells the engine to render 32 pixels from the sprite onto 64 pixels on screen. This gives a nice whole number factor of 2 which will look good at the same time giving you a world space that’s just 6.25% smaller than your reference setup.
This technique does not require new assets to be created.
* The PPU 32 sprites are now rendered twice as big but still look fantastic. This only works for whole number enlargement.
Other Tweaks
These other settings are essential to make things as crisp as possible.
On the sprite:
- Ensure your sprites are using lossless compression e.g. True Color
- 1. Turn off mipmapping
- 2. Use Point sampling
In Render Quality Settings:
1. Turn off anisotropic filtering2. Turn off anti aliasing
(Optional) Turn on pixel snapping in the sprite shader by creating a custom material that uses the Sprite/Default shader and attaching it to the SpriteRenderer.
Implementation Details
To implement the above system requires 2 parts.
- Create a simple component that calculates the orthographic size for the camera based on the screen height.
- Allow for overrides for certain resolutions so that the user could dictate the PPU settings for that resolution
- This calculation takes place at the start of the scene
- Load the right asset bundle variant based on the screen height. Either load the default bundle or one that’s based on the override settings.
PixelPerfect component
Check out a demo project that demonstrates this approach
Known Issues
Even with all these number tweaking, there are still a few issues:
- Physics and animation systems might move/rotate your object to a position or rotation that’s not ideal.
- Single-pixel width art assets will render poorly if they are allowed to be rotated arbitrarily. This is true no matter what you do. The only real solution to this is to either:
Avoid single pixel art
Always ensure they are axis aligned
Conclusion
Making pixel perfect 2D games is possible with the current version of Unity. However, as detailed above, there are consequences and known issues, but they are not insurmountable nor are they blockers. Long live retro style games!
- PIXEL PERFECT 2D
- Pixel perfect 2d in 4.3?
- Android Performance(6) Pixel Perfect
- Pixel Perfect Collision Detection (Using Cocos2d-x)
- Pixel-Perfect UI in the WebView
- D(1909)Perfect Chocolate
- Molehill Pixel Bender 3D 已发布!
- Adobe Pixel Bender 3D 例子
- Swift & Perfect 初步搭建d
- pixel
- Pixel
- Per Pixel Lighting [Part 2]
- Google Pixel 2 相机测试
- "Perfect"
- 4:2:0 Video Pixel Formats
- -webkit-min-device-pixel-ratio: 2是什么意思?
- PGM——D-map、I-map、perfect-map
- 谷歌 Pixel 2 及 Pixel XL 2 参数曝光,预计最早9月面市
- linux网络编程之-----多播(组播)编程
- 多进程 fork之后父子进程 对文件描述符的作用
- JVM学习02-GC算法与种类
- Linux之广播和多播
- 8086键盘输入实验——《x86汇编语言:从实模式到保护模式》读书笔记07
- PIXEL PERFECT 2D
- 成员的访问控制
- 基于Linux的多播编程
- 项目管理之道--庆我的新书出版并预祝大卖!
- 理论: 图论(11): 二分图的最大权匹配(KM算法)HDU 2255
- linux 多播
- reinterpret_cast本质
- Linux 高级Socket编程
- OkHttp的使用简介及封装,实现更简洁的调用