mirror of
https://github.com/Relintai/pandemonium_demo_projects.git
synced 2024-12-21 13:56:50 +01:00
95 lines
4.6 KiB
Markdown
95 lines
4.6 KiB
Markdown
|
# Multiple Resolutions and Aspect Ratios
|
|||
|
|
|
|||
|
|
**Note:** This demo is intended to showcase what Godot can do in terms of
|
|||
|
|
supporting multiple resolutions and aspect ratios. As such, this demo very
|
|||
|
|
full-featured but it's also fairly complex to understand.
|
|||
|
|
|
|||
|
|
If you're in a hurry and want to implement *decent* support for multiple
|
|||
|
|
resolutions and aspect ratios in your game, see [Multiple resolutions crash
|
|||
|
|
course](#multiple-resolutions-crash-course).
|
|||
|
|
|
|||
|
|
___
|
|||
|
|
|
|||
|
|
This project demonstrates how to set up a project to handle screens of multiple
|
|||
|
|
resolutions and aspect ratios.
|
|||
|
|
|
|||
|
|
This demo allows you to adjust the window's base resolution, stretch mode,
|
|||
|
|
stretch aspect, and scale factor (internally known as "stretch shrink"). This
|
|||
|
|
lets you see what happens when adjusting those properties. Make sure to resize
|
|||
|
|
the project window in any direction to see the difference with the various
|
|||
|
|
stretch mode and stretch aspect settings.
|
|||
|
|
|
|||
|
|
The GUI can be made to fit the window or constrained to a specific aspect ratio
|
|||
|
|
from a list of common aspect ratios. On ultrawide aspect ratios, this can be
|
|||
|
|
used to prevent HUD elements from being too spread apart, which can harm the
|
|||
|
|
gameplay experience. For non-essential HUD elements, specific controls can be
|
|||
|
|
made to ignore this aspect ratio constraint when it makes sense (e.g. a list of
|
|||
|
|
players on the side of the screen).
|
|||
|
|
|
|||
|
|
Additionally, a GUI margin setting is provided to better handle TVs with an
|
|||
|
|
overscan area to prevent GUI elements from being cut off. This can also improve
|
|||
|
|
the gameplay experience on large monitors by bringing HUD elements closer to the
|
|||
|
|
center of the screen.
|
|||
|
|
|
|||
|
|
A DynamicFont is also used to ensure font rendering remains crisp at high
|
|||
|
|
resolutions, thanks to Godot's built-in support for font oversampling. In other
|
|||
|
|
words, the engine will automatically re-rasterize fonts at different resolutions
|
|||
|
|
than the base window size when the window is resized (or when the window scale
|
|||
|
|
factor is changed).
|
|||
|
|
|
|||
|
|
Language: GDScript
|
|||
|
|
|
|||
|
|
Renderer: GLES 2
|
|||
|
|
|
|||
|
|
## Technical notes
|
|||
|
|
|
|||
|
|
The demo works with the following project settings:
|
|||
|
|
|
|||
|
|
- `2d` stretch mode (recommended for most non-pixel art games).
|
|||
|
|
- `expand` stretch aspect (allows support for multiple aspect ratios without
|
|||
|
|
distortion or black bars).
|
|||
|
|
- Using a base window size with a 1:1 aspect ratio (`648×648` in this demo).
|
|||
|
|
This prevents GUI elements from automatically shrinking, even in portrait
|
|||
|
|
mode.
|
|||
|
|
- With this setting, to prevent the GUI from breaking at narrow aspect ratios,
|
|||
|
|
the GUI must be designed to work with a 1:1 aspect ratio. This is not
|
|||
|
|
feasible in most complex games, so a base window size with a wider aspect
|
|||
|
|
ratio (such as 4:3 or 16:10) can be used instead. The wider the aspect
|
|||
|
|
ratio, the easier design becomes, but the GUI will automatically become
|
|||
|
|
smaller at narrow aspect ratios unless the user overrides its scale with the
|
|||
|
|
stretch shrink setting. Many devices such as the Steam Deck and MacBooks
|
|||
|
|
feature 16:10 displays, so it's recommended to use a 16:10 resolution or
|
|||
|
|
narrower as a base window size to ensure a good gameplay experience out of
|
|||
|
|
the box on those devices.
|
|||
|
|
- Using a test window size with a 16:9 aspect ratio (`1152×648` in this demo).
|
|||
|
|
This way, the project starts in a 16:9 window even if the base window size has
|
|||
|
|
a 1:1 aspect ratio.
|
|||
|
|
- The test window height matches the width and height of the base window size,
|
|||
|
|
so GUI elements are still at the same size.
|
|||
|
|
|
|||
|
|
## Multiple resolutions crash course
|
|||
|
|
|
|||
|
|
**Not everything in this demo is critical to all games.** For gamejam projects or mobile games, most of this can be skipped.
|
|||
|
|
See the [Common use case scenarios](https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#common-use-case-scenarios)
|
|||
|
|
section in the Multiple resolutions documentation.
|
|||
|
|
|
|||
|
|
With the simpler setup described in the above documentation, there are a few
|
|||
|
|
limitations compared to this demo:
|
|||
|
|
|
|||
|
|
- The HUD will shrink when the aspect ratio becomes narrower than the base
|
|||
|
|
window size. As such, it's recommended to use a base window size with a 16:10
|
|||
|
|
aspect ratio to prevent the HUD from shrinking on Steam Deck and MacBooks.
|
|||
|
|
- Players will not be able to define a margin, which can be problematic when
|
|||
|
|
playing on a TV (as overscan can obstruct some HUD elements). This can be
|
|||
|
|
worked around by ensuring the entire HUD always has a small margin around it.
|
|||
|
|
This can be done by increasing the Margin properties on all sides on the root
|
|||
|
|
Control node by 10-30 pixels or so.
|
|||
|
|
|
|||
|
|
If you're releasing a full-fledged game on a desktop platform such as Steam,
|
|||
|
|
consider implementing full support as this demo suggests. Your players will
|
|||
|
|
thank you :slightly_smiling_face:
|
|||
|
|
|
|||
|
|
## Screenshots
|
|||
|
|
|
|||
|
|
|