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

intensity default #322

Open
Paril opened this issue Oct 21, 2023 · 3 comments
Open

intensity default #322

Paril opened this issue Oct 21, 2023 · 3 comments

Comments

@Paril
Copy link

Paril commented Oct 21, 2023

This is a continuation of the discussion we were having in the glowmap PR about intensity/gl_modulate.

I'm implementing muzzle flashes from Q2R, but the default intensity of 2.0 ends up blowing out the image colors entirely - they should be orange, but they're getting scaled to yellow (and in the case of the blaster one, they become nearly white).

I'm starting to think that intensity really should be 1.0 by default, because 2.0 over-saturates colors against artist intent, and gl_modulate should be pumped up instead to counter-act the lightmap darkening. It ends up looking the same, except entities in particular don't have their skins blown out:


This is what I'm gonna do in our fork at least, but I think it should be at least considered for regular Q2PRO as well.

@skullernet
Copy link
Owner

The problem with changing default value is that it will break existing user configs. Also while intensity is mostly redundant to gl_modulate in shaders mode, in legacy mode it acts somewhat differently. But yes, current situation with 2 intensity and 4 modulate cvars (including gl_doublelight_entities) is an awful mess. Since you are prioritizing re-release support anyway maybe this is an opportunity to clean this up in your fork. No idea were to start with this in Q2PRO though.

@Paril
Copy link
Author

Paril commented Oct 23, 2023

Config versioning maybe? We did that in Kex - we have a config_version cvar that we can increase (or assume its default value is 0), so like if you load the game and config_version is 0, then it can check if the options were unchanged (gl_modulate == 1 && intensity == 2) and swap them or something. It's tough since it's impossible to know what was set by default and what was changed by the user...

But yeah we've swapped the defaults in our fork and will probably use a different .cfg file name just to avoid any collisions.

@res2k
Copy link
Contributor

res2k commented Oct 23, 2023

An alternative might be to choose different cvar names... that way, for existing configs the settings would be "reset", but at least they wouldn't be broken as in "old intensity from config but new modulate default".

Also, to my knowledge, the texture color modulation done by "intensity" might not necessarily be needed in legacy mode - if multitexturing is available, texture modulation (by some factors) would be available as well.
So the "intensity" application could also be disabled for "legacy with multitexturing" and only made active in the "legacy without multitexturing" case (ie extremely rarely, I'd guess).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants