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
[combine
texture modifier regression
#14312
Comments
It looks like the code inappropriately used unsigned types when it should have used signed types; we were relying on if (x >= w0 || y >= h0)
COMPLAIN_INVALID("X or Y offset"); but which fails if This could have been caught with The fix should be trivial: Change these to |
As far as I am concerned passing negative coordinates or otherwise out-of-bounds coordinates should be an error. 🤷
I don't think it's hard to imagine that "if it looks like an error silently do nothing" is often not very helpful. |
Probably related: Signs from signs_lib (guess it's the posters) scroll horribly in chat with red warning messages (this is probably from a single poster):
|
There's no reason for an error if part of the image is still in the visible area, which is possible with negative coordinates. Anyway, I think we have to support this for backwards compatibility. |
Passing negative coordinates should definitely not be an error. That's how you achieve (arbitrary) cropping of images.
I don't think they can. Not in general anyways. They basically want to crop the creeper texture to only keep the head. If the creeper texture conveniently happened to align to a 16x16 grid which could be interpreted as a tilesheet, this would work. But in all other cases, it doesn't. Looking at the texture modifiers, we see
We could consider a "special case" where blitting an image completely out of bounds (that is, zero overlap with the original image) is an error. I don't think this is a good idea, for multiple reasons:
|
And here for signs_lib_color and others as requested (only some example lines; multi-line errors combined back into one line):
|
Regarding Sokomine's comment:
My PR should return both to the previous behavior (proper blitting in the first case, silent no-op in the latter case). |
[combine
texture modifier regression
Indeed.
My mental model for The fact that negative offsets safely and reliably do what they do and can be used to get arbitrary cropping surprised me and seems more like a happy accident to me. Consider also that the code has no special casing for this and blindly processes 262144 pixels when you want to "crop" anything (no matter how small) from a tilesheet sized 512x512.
I was thinking this should be made a warning at least.
As far as I can see all relevant parameters are in control of the mods here.
Only issue is that it's not currently a no-op (by work done, not end result). |
Steps to reproduce
/giveme mcl_heads:creeper
Result
Broken rendering
Working rendering (with b7822e7 reverted)
Looks like it doesn't accept negative offsets anymore?
The text was updated successfully, but these errors were encountered: