Hello!

I know that working with absolute positions and sizes on sprites and collision-boxes is not a good idea if one wants to support multiple resolutions.

But what ways are being used to actually scale properly?

What I know is working in percentages (and offsets). One would define a vector of x and y (both between 0 and 1) and an offset vector of x and y of arbitrary pixel size. Now multiply with the screen-size and add the offset and get the scaled absolute size. This would work for size as well, but probably without the offset.

So if an object is outside of the window, its relative coordinates would be higher than 1?

I assumed updating absolute coordinates is done once when the resolution has been altered and every sprite owns two attributes: relative and updated absolute coordinates. But then again sprites can move thus change their relational coordinates; it's probably easier to do the calculation every draw-call or maybe keep a "has sprite changed its size/position"-flag/bool.

And I also assume that physics are calculated the same? Since the transformation is 1:1, every mouse click can be transformed into relational coordinates and then do the usual collision maths. Same goes for sprites, I would calculate movement in relational coordinates and with relational sizes and then alter the relational coordinates.

There is one issue on my mind, since all these values are meant to move in floating numbers (e.g. between 0 and 1 for everything inside the resolution/visible canvas), isn't there a float-point accuracy issue with different hardware? Especially if savegames are usable on other multiple devices, e.g. from desktop to smartphone.

On a final note, are there any other alternative systems for scaling sprites according to a resolution?

Thanks for your time.

By artefacts you mean artefacts caused by up- or downscaling?

What I understand: Draw to a render-target or something as a view, this could be 1920x180 big.

Then scale this to the actual window-size, e.g. down to 1280x720.

The question that remains for me: How do I handle different aspect-ratios? If I do not care about what is actually seen on the screen, I can simply show more or less and have 1920x1200 as virtual size?

I always thought relational coordinates and sizes are the way to go, so this is a bit new to me, but interesting : )

19 hours ago, Angelic Ice said:

What I know is working in percentages (and offsets).

All forms I have ever encountered is just a alteration of the percentage formula. The most common is the setting the zero to the camera corner and the other common one is using a axis.

So zero point at corner is the one you are describing:

The other is the axis or grid way:

Here we see 800 * 600 (4:3) and 1600 * 900 (16:9) ratio.

What is important to note is that this is used often in world space and camera space. Often the Percentage method is used for camera space and the axis for world space; this keeps things neat and separate. However this isn't some predefined rule, you are free to use what you want.

21 hours ago, Angelic Ice said:

So if an object is outside of the window, its relative coordinates would be higher than 1?

Yes, if it's (2,2) and on a 800* 600 screen then (800 * 2, 600 * 2) = (1600,1200).

21 hours ago, Angelic Ice said:

and every sprite owns two attributes:

No, because as shown in the above image we can just calculate the position using the resolution and position. No need to give every object an attribute when the screen position is dependant on the underline position.

Note that all ratios are design to make this easy: https://en.wikipedia.org/wiki/Aspect_ratio_(image)

The rule of thumb is design your math and physics from 1X upwards and art downwards. Math: 1 * Min Resolution.  || Art: 1 * Max Resolution.

15 hours ago, mr_tawan said:

I'm not a big fan of scaling every sprite on the screen, as it can lead to artifacts if you're not careful enough. Every sprite will need 1- pixel guard around it

Personally I use a 4 pixel margin.

There is no way to prevent scaling errors but there are ways to improve the scaling. One way is to keep things pixel perfect but this requires manipulating the camera based on the device.

My prefered way is using Mips to blend details from higher and lower images, also known as Trilinear filtering.

Thanks! So there seem to be two ways, either one works with absolute pixels and a preset window-size and transforms the view to window-size or one works with a very basic coordinate system of values between 0 and 1 and draws accordingly based on window-size.

The reason I mentioned two attributes was to prevent re-calculating by caching the result until it's outdated (sprite moved, screen resized, ...). Since doing 0.5 * 1280, 0.25 * 720, every time seems unnecessary.

Now, what I do not understand, what do you mean by artefacts?

11 minutes ago, Scouting Ninja said:

Personally I use a 4 pixel margin.

What does this mean? What are artefacts? I know that when I scale images, pixels can jump around into ugly places, is that what this means? Especially if nearest neighbour scales from 100% size to 120% instead of the next full option: 200%.

But what is a margin in this case?

16 hours ago, Angelic Ice said:

The reason I mentioned two attributes was to prevent re-calculating by caching the result until it's outdated (sprite moved, screen resized, ...). Since doing 0.5 * 1280, 0.25 * 720, every time seems unnecessary.

Most games solve this by scaling the game. While playing games you might have encountered this yourself, with the game asking for a restart after the resolution is changed. When the game starts it scales to match the required resolution and there is no longer a need to multiply the values.

The way you are describing here could maybe be used in a multiplayer game where the server runs a 1:1 version while players use a ?:? version. Even so it's often only the visuals that scale not the math, so there isn't that much of a need for tracking it.

I want to point out that most modern engines take care of this. So if you are using Unity, Unreal or any other popular engine then this isn't something to concern yourself with.

@mr_tawan describes the artifacts perfectly. It's known as pixel bleeding and is very easy to avoid by just adding a little boarder to the sprite.

The reason I use 4 pixels instead of 1 is because I like using performance focused algorithms. The tradeoff for many of these it that they take much larger samples (so there are fewer samples to take in total) that often result in a larger pixel bleed.

Hm, but wouldn't artefacts occur over the entire sprite-structure anyway? I'm not sure if I understand this issue well enough. Not all sprites are fully filled to the very corner (out of 64x64 pixels, 64x64 are filled) and own a mix of transparency/isometric/dimetric/.. and do not fill the entire sprite-image assigned to them inside the sheet. Thus I do not really understand how adding a "border" would fix this? The bleeding would occur way before the border of the sprite is arrived.

1 hour ago, Scouting Ninja said:

Most games solve this by scaling the game. While playing games you might have encountered this yourself, with the game asking for a restart after the resolution is changed. When the game starts it scales to match the required resolution and there is no longer a need to multiply the values.

Sorry but I still cannot imagine the process.. So, when I have a 64x64 sprite that I load 10 times onto the screen, next to another, I would at least require a width of 640. I decide that this looks good and shall be what every player (with the same aspect ratio) sees and pick 1280x720 as my default resolution.

Now a user with a native resolution of 1920x1080 starts the game - the game starts in 1280x720. The user changes this in the settings. If I draw to a render target, I can simply upsample this to 1920x1080 - there would be no restart required here or would it be? I can reproduce this with a view-element from SFML, rescaling the view does not require a restart, it's a pretty dynamic process.

So the restart would be required if I work in percentages? Deserialise whatever level, and directly save every percentage as absolute coordinates on a sprite's usual way to attribute its position and size?

On another note, I assume physics would work in percentages too and also converted to absolutes?

Thanks for you two's patience with me<3