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

Move no-mipmapping from actor renderflag/particle flag, to a material… #2770

Merged
merged 1 commit into from
Oct 19, 2024

Conversation

nashmuhandes
Copy link
Contributor

… property in GLDEFS, where it makes more sense. The feature was introduced in the short-lived engine version of 4.13 which was deemed too broken and needed to be replaced with a newer version anyway, so might as well perform an API-breaking change at this point in time. Note that this currently only works for sprites (its primary targeted use case) -- walls, flats and models can be patched in later.

To re-iterate its use case - small, moving transparent sprites look undesirable with mipmapping (can be seen in the example file) -- they "phase" in and out with camera distance.

Example file:

NoMipmapTest2.zip

… property in GLDEFS, where it makes more sense. The feature was introduced in the short-lived engine version of 4.13 which was deemed too broken and needed to be replaced with a newer version anyway, so might as well perform an API-breaking change at this point in time. Note that this currently only works for sprites (its primary targeted use case) -- walls, flats and models can be patched in later.
@madame-rachelle
Copy link
Collaborator

I would like an opinion from @coelckers before moving forward with this one. GZDoom has historically been an engine that generally respected backwards compatibility but this truly has never been 100% the case, there have been exceptions here and there (Doomsday hi-res textures being probably the most prominent). Sometimes it does make sense to break with that norm, but I don't have a dog in this fight, other than to say I have no issue with whatever the final decision will be.

@nashmuhandes
Copy link
Contributor Author

nashmuhandes commented Oct 18, 2024

Here are my thoughts:

  1. The initial submission wasn't well-thought - I will take the blame for that one
  2. to counter (1) -- there was no feedback or resistance to the initial PR (here) -- hence why we arrive where we are right now :P
  3. But I also understand that people have busy lives, mistakes can be made, etc...
  4. ... which leads me to my final point on why I think this is OK -- realistically, no one has had a chance to use this feature yet, and GZDoom 4.13 is shortlived due to some other critical bugs (like the sector damage one). And I consider this particular feature also another oversight and am taking responsibility to quickly rectify it before it gets widespread.

@Blue-Shadow
Copy link
Contributor

Searching the wiki for the added flags yielded nothing, luckily, which adds to the feature's obscurity.

@madame-rachelle
Copy link
Collaborator

Well the longer this goes unaddressed the more likely the Streisand effect will take hold, so if this isn't addressed later today I will just merge it.

@madame-rachelle madame-rachelle merged commit 12c6d13 into ZDoom:master Oct 19, 2024
9 checks passed
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

Successfully merging this pull request may close these issues.

3 participants