Alberto

> Yes, the output surface will be different because you will multiply by the alpha again. Maybe add this to the docs?

Right now this function is between 20-30% faster for drawing hollow polygons and between 5-7% faster for filled ones. And I'm comparing it to a for loop + pygame.draw.polygon().

Putting out the new test that shows improved performance with 2 arguments: ``` coll point: 0.7030235000001994 not coll point: 0.7181456999996954 coll point two: 0.4383071000002019 not coll point two: 0.4396271000005072 Total:...

I expanded my test suite for more cases and got these results: **NEW** ``` coll point: 0.7149117999997543 not coll point: 0.7133573000000979 coll point lst: 1.0290474000003087 not coll point lst: 1.0237922999999682...

Latest test (latest commit improved performance of an additional 2.7% and cleaned up the code) ``` coll point: 0.6911872000000585 not coll point: 0.6898155000017141 coll point lst: 0.9968098999997892 not coll point...

I recently added 2 new C API functions for getting an int from an object (`pg_F_IntFromObj`) and two ints from a sequence (`pg_F_TwoIntsFromObj`). I really hope these two function can...

Latest results: ``` ====||SEQUENCES||==== -) tup inside tup: 0.50052934 s -) coll tup: 0.4147287 s -) not coll tup: 0.41854068 s -) coll list: 0.68230462 s -) not coll list:...

Latest test: NEW WITH FLOAT POSITIONS ``` ====||SEQUENCES||==== -) tup inside tup: 0.38056136 s -) coll tup: 0.36971348 s -) not coll tup: 0.35821488 s -) coll list: 0.57929936 s...

Yeah for example we also have clock.tick() and clock.tick_busy_loop(), two functions that are very similar, yet one is more precise. I've seen that python itself with its "adaptive intepreter" is...

I'm making this a draft so that we can implement the C API functions first and then implement them separately