Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

Gameplay Sprite sizes and positions on different resolutions

Recommended Posts

3 hours ago, Angelic Ice said:

Hm, but wouldn't artefacts occur over the entire sprite-structure anyway? I'm not sure if I understand this issue well enough.

You want it to happen over the whole sprite. It's by sampling the pixels that a new sprite is made. 4 or more pixels sampled and a 1 pixel made from this data.

I realize it's something you have to see, so I found this Unity topic: https://answers.unity.com/questions/939077/sliced-textures-bleed-into-eachother.html

43790-unity-help2.png.a98f0f12dfb601d30e48136984b7c3de.png

If you zoom in you can see where the sprites are bleeding into each other.

3 hours ago, Angelic Ice said:

Not all sprites are fully filled to the very corner

It's actually more noticeable with sprites that don't fill every corner and ones that use alpha channels. Imagine a walking character where the hand from the next sprite bleeds into the new sprite. What you get is this line that floats in front of the character.

The more the object is scaled the worse it gets.

3 hours ago, Angelic Ice said:

Thus I do not really understand how adding a "border" would fix this?

In the case of a alpha image we use a alpha border so that there is no color to sample from, so it doesn't mix with a color. A full sprite we use the last pixel and "stretch" it.

Google: "sprites edge padding" Also look into "Sprite bleeding problems".

 

3 hours ago, Angelic Ice said:

Sorry but I still cannot imagine the process.. So, when I have a 64x64 sprite that I load 10 times onto the screen

There is so much misunderstandings, sorry it's my fault I should have made something clear from the start.: Art has nothing to do with the game.:)

If my collision box is: 10 by 10 units long, it tells me nothing of how many pixels that is going to be. If I change a 64*64 sprite with a 120*10 sprite it will not affect collisions or gameplay at all. Rendering and gameplay are separate from each other.

So the thing you are describing here with the 64*64 sprite being used 10 times isn't how we calculate space. You aren't doing anything wrong but it is a weird way of thinking about the object.

The above post is where I explain Unity's coordinates. Unity uses the axis/grid way as I explained above.

 

I feel like there is gaps when I am trying to explain things. Maybe if you tell me what it is you want to do I can focus on explaining only what you need to know.

Share this post


Link to post
Share on other sites
Advertisement
5 hours ago, Scouting Ninja said:

There is so much misunderstandings, sorry it's my fault I should have made something clear from the start.: Art has nothing to do with the game.:)

This is what I wanted to learn about in this thread. I know that art should be seperated from physics, but I was not sure how I would make art independent from resolution and then physics transformable into graphics.

So borders are literally bonus pixels that are used so that sampling methods do not blend over with nearby colours. I think the rotating cube image did explain it fairly well: border-artifacts.png

So what I see is that Unity is using abstract units. Their meaning is given by the developer. A unit represents a number that I decide.

Working with percentages would be one way to construct these units, I assume?

And about physics, if I say, an object is defined as such:

x-position: 0.5, y-position: 0.25, width: 0.2, y-position: 0.2

I think that is okay to do? If there is no off-set, I assume it is safe to calculate the collider's position like this. But I assume one would usually save physics x, y, width, and height separately from sprite x and y.

One last thing, what's more common: Sampling every sprite directly to the screen-size or rendering in game's native-size to a view and sampling this to screen-size? Because first would require me to set the scale of each sprite manually, latter would make me set the scale of the view, I guess?

Share this post


Link to post
Share on other sites
14 hours ago, Angelic Ice said:

I think the rotating cube image did explain it fairly well:

Perfectly, I will remember rotation for future reference.

14 hours ago, Angelic Ice said:

So what I see is that Unity is using abstract units. Their meaning is given by the developer. A unit represents a number that I decide.

Working with percentages would be one way to construct these units, I assume?

Yes, exactly.:D

Both Unity and the percentage method use abstract units. The difference is that with the grid we decide how many pixels we want, while with the percentage method each unit is the size of the resolution.

This is why I said they are just alterations of the percentage formula. It's easier when you stop thinking of it as a percentage and instead think of it like a grid.

ZoomedOut.jpg.bc85f8abfd92689b2de0fea9ee9c0049.jpg

Once you start moving the camera around both systems act exactly the same way. The math remains the same and objects act the same way. You can't go wrong, no matter what you choose.

The percentage one is often used with games that don't have a moving camera. That way it is easy to find the location of every object and where it should be rendered.

The grid system is the most common one. This is because it allows more control and allows the developer to decide what is what. It's preferred with "scene" based games like Unity and Unreal makes.

15 hours ago, Angelic Ice said:

And about physics, if I say, an object is defined as such:

x-position: 0.5, y-position: 0.25, width: 0.2, y-position: 0.2

Is this based on screen size? If it is it isn't wrong but has a common downside, lets take an example. If it's relative to a screen size and the screen is 800*600 then: (0.5 * 800, 0.25* 600, 0.2 * 800, 0.2* 600) : 

position = (400, 150) and size = (160 , 120) See the problem?

Result.jpg.96731099b1ff11d1dce0f2c005637fa1.jpg

0.2 by 0.2 is what the sprite size is but because the screen is (4:3) we get a rectangle and not a square. If the screen is a wide screen then the result is a longer rectangle.

Is this what you meant?

 

16 hours ago, Angelic Ice said:

One last thing, what's more common: Sampling every sprite directly to the screen-size or rendering in game's native-size to a view and sampling this to screen-size? Because first would require me to set the scale of each sprite manually, latter would make me set the scale of the view, I guess?

The rendering is scaled.

Share this post


Link to post
Share on other sites

I gave all these concepts a bit more time for me but still have some questions:

When does the conversion from abstract values to real values happen? When I load an object and simply mutate the abstract value with the real one or does that happen prior drawing and I keep working with abstract units all the

The issue I have with this, when the sprite moves, the graphics position change too, but do I mutate abstract values? This is a bit mind boggling to me.

Also on another note, when my sprites are 1024x1024 large, simply because they have a high resolution, how do I handle the game's native screensize? We talked about using down- and upsampling of 1280x720 and 1920x1080, but this would result in a very huge size. If I have a row of 10 of them and I want them to fit into what the player sees, I would already need a format with at least 10240 pixels, I think that might be a bit brutal for a game's native size.

Should I lower the size of my sprites? How do quality settings in games come to play? Do they actually draw to a larger native size with higher texture-resolution or do they draw simpler/complexer textures? Or do they start with textures that are lower than supposed (e.g. 32x32 instead of 64x64) and upsample them until the settings are put to Very High and then the original size (e.g. 64x64) would be used?

 

Share this post


Link to post
Share on other sites
3 hours ago, Angelic Ice said:

When does the conversion from abstract values to real values happen?

All the time? This is confusing because there is lots of different ways of doing this. Most of the time you program on a 1:1 scale and the camera turns it to a 4:3 scale.

In other words, this isn't something you do do unless you also want to make your own render system (API Application Programming Interface, OpenGL and DirectX).

3 hours ago, Angelic Ice said:

The issue I have with this, when the sprite moves, the graphics position change too, but do I mutate abstract values? This is a bit mind boggling to me.

If your sprite moves 1 on the X and your screen is 3:4 then it will move 3 pixels on the X axis when rendered. Moving 1 on the Y also moves it 4 on the Y axis when rendered. You don't do this, your rendering API will or engine will.

3 hours ago, Angelic Ice said:

Also on another note, when my sprites are 1024x1024 large, simply because they have a high resolution, how do I handle the game's native screensize? We talked about using down- and upsampling of 1280x720 and 1920x1080, but this would result in a very huge size. If I have a row of 10 of them and I want them to fit into what the player sees, I would already need a format with at least 10240 pixels, I think that might be a bit brutal for a game's native size.

If your sprite is 1024*1024 but it only takes 64*64 pixels on screen then the API will keep down sampling till it has a 64*64 image to fill those pixels. This takes a long time.

It can't render 1024*1024 in a 64*64 space no matter how much it wants.

So to avoid this Mipmapping is used. Mip maps store do the sampling and keeps it in the "sprite" then instead of sampling the large texture and wasting performance.

See this video: https://drive.google.com/file/d/107_vHcHx_wByMARYj-LOgXnQYVyDhQEj/view?usp=sharing

This was made using a DDS texture that allows me to make custom mips for special effects.

 

So in other words if you used 10 sprites each of them a 1024*1024 and rendering them on a 1280x720 ratio then each sprite result will be: 1280/10 x 720/10 = 128x72 pixels per sprite meaning that X has to be down sampled 8 times and Y 15 times to scale it to fit on screen.

This means you are using 15 times the performance needed to actually display that sprite. Where with a Mipmap and Anisotropic filtering you would be able to render it around 10 times faster and get better results.

 

In other words you will only use a 1024*1024 sprite if the sprite covers 90% of the screen and you know most players will be using a screen +/- 1280x720.

Bigger sprites does not mean better quality unless your players have bigger screens. If you used a 4K (4096x4096) sprite it will never display that way on a 1280x720 screen no matter what you do. The screen just doesn't have enough pixels so it has to down sample the sprites.

 

Also 10 of the same C doesn't use 10 texture sheets so you won't need a 10240*1024 texture. You will just render the same sprite more than once. Only 10 unique sprites of 1024*1024 would need a texture of that size and you would pack it better like this:

10240*1024 -> 4096*4096 aka a 4K texture and it will look something like this:

From this:

10By1.jpg.90d163e6a48043bf8e86e4a3aefd5360.jpg

To this:

4By4.jpg.5f51b651ccbeab96b74988a917352884.jpg

Because computers like working with numbers to the power of two, meaning that the image bellow actually loads and renders faster than the image above. This is known as a atlas or tile sheets.

 

What is it you are trying to do? Are you making a rendering API? A engine? A game?

The knowledge you need in the moment depends on what you do. The stuff I am telling you took me years of experience as a professional 3D artist and a hobby 2D artist to learn(3D and 2D is the same stuff just have different names).

There is a lot of information you need before these things make sense, a lot you don't need to know to make games.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!