Trash pixels in game

#1

Hello,

The first thing, Defold is a great engine to make a game and I like it very much :stuck_out_tongue:
while making a game, I see my game have some trash pixel as an image below.

( i used the same image, but it happens randomly when scaling. rotating…)
Could you please help to solve it?

Many thanks

3 Likes

Back to Defold after 2 years, "Bouncy Catapult" hypercasual prototype
#2

I believe it is because the Atlas. Try extrude borders on Atlas.

02

9 Likes

#3

wow, it works fine now, you saved my life
many thanks

2 Likes

#4

I recall this was brought up a couple of times already in (ru) telegram community, maybe this should be a default?

7 Likes

#5

Fully agree with you https://github.com/defold/editor2-issues/issues/2332

5 Likes

#6

I don’t. It will increase the atlas size, and those additional border pixels could be what pushes an atlas above a certain size. We should however provide tooltips for the various properties of an atlas in the editor.

1 Like

#7

But if user wants good picture without those artifacts he has to add those extra pixels anyway.
Is it possible to change template only for new atlas file without affect already exist?

3 Likes

#8

Yes, sure. But which value should we chose? 1 is not always enough (especially if you scale your graphics a lot). And setting 2 would be overkill on several situations, but not all.

Defold is a tool for professional developers and while it can be used by beginners as well I think it’s better if we’re not prescriptive and make decisions for all developers. Developers should be aware of (or made aware of) things such as texture bleeding and make a conscious decision when creating an atlas and setting an Extrude Border value based on how the atlas will be used.

11 Likes

#9

Fully agree with you. Moreover, I am sure that professional can (and will) change any default parameters as he/she wishes because he/she knows what those parameters do. For professional 0 or 2 doesn’t matter.

I am talking a lot with people who start working with Defold, they faced a lot of difficulties and this issue with atlases is one of most mentioned.

8 Likes

#10

Do it by default, please! 2 pixels!

3 Likes

#11

I agree with britzl. I ran into this issue myself when I started out, tooltips at that point would have been very helpful. I don’t think the solution is to arbitrarily pick a number (1, 2, etc) and set that as default.

Perhaps a setting in game.project? Under “graphics”, “set default atlas extrusion”.

¯_(ツ)_/¯

5 Likes

#12

This “edge bleeding” issue is not a Defold only problem, it occurs in other engines too as it’s to do with the way graphics cards render textures. Defold offers a solution to this in the “extrude borders” setting but I think that should be an opt-in solution - having it on by default would likely cause different issues, say you have a 512x512 texture, the atlas containing that would then pop to something like 1024x1024 in size because the extrusion has pushed it over that 512px boundary.

4 Likes

#13

99% of the time I set margin of atlases to 2. Only in some pixel art projects do I not set a margin but extrude borders by 2, that is tilemap squares.

Perhaps it could be an option to set in the editor to default to a certain margin value when creating a new atlas.

4 Likes

#14

I too agree with @britl.
And we do agree that everything should be balanced properly between easy-of-use, correctness, performance etc.

In this case, the visuals is making it clear, that something is up.
It’s much better than simply hiding the fact that you potentially get a much bigger texture loaded in game. This way, you learn something valuable, and you will stay in control of your bundle size and visuals.

4 Likes

#15

On the other hand, once you know the problem, it becomes “busy work” to do it for nearly every single atlas. Customizing defaults would be nice!

6 Likes

#16

Yes, and then you can go to your atlas settings and remove this 2px border in some exact edge cases, when you have a 512x512 texture alone in 512x512 atlas. And even if you’ve missed that 512->1024 atlas size thing, it will not brake your game, and will not mess the visuals, just some extra memory consumption which might be painless (plus, it’s hard to miss this case, because you see your 1024x atlas in editor when you create it, so you can fix it immediately, when issues with edge bleeding appear only in run-time)

When having border = 0px in an atlas with several textures in it will mess your visuals in… 100% cases?

Being professional does not mean, one should fight with the engine to make it work at least “normal” from the box. You can’t fix this by tooltips or FAQ or whatever, new engine customers will face this issue over and over, asking the same questions onforum and chats, over and over.

Even if solution is well known and you can google it in 5 minutes (or, say, in our russian defold chat you’ll get an answer “haha, welcome to the club, just set the borders of your atlas to 2px” immediately after mentioning issues with messed textures). I think it should be set to 2px by default, and changed manually if it’s not good enough in special cases. Please.

“Default settings” means something, that will work in most cases. Well, now in “most cases” it seems to be not working.

4 Likes

#17

I bet this is one of the reasons that we nowadays see mobile games with a size close to 1Gb in size. Developers simply not caring about the size of the assets in their games.

Yes, this situation might not matter much for a single atlas, but if it happens for several atlases it could have a big impact. And if you go above for instance a 4k texture then it could have potentially huge impact. And the tricky thing is that you might not notice this problem until you get one-star reviews saying that the game is crashing…

With the texture bleeding you notice it during development, not after.

1 Like

#18

I agree with the argument “you can miss the fact, that your atlas became 4k size instead of 2k”, but I don’t really see how it’s related to the current topic with borders size. If you don’t know that textures sizes on some devices ar limited by 2k max, then you can make your atlas 4k regardless of borders sizes.

Let’s imagine a newbie, he created his first assets, put them into the atlas, faced issues with edge bleeding, googled the solution and then made his main atlas maximum size of 4k, because - why not? And got 1-star reviews. Forcing a user to deal with borders sizes, is not really about teaching him about textures sizes, right?

And if you already know about such thing with textures sizes limitation by 2k, you see your atlas size in the Editor (“during development, not after”) and if it appears more than 2k you’ll fix it.

Right here we’re talking about one exact step which almost every developer is forced to do, which can be easily avoided. Yes, if you don’t understand what you’re doing, then you can mess everything up, but forcing “edge bleeding” from the box does not teach you anything, just some “bug” you’re trying to fix, it does not say you anything about how GPU works, or what limitations on hardware can be, if you don’t research such info by yourself.

So what’s the point of keeping settings, not suitable in most cases? To keep engine “pure”? For whom? Isn’t it made for customers, to hepl reach ther goals? Or to teach them to do things right?

UPD: Sorry if I sound rude, maybe setting it by default for all projects is not the best solution, but I think just a tooltips will also be not enough. Can there be some compromiss? Like having different “default” templates, say “white list template” and “comunity-driven template” with 2px borders, “size_fit” render projection, scaled physics, disabled mip-maps etc?

1 Like

#19

Some arguments that you make are valid, but I still think it makes most sense to not make a choice for the user. It’s better to keep the value at 0 and let the user make the decision. Select 1 if you’re not scaling your graphics, 2 or more if you intend to scale the graphics.

I downloaded TexturePacker and it also defaults to 0:

4 Likes