I played around with this myself as well, although this doesn’t quite deliver the expected result.

```
Before sorting clockwise
[(0, 384), (0, 640), (64, 384), (64, 640), (128, 448), (128, 640), (192, 448), (192, 640), (256, 448), (256, 640), (320, 448), (320, 640), (384, 448), (448, 512), (512, 512), (576, 512), (640, 512), (704, 512), (768, 512), (832, 512), (896, 512), (960, 512), (1024, 512), (1088, 512), (1152, 512), (1216, 512), (1216, 640)]
After sorting clockwise
[(1216, 512), (1152, 512), (1088, 512), (1024, 512), (1216, 640), (960, 512), (896, 512), (832, 512), (768, 512), (704, 512), (640, 512), (576, 512), (512, 512), (448, 512), (384, 448), (320, 448), (256, 448), (320, 640), (192, 448), (256, 640), (192, 640), (128, 448), (128, 640), (64, 384), (64, 640), (0, 640), (0, 384)]
```

Although it does sort by angle correctly, it’s not truly clockwise yet because it does not factor in the distance to the various points correctly. Going through the different points listed, you can note as to how the angle will increase on these first points, but it is actually moving down on the x-axis whilst remaining on the same y-axis. And in the end it’s making zig-zag jumps.

In some way I think the distance_squared_to() function needs to be factored in, referring to the origin as Vector2(0,0). But I have yet to figure out the correct code to mix these two.

I have tried the following:

```
var origin = Vector2(0,0)
if a.distance_squared_to(origin) < b.distance_squared_to(origin):
if a.angle() < b.angle():
print("a: ", a, " b: ", b)
return true
else:
return false
else:
pass #...
```

Herein taking the notion that if a is closer to the origin than b, I only want to sort it this way if the angle of a is actually less than b.

```
a: (1216, 512) b: (1216, 640)
a: (1152, 512) b: (1216, 640)
a: (1088, 512) b: (1216, 640)
a: (1024, 512) b: (1216, 640)
a: (320, 448) b: (320, 640)
a: (256, 448) b: (256, 640)
a: (256, 448) b: (320, 640)
a: (192, 448) b: (192, 640)
a: (192, 448) b: (256, 640)
a: (128, 448) b: (128, 640)
a: (64, 384) b: (64, 640)
```

The coordinates matching these conditions are the ones above.

And having “finished” the sort (I would assume it leaves part of it just unsorted, because there is no further conditional), this gives:

```
After sorting clockwise
[(1216, 512), (1152, 512), (1088, 512), (1024, 512), (1216, 640), (960, 512), (896, 512), (832, 512), (768, 512), (704, 512), (640, 512), (576, 512), (512, 512), (448, 512), (384, 448), (320, 448), (256, 448), (320, 640), (192, 448), (256, 640), (192, 640), (128, 448), (128, 640), (64, 384), (64, 640), (0, 640), (0, 384)]
```

And here we face the same problem again. We can see this occur in the individual coordinates as well, take for example the first few:

```
a: (1216, 512) b: (1216, 640)
a: (1152, 512) b: (1216, 640)
a: (1088, 512) b: (1216, 640)
a: (1024, 512) b: (1216, 640)
```

Yes, a is smaller than all of the provided b’s. But the last a is closer to the origin than the first a and as such is supposed to be sorted first.

And this is where I keep hitting a wall for now. And in which I am actually wondering whether this approach is actually viable, I am just overlooking something right now. So if you or anyone else has any further suggestions, please let me know.

Fornix | 2019-01-03 10:52