[Translated from Korean]
Hello!
This is Team OOPArts, currently developing Frostory.
This time, we’d like to discuss the considerations we had about pixel-perfect rendering in the early stages of development.
At the beginning of development, we didn’t pay much attention to pixel-perfect rendering.
(In fact, we didn’t even know the term "pixel-perfect" back then.)
However, as development progressed, we came across the concept of pixel-perfect rendering.
We found that various approaches were used in different games.
Perfect Pixel-Perfect Rendering
When Pixel Snap is not applied (slight misalignment between background and character)
Allowing pixel rotation and scaling
Each approach has its own advantages and disadvantages.
The first method offers the best presentation when stationary and has a strong retro feel.
However, when forced to render rotating objects in pixel-perfect units, the pixels looked broken, which felt uncomfortable.
(There’s a glitch in the character rendering in the image on the right, but please focus on the fruit instead.)
Depending on the art style and preference, one may choose differently, but we concluded that the left method was better for our game.
There were various ways to apply pixel snap, each with its own characteristics.
1. Pixel Snapping at the Rendering Stage
(Rendering at a small texture size and then scaling, or rounding all sprite coordinates to the nearest pixel)
- Perfect pixel-perfect rendering, but camera movement is also pixel-locked
- Objects moving slowly may look awkward
- Suitable for retro-style or fixed-resolution games
2. Objects Already Snapped
(All object coordinates are pixel-locked)
- Allows the camera to move smoothly in screen pixel units
- Difficult to implement physics
3. No Snapping
- Smooth movement for both camera and objects
- Potential for glitching between objects at pixel level
- Stationary objects may appear to shift by one pixel as the camera moves (Look closely at the left tree)
After considering the pros and cons, we decided not to apply pixel snapping.
The calculations for movement in pixel units are complex, and the smooth motion felt acceptable.
After making this decision, we realized that stationary objects have no physical movement, so we snapped only stationary objects to the background pixel position to fix issues like the left tree.
Although we made some decisions, there were still issues.
When learning about pixel-perfect rendering, we referenced Enter the Gungeon extensively.
The main focus was the display options, which offered a Scaling Mode for players to choose their preferred graphics.
The reason for these options is likely that people use monitors of various sizes, making full-screen pixel-perfect rendering impossible at all times.
By comparing pros and cons, they allowed users to make a choice.
These options can be categorized as follows:
1. When the monitor has an integer-multiple resolution of Enter the Gungeon's art pixels (480x270), like 1920x1080, 1440x810, etc.
Setting it to the monitor resolution works perfectly.
2. When it’s not the case
- If pixel-perfect is desired, adjust the output range to make it pixel-perfect (this will add letterboxing).
- If you want a full-screen view, scale the game scene and choose whether to apply anti-aliasing.
Understanding why these options are provided requires knowing the following concepts.
[Game Scene]
The game scene you want to display. In the case of Enter the Gungeon, it’s 480x270, while for our game, it’s set at 320x180.
(Currently, it has been changed to 427x240)
The technique of scaling this beautifully is crucial.
[PPU]
Sprites ultimately exist within the game world.
PPU, or Pixels Per Unit, determines the size of one sprite pixel in the world.
Unity’s default is 100 PPU, meaning 100 pixels equal a length of 1 unit.
This value varies depending on the game’s requirements.
We use 36 PPU to set one tile with a width of 18 pixels as 0.5 in size.
[Camera Orthogonal Size]
The orthogonal size is the height of the world captured by the camera in the y-axis.
The camera automatically adjusts its x-axis according to the screen ratio.
You need to calculate this orthogonal size correctly to fit the world precisely.
To fit by y-axis, orthogonal size = H / PPU, and to fit by x-axis, orthogonal size = W / PPU * screenHeight / screenWidth, where W is the game scene’s width and H is its height.
What if you want the game scene to be displayed proportionally regardless of screen size?
In this case, you can add letterboxing by adjusting the camera's rect value.
The camera’s two corners min and max default to (0,0) and (1,1).
For example, if the screen ratio is 4:3 and the game scene ratio is 16:9, you can set it to (0, 0.125) and (1, 0.875) for a perfect fit.
[Camera Back Buffer]
The camera renders the world onto a render texture known as the Back Buffer (framebuffer).
Therefore, if the Back Buffer size matches the game scene size, pixel-perfect rendering is achieved (putting other issues aside for now).
What if the Back Buffer size is twice the game scene size?
Even in this case, pixel-perfect rendering is achieved. (See image)
What if the size is 1.5 times?
The pixels will appear distorted.
This happens because each pixel can only store one color.
As a result, during scaling by the rasterizer, pixels may seem to jump irregularly.
(Mathematically, the pixels are scaled according to a formula, but complex pixel art often appears distorted.)
To understand this intuitively, you can recreate similar situations with a graphics program.
The image distorts until it scales perfectly to twice the size.
In summary, the Back Buffer size should be an integer multiple of the game scene size.
In Unity, you can set the size using the Screen.SetResolution function.
[Screen Pixels]
The pixel information in the Back Buffer is displayed through the monitor.
Monitors are made up of pixels at their native resolution (1920x1080, 2560x1440, etc.).
If you want a perfectly clear pixel art look, this also needs to be an integer multiple. However, as everyone uses monitors with different resolutions, there are various practical issues.
It seems better to scale and apply anti-aliasing when the Back Buffer doesn’t have an integer multiple on the screen.
In general, monitor resolutions are much higher than the game scene size, so even with anti-aliasing, the pixel art look can be preserved.
In this case, even without anti-aliasing, the visuals aren’t heavily affected, so it seems to be a matter of choice.
In the left example above, you can see where the screen pixels misalign.
It generally looks fine, but if you look closely at the diagonal lines, the pixel sizes become irregular.
Ultimately, we designed our UI with these considerations in mind.
Unexpectedly, we encountered an unusual issue.
Please look at the image below.
The character’s brow width narrows and widens!
We discovered that this mysterious issue occurs along the diagonal lines splitting the sprite mesh, but unfortunately, we haven’t found a fundamental solution yet.
Coincidentally, we saw similar issues in pixel art games using other engines, suggesting that it may be an unavoidable problem specific to pixel art games that don’t use anti-aliasing, independent of the engine.
We believe this phenomenon is related to floating-point calculation errors. We tried slightly adjusting the camera position relative to the character to reduce these errors, which helped to prevent the main character’s brow from widening, though it wasn’t a complete fix.
(If anyone knows, please let us know!)
We ended this development log with a lingering issue, but this is the conclusion for now.
Thank you for reading!