Aaline blend test

[illume]

Continuing on from the PR #582 so we can all change things in a branch on pygame repo if needed.
For the issue #575

• adds a test for aaline blend
• moves to use builtin trunc if it exists, else old trunc function. This is because casting to int is slightly different behavior to trunc() when numbers are negative. I'm not sure if the builtin one is near the speed of casting to int speed, or if it matters if we have exact trunc behaviour.
• ran clang-format on the draw.c code as suggested for formatting.

[dlon]

Hmm, casting to int is fine, I think. Source for that algorithm: https://web.archive.org/web/20160512070449/http://freespace.virgin.net/hugo.elias/graphics/x_wuline.htm

function trunc(x)
	return integer part of x
end of function

Should be okay for negative numbers: (int)(-2.6) = -2. The only difference is that trunc() returns a float, as far as I can tell.

[illume]

The reason I think it could have trouble with negative numbers is that trunc will cause the number to go to either the left, or right depending on if it is negative. So for diagonal negative lines, the results could be 1 pixel off what they were before?

[dlon]

They seem to give the same results:

#include <math.h>
#include <stdio.h>

#define TRUNC(d) (((d) >= 0.0) ? (floor(d)) : (ceil(d)))

int main() {
	for (float i=0; i<3.0f; i += 0.4f) {
		printf("%f %d %f %f\n", i, (int)i, trunc(i), TRUNC(i));
	}

	for (float i=0; i>-3.0f; i -= 0.4f) {
		printf("%f %d %f %f\n", i, (int)i, trunc(i), TRUNC(i));
	}

	return 0;
}

0.000000 0 0.000000 0.000000
0.400000 0 0.000000 0.000000
0.800000 0 0.000000 0.000000
1.200000 1 1.000000 1.000000
1.600000 1 1.000000 1.000000
2.000000 2 2.000000 2.000000
2.400000 2 2.000000 2.000000
2.800000 2 2.000000 2.000000
0.000000 0 0.000000 0.000000
-0.400000 0 -0.000000 -0.000000
-0.800000 0 -0.000000 -0.000000
-1.200000 -1 -1.000000 -1.000000
-1.600000 -1 -1.000000 -1.000000
-2.000000 -2 -2.000000 -2.000000
-2.400000 -2 -2.000000 -2.000000
-2.800000 -2 -2.000000 -2.000000

I'd guess that the builtin trunc() is faster than floor() and ceil(), though

Edit: I realized that the sign might matter, but does it?

[illume]

trunc is used in a few spots, and perhaps some(or all) of them would be fine with casting-to-int trunc?

• Maybe they won't ever go negative because surface coordinates should never be negative?
• Also, If trunc result is used with an unsigned value, then it's not going to go negative.

[e1000]

Ok for me if the new test passes (which I assume) even though it might become wrong after decision on #522 .

After merging this branch , we should close #575