Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tr_shader: colormap stage with 2D image bit is generic2D #1208

Open
wants to merge 1 commit into
base: for-0.55.0/sync
Choose a base branch
from

Conversation

illwieckz
Copy link
Member

Color map stage with 2D image bit is generic2D.

We can skip the render-time test for them.

Also make a variable local to the block using it.

We can skip the render-time test for them.

Also make a variable local to the block using it.
@illwieckz illwieckz added T-Improvement Improvement for an existing feature A-Renderer labels Jun 24, 2024
@slipher
Copy link
Member

slipher commented Jun 25, 2024

Why 0.55?

@illwieckz
Copy link
Member Author

Because RSF_2D is not in master, it was added in:

Providing RSF_FITSCREEN and RSF_2D broke compatibility with game.

@slipher
Copy link
Member

slipher commented Jun 28, 2024

Is that really a good way to decide whether we are doing 2d rendering? What if the same image were used for both something in the UI and something in the map and it got registered with the 2D flag. The if ( backEnd.projection2D ) that we have now seems more reliable

@illwieckz
Copy link
Member Author

illwieckz commented Jun 28, 2024

That's something that crossed my mind, but images with RSF_2D flags are created by the game for its own UI. There are even no legacy image having RSF_2D flag to take care about.

Those images are usually using 2D-specific options like disabling mipmapping and preventing the downscale of them like with noPicMip or fitScreen. Using them on a 3D surface may work but would be hacky and it would be recommended to create a special shader for them.

Also those images using the RSF_2D flag usually live in folder like ui/ which are not usable at all on map surfaces: only images in textures/ can be applied on map surface. Well it's possible to edit a bsp to set non-textures-prefixed images, but the map source format make it impossible to do in a map editor or even by hand in the map format itself..

Those 2D images may still be usable by the engine anyway, like on a model, or in a particle system. For example I know some maps have implemented fireworks using a granger emoticon as particle. As far as I know we don't set RSF_2D on them. It would be then considered wrong to set RSF_2D on them.

If one day we implement UI on some 3D surfaces (like some DOOM3 in-game screens), we would either duplicate the shader, either remove the RSF_2D flag.

The purpose of the RSF_2D flag is to tell the engine it's an UI image. In fact we may even rename it to RSF_UI to avoid confusion with SHADER_2D (which I have no idea what it is about, but is unrelated to the 2D UI images).

Edit: And we may even rename generic2D as genericUI.

@slipher
Copy link
Member

slipher commented Jun 28, 2024

Fine, you can say the use cases for that are doing it wrong, but the benefits from this seem microscopically small. So I disapprove of the proposed change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Renderer T-Improvement Improvement for an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants