Is it really the truth? There is no anti aliasing for 2D? I don't believe!

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By individlab

How can I create universal mobile game with huge size graphics without anti aliasing? Please help if I’m wrong and there are methods to smooth graphics. Thank you.

I’ve tried to set mipmaps, filter and reimport images, but it still doesn’t work for me( and it has many artefacts.

How it looks on iPhone

:bust_in_silhouette: Reply From: MysteryGM

The images you linked are raster images, aliasing would have very little effect on them.

It is true that Godot doesn’t have aliasing in 2D, but aliasing mostly effect vectors, sampling the sharp edges to get a softer edge.

For your own images there is a few design principles you need to follow for Filtering to work; filtering is what you are looking for.

1.) A small empty boarder needs to be placed around every image, 2 transparent pixels on each side should be perfect.

2.) Mips and Filtering only work on images of power2 that is 64x64 or 32x512 etc. X and Y doesn’t have to be the same.
List [1, 2, 4, 8 ,16 ,32 ,64 ,128, 256, 512, 1024, 2048, 4096 etc.]

3.) If you have buttons that are odd sizes like 100*50 pixels you will need to atlas them on a sheet that follows the power2 rule.
You can often fit the whole GUI on a single 2048x2048 texture atlas; saving a lot of memory and loading time.

You will need to make manual “TextureRegions” for each button. Because the Godot AutoSlice isn’t going to keep the 2 transparent pixels you need.
I find the Godot TileMap tool works for this.

For the text: Under DynamicFont->settings->MipMaps and Use Filter here.
Fonts follow the power2 rule so enabling them will work without any problem.

Wow! Thank you very much! I will try.

individlab | 2018-09-27 23:17

Can you recommend any tool for creating atlases?

individlab | 2018-09-27 23:38

Gimp, Photoshop. You don’t need a special tool to make atlases, they are just sprite sheets but often contain objects with no animation or only a few frames.

It looks like this:


Any image editing software can make them.

MysteryGM | 2018-09-28 00:25

Hi, there!
Sorry for interfering, but creating atlases in GIMP or Photoshop is not the way to go for at least two reasons: Firstly, you will have to create separate text file with coordinates of sprites manually. Secondly, placing them like in screenshot above will waste image space (of course, if all of them of same size, it will be easier to use from code).

I am not sure if Godot supports creating texture atlases out of the box, may be someone with knowledge can reply here (Godot API have AtlasTexture resource by the way). If not then you DO NEED special program - like Texture Packer (commercial) or Cheetah Texture Packer (free), or any other you can find on the Internet. Such tools effectively packs sprites together and automatically creates supporting file with coordinates in different formats (like JSON etc.)

You can even write your own packer yourself right in GDScript (there are many examples of rectangle bin packing algorithms on the internet or books (for example, Lua Game Development Cookbook, its in Lua but can be comparatively easily translated to GDScript)).

Also be aware of infamous “texture bleeding” problem if you plan to use mip-mapping or scale those sprites. Godot’s documentation contains information about this problem.

mart | 2018-09-28 12:32

Thank you! Interesting)
I found an online tool for example:
http://free-tex-packer.com/

individlab | 2018-09-28 15:30

The above image is an example, but let me clarify in case there is any confusion.

*UI atlas should have a transparent background. Not Blue
*At least 4 pixels between each object. Not cantered and large gaps.
*No Watermark/Logo covering the UI components.

The above things are done by UI designers when they upload examples to the net, these things make it difficult to steal their work. Don’t imitate it.

As for mip bleeding that is solved with box filtering when generating mips. If Godot doesn’t allow using custom mips then try the Gimp/Photoshop DDS addons.
DDS is a texture format that allows custom mips and the plugins for using it has a fantastic range of settings.

As for atlas software, they are not needed and unfortunately require plugins with their own bugs and problems to use.
It would be faster to just import the sheet into Godot and use the Texture Region tools.

Once Godot has full sprite sheet and atlas support , atlas tools will be more efficient. Even so you can use them if you want.

MysteryGM | 2018-09-28 23:53

@MysteryGM I’m still not convinced ).

Of course you can go without special tools, but it would be huge manual work if sprites’ number is big (and all or part of them can also be removed and/or replaced several times during game development). May be this depends on use case. When i found myself constantly playing “tetris” with hundreds of sprites of different sizes i decided that this is too boring task to do manually. Better to spend that time on game design for example.

Also optimal arrangement of sprites manually is hard. Sometimes dedicated tool can make atlas 4x times smaller than carelessly arranged by person (i’m not talking about this screenshot here, but in general). Also i’d like to point that if optimal arrangement of sprites is not needed then it still better to use ImageMagick’s “montage” command to automate spritesheet creation than some graphics editor.

IMHO bugs are not a reason to reject special tools. Graphics editors has bugs, Godot has bugs, my game has bugs. We can always send issue to developer of tool/plugin to deal with this. Also, i’m interested what bugs in what plugin you encountered?

From my experience (may be too poor, but I struggled with this problem several weeks in the past) mip bleeding is unavoidable by just using border (or even repeating pixels from opposite sides like many people suggests) (don’t matter 1, 4 or even more, say 32 pixels) and box filtering in all situations. For example in my case it was a tiled environment with FPS camera. For repeatable tiles i found two methods to completely avoid this: 1. Put each tile nine(!) times in the atlas in square formation and use UVs of central tile (too much space wasted). 2. Use very complicated (for me at least) approach like described in paper “Invisible seams” (Eurographics Symposium on Rendering (2010)) (haven’t tested that).

Nevertheless, if you forced to use texture atlases, i still think that a best way is to integrate their creation(not only at design-time but essentially at run-time) into Godot as you noted in last comment (GDScript or GDNative plugin). This will allow to create atlases on the fly (rectangle bin packing algorithms runs fast enough for this). Imagine that you have a bunch of common sprites and sprites specific for each level in the game. They can be combined before loading next level, reducing the need for atlases with redundant sprites, which is inevitable at design-time.

Sorry if i’m sound somehow offensive here. I would be pleased to hear your comment if you can spare some time to read so long text and reply.

mart | 2018-09-29 14:36

It works very good, thank you!)
But the loading time on ios becomes very long with atlases.
Is it possible to do anything with it?

individlab | 2018-10-05 08:38

I’ve got only 3 atlases 2048.

individlab | 2018-10-05 18:28

It depends on your situation.

As i pointed earlier, run-time atlas generation allows flexible strategy with loading different set of sprites. You load only sprites needed by current game level, appending or replacing them inside previously created atlas.

You can make use of background loading (see in Godot’s documentation) and show user some interesting hints about game (short tips how to play, etc.) while atlas is loading. At the very least progress bar showing the status of loaded data is better than nothing.

Use image formats with stronger compression algorithm (like jpg instead of png, or one of compressed texture format supported by Godot) But those are lossy image formats so you have to sacrifice some image quality in exchange for faster loading and smaller image size.

Review all your sprites: does all of them are really needed at all? Maybe you can use a sort of procedural generation of graphics instead of loading from file. For example, instead of loading several buttons with different colors you can use one button with black or white color and apply modulation or shader to that button to get all others. If several similar sprites differs only by text labels - apply text separately. If sprites shares some common parts, split them and combine those parts to get different sprites at run-time.

mart | 2018-10-07 22:32

:bust_in_silhouette: Reply From: bdani2000

You can enable Hidpi in Project settings → Display → Window. It makes the resolution adaptive to the screen’s so this effect becomes less visible on larger-resolution screens. I know this doesn’t solve the issue, but it helped for me.

Allowing hiDPI only affects hiDPI displays on desktop platforms. It has no effect on mobile platforms.

Calinou | 2021-01-25 17:29