-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
Re-allow destsurf scale w/ diff but compatible pixelformats #2172
Re-allow destsurf scale w/ diff but compatible pixelformats #2172
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool fix, thankss 🌟
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whilst this does solve the case of RGBX sources it does not fix BGRA cases (and possibly others) which the method prior to 2.2.1 handled fine so it will likely need to be modified to support those as well.
What kind of BGRA cases? If you're trying to scale a BGRA surface onto a RGBA surface it should fail. It "worked" before but would produce incorrect output. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cases where the destination format was BGRA which would result in altered colours in the old method.
Though if that was unintentional behaviour of the old function then everything else should be good to go.
My thought is that it’s better to explicitly fail in that case rather than give such weird output. |
It likely is, I can't see many scenarios where someone would intentionally make use of the scaling methods to also change the displayed colour at the same time, there's a greater chance someone would accidentally cause that problem when scaling which the error message would help with. |
cca990d
to
e6bef67
Compare
Fixes #2116
So, in #1884 I replaced our bespoke scaling code with a call to SDL_SoftStretch. I also removed our explicit source bitdepth == dest bitdepth check when a dest surface is provided, because I knew SDL_SoftStretch would do that error for us.
What I failed to take into account is that there are in fact times when a dest surface would be used (with the same bitdepth) but with a different pixelformat.
For example, scaling a RGBA image onto an RGBX destination surface. It was able to handle that before, and a few people used that functionality.
So I had a few ideas:
I went with the third option, using CreateSurfaceFrom to share the pixel data with the existing destination surface.