Can anyone please help me, for a 2d tileset game what are the recommendations for displaying the game display screen on different resolutions?
Curiously,
Joshuae
Displaying A Game's Graphics Using Different Resolutions
There are several. I'll list enough that you can know what to find in web searches.
One is to pick certain aspect ratios and then scale down. 4:3, 16:9, 16:10, whatever ratios are common on your platforms. If the screen doesn't match, pick the nearest. Scale your artwork to fit that form factor, usually scaling down. If you have lots of money, pick multiple resolutions at the aspect ratio and choose the nearest.
Another option is to display things relative to positions. UI may not be based on exact screen positions, but relative coordinates much like HTML elements are often specified. One box 10% from the bottom and 5% from the left, then another adjacent to the right, then another adjacent to the right of that. Another box 0% from the top and 0% from the right, then another adjacent to the right and one adjacent below.
Combine the two and you've got enough to cover most UI situations.
For gameplay, it depends on the game. Some games the amount of world you can view will impact the game, others it may not.
You might decide the game works well by allowing all visible space. A person who has an expensive 8K or 4K monitor will be able to see far more than someone with a 1024x768 monitor. This works well for 3D games where it is only model LOD that needs to be swapped out and the system can handle the workload.
Another option is to limit the space so it is equal on all devices; this may be accomplished with black bars on the top and bottom of the screen, or decorative frames around the viewing area, or other means. No matter the resolution everyone gets a gameplay area capable of viewing exactly the same size view of the world, although at different pixel densities and possibly with different graphical images.
And like always, there are options in between.
This is a dilemma I've thought way too much about, and the problem is that there is no defined right or wrong.
I'm pretty sure that 16:9 is the most common aspect ratio nowadays, so that is what I would recommend to design your game for. Also, for the game I'm currently working on, we decided to make the sprites for 4k (3840 × 2160) resolution because it might become more popular in the coming years, and downscaling usually looks better than upscaling. But if you're doing retro-style graphics, I guess it would be kinda the reversed.
Aside from black bars/frames and letting the player see a different portion of the world depending on resolution, there is also the option of stretching the image to fit the screen. If you decide to fit the game to a specific resolution, you could even let the player choose if they want black bars or stretched images in the options (would probably default to black bars).
In most cases you won't have to worry too much as most players will probably be playing on a 16:9 display and it's totally fine to assume that imo, but making the decision of ensuring that all players see the same portion or not is obvously important as it can affect gameplay (depending on the type of game).
I'm pretty sure that 16:9 is the most common aspect ratio nowadays
Some people still have only one display??
I'm pretty sure that 16:9 is the most common aspect ratio nowadaysSome people still have only one display??
Many people have multiple displays, but isn't it pretty uncommon to play 2D games on more than one display? At least I haven't seen that much, but maybe I'm a bit behind.
EDIT: Having support for multiple displays is great if you go with the option of extending the field of view depending on resolution, but otherwise I don't see a point adjusting to multiple displays. Except for an in-game option to set which display to show the game on of course.
device independent graphics and supporting all resolutions is the best way to go.
you code to something like a virtual 10Kx10K coord system. these get translated to the current rez.
I found a really simple and working solution for that - making it full resolution independent:
- Define a non-pixel game width game units (meters) for the full physical monitor width you are creating your game on - can be as simple as 10 meters
- Define a aspect ratio you want to design your game (16/9, 4/3, whatever)
- Calculate the game height: Game Width / Game Aspect Ratio
- Design your game based on that given game dimensions and do not work in pixels in any way - just use your game units always
- Calculate for each frame or when the window size changes a factor for converting game units into screen coordinates: Window width in screen space / Game Width in meters
- When you render you pass that factor as a scale to your transformation matrix or
- Calculate the pixel position yourself (Projecting): game coord * scale factor + screen offset (Screen offset is needed only when the screen coordinates are not cartesian based - mostly starting on top left)
- Sometimes you need the opposite (Unprojecting: Mouse pixels to game units): (screen coord - screenoffset) / scale factor
- Lastly you want the game to be letter boxed to the screen dimension:
Vec2i *viewportSize = &renderState->viewportSize;
Vec2i *viewportOffset = &renderState->viewportOffset;
renderState->renderScale = (F32)renderState->screenSize.w / renderState->gameSize.w;
renderState->viewportOffset = V2i();
viewportSize->w = renderState->screenSize.w;
viewportSize->h = (U32)(renderState->screenSize.w / renderState->aspectRatio);
if (viewportSize->h > renderState->screenSize.h) {
viewportSize->h = renderState->screenSize.h;
viewportSize->w = (U32)(viewportSize->h * renderState->aspectRatio);
renderState->renderScale = (F32)viewportSize->w / renderState->gameSize.w;
}
renderState->viewportOffset.x = (renderState->screenSize.w - viewportSize->w) / 2;
renderState->viewportOffset.y = (renderState->screenSize.h - viewportSize->h) / 2;
- Design your game based on that given game dimensions and do not work in pixels in any way - just use your game units always
I agree that you should keep pixels out of almost all of your code and use another unit, like meters. But to be able to upscale/downscale the images correctly when rendering, you still need to tell the game somewhere which width and height the images were made for, right? Say if a sprite is supposed to cover a meter, then you would need to have a constant or something somewhere in the code that holds how many source pixels a meter is. But for positioning, collision detection and all other game logic, you don't need to know anything about what resolution the images were designed for, you only need to know that when rendering.
- Design your game based on that given game dimensions and do not work in pixels in any way - just use your game units always
I agree that you should keep pixels out of almost all of your code and use another unit, like meters. But to be able to upscale/downscale the images correctly when rendering, you still need to tell the game somewhere which width and height the images were made for, right? Say if a sprite is supposed to cover a meter, then you would need to have a constant or something somewhere in the code that holds how many source pixels a meter is. But for positioning, collision detection and all other game logic, you don't need to know anything about what resolution the images were designed for, you only need to know that when rendering.
I agree, i would solve that by converting my current screen width into a clamped percentage based on my target min/max screen width.
Each sprite may have a way to get a percentage as well, so you can compare that two by a threshold constant.
With that technique you can have as many upscaled/downscaled sprites as you want - just need to fiddle with the threshold.
Also a sprite may have different threshold constants, so you have much more control.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
