Formatting should hopefully be correct finally

The source of this problem is very mysterious. I think it's SIMD related, but why? SIMD doesn't do approximation, it just does acceleration.

I don't think the solution is to just add a delta to the test. I would prefer it to test that the result is EXACTLY X or Y, rather than testing whether it's within 4 of X.

I am of the view that as long as something blitting related does not change much visually, it shouldn't be considered a break.
The underlying formula is an implementation detail, especially while using the SDL blitter, we should not treat things as a break when they make minor changes on their side. So to me having a delta makes sense, but I don't mind changing the exact number specified in the delta

Blitting should be 100% deterministic. Input A goes to output B, every time, 100% accurate. The fact that it isn't (on the SDL2 blitter) is extremely unsettling.

I believe our current situation is that Input A goes to output B or output C, based on SDL version / architecture. Therefore I'd like to test the output against B and C, and only fail if it is neither.

I don't want it to drift again without our noticing, and that's what a delta does.

Alright I'll look into changing the implementation to use fixed outputs as specified by the original error but I will need someone else who has those architectures to test that it resolves the issue.

Blitting should be 100% deterministic. Input A goes to output B, every time, 100% accurate. The fact that it isn't (on the SDL2 blitter) is extremely unsettling.

Blitting should be deterministic for a given SDL version? yes. Theexact same on all platforms across all SDL versions of the past and future? Probably too much to ask, even if desirable. SDL can make algorithmic changes, and since the exact algorithm is not a documented API detail, I don't see why they shouldn't be making tiny changes to it if it helps with performance, even though the exact pixel colours change a tiny bit. I can understand if there's a big change that has visual affect, it could be considered a breaking change.

If I had to guess, I'd say this PR changed thingslibsdl-org/SDL#5430 (I tested on windows 2.24.1) but I'm not very sure. Atleast I didn't find anything else blit related that changed.

I don't want it to drift again without our noticing, and that's what a delta does.

I'm saying we shouldn't care of minor drifts. I can't tell the difference between(255, 10, 100) and(253, 12, 98) when they are in the same image side by side. Visually I can't see the line of separation and it looks all pink to me, even though I'm sure the lines technically there. Am I colour blind? Probably not 😄

I also don't want to add the maintenance burden of having to keep updating our tests everytime SDL does a minor change like now. pygame users who resort to using the SDL blitter are the same target group of people who care about performance and not exact match with the pygame blitter.

Created an implementation that checks if its either the normal outputs or the ones provided in the original issue, just need to come to a decision on which version would be a better choice now. Can view the differences here in the meantimehttps://github.com/Temmie3754/pygame/tree/surface-test-fixes.

I'll merge it in now, it's a non-risky change and as said before should better future-proof this test. If the need arises in the future, we can consider a stricter but more-maintenance-ey test then.
Definitely the docs aroundBLEND_ALPHA_SDL2 needs updating to reflect the latest pygame blitter improvements, and the inter-SDL-version minor differences, but as MyreMylar says that can happen in a future PR, lets get this one in 🥳