Function texture_set_shrink_all_x2_on_set_data is missing from Godot 4 RenderingServer

k8035 commented 2 years ago

Godot version

4.0.beta2.mono

System information

Windows 11

Issue description

The method void texture_set_shrink_all_x2_on_set_data ( bool shrink ) (see 3.x documentation here) is not available in Godot 4's renamed RenderingServer class.

We use the method for the purpose described here:

https://docs.godotengine.org/en/stable/tutorials/rendering/multiple_resolutions.html#reducing-aliasing-on-downsampling

If the game has a very high base resolution (e.g. 3840×2160), aliasing might appear when downsampling to something considerably lower like 1280×720. Aliasing can be made less visible by shrinking all images by a factor of 2 upon loading. This can be done by calling the method below before the game data is loaded:

VisualServer.texture_set_shrink_all_x2_on_set_data(true)

We decide to call or not call the texture_set_shrink_all_x2_on_set_data method depending on the screen resolution. For resolutions of 2880x1620 or higher, we use the original textures that are optimized for 3840x2160 and do not call that method. For lower resolutions like 1920x1080, we call texture_set_shrink_all_x2_on_set_data in order to reduce the required texture memory and to reduce aliasing.

Available alternative: we could use mipmapping instead. However, this needlessly increases texture memory usage when the user is running a resolution like 1920x1080.

Steps to reproduce

(Using Godot 3.x)

Create a 2D project and set the base size to 3840x2160
Import some texture and place it as an image in the scene.
When running the project at a resolution of 3840x2160, the texture will be displayed in original quality.
Add the method texture_set_shrink_all_x2_on_set_data to ready() of the main scene, in an IF statement that checks whether the screen resolution is lower than 2880x1620.
When running the project at a resolution of 1920x1080, the texture should be displayed at half its resolution, reducing aliasing and reducing memory usage.

Minimal reproduction project

No response

clayjohn commented 2 years ago

I believe this functionality was moved to the importer in Godot 4.0. That being said, it sounds like your game relies on having the ability to downscale all textures at run time, so an importer option may be of little help.

k8035 commented 2 years ago

If I can suggest a more elaborate feature, generally I expected to able to do something similar to how multiple resolution assets are done on iOS/Android and in frameworks like Corona/Solar2D SDK (see here for the docs and here's an example configuration). Compatibility with ninepatches included, with consistent ninepatch margins across different resolutions. They achieve this by decoupling texture pixel sizes from UI element point sizes.

The "One size fits all" approach, the downsampling approach with mipmaps, and the downsampling approach with VisualServer.texture_set_shrink_all_x2_on_set_data(true) all have significant drawbacks compared to the approach taken by Solar2D.

This is for a 2D UI that is intended to be visually just as crisp as the OS desktop, and it needs to be energy-efficient and work on mediocre hardware too. ( e.g. by using Low Processor Mode)

Desired project configuration:

A project with a base size of 1920x1080.
At resolutions of 2880x1620 or above, all textures are loaded at 2x their original size (e.g. 240x240), with a suffix "@2x".
At resolutions of 1920x1080 or above, all textures are loaded at 1x their original size (e.g. 120x120), with a suffix "@1x" or no suffix.
At resolutions of 1280x720 or above, all textures are loaded scaled at 0.666x their original size (e.g. 80x80), with a suffix "@0.66".

Ideally, the developer can choose whether to supply textures in several sizes in the project, with different freely definable filename suffixes ("@1x", "@2x", "@4"), or to scale down the original size during loading, with a freely definable scale factor (not just 0.5).

Calinou commented 2 years ago

Duplicate of https://github.com/godotengine/godot/issues/43276. Please post your findings there as a comment :slightly_smiling_face:

They achieve this by decoupling texture pixel sizes from UI element point sizes.

This was proposed in https://github.com/godotengine/godot/issues/23145 and rejected. That said, feel free to open a proposal for this on the godot-proposals repository, as the status quo may have changed since then. I personally think it's a good idea in some cases, but it may also make things more difficult to handle for beginners. Also, it should be done in a way that works with textures supplied to Control nodes as well (such as checkbox icons).

Ideally, the developer can choose whether to supply textures in several sizes in the project, with different freely definable filename suffixes ("https://github.com/1x?type=source", "@2x", "@4"), or to scale down the original size during loading, with a freely definable scale factor (not just 0.5).

Doing this can waste a lot of file size (while also requiring manual work from the user end). I think these files should be resized on load and optionally cached instead. It takes some more time, but unless you intend to ship HD textures as a separate DLC, this on-the-fly approach can save several gigabytes in a complex 3D game.

godotengine / godot