Completely overhaul Arcade's physics engines, and physics engine dependencies.

[DragonMoffon]

Arcade has not had proper physics engines since its inception.

The built-in pure python implementations served their purpose in the past, but as arcade becomes more complex and used by more people they will quickly be out paced. They have several flaws that wreck their performance and go against modern physics engine design.

Pymunk was partially the solution to this, but it has binaries that limit's arcade's range of support. There has already been work done to make this optional, and in the next few updates should hopefully be fully separated.

Currently in Arcade sprites always have a hitbox which is either tied to the 'first' texture they are given or set manually. This is a huge waste as most sprites don't need a hitbox, and forces users to use sprite lists for collision checking which is a confusing and inconvenient.

I propose we provide 2-3 types of physics engine.

1st is a rotation less 'simple' engine that's perfect for platformers and top-down games like celeste, super meat boy, or civ where the physics is for movement and collisions rather than anything dynamic.
2nd is a classic 2D rigidbody and softbody engine (might need to be two systems depending on how performance is)
3rd are optional bindings to various high performance 2d libraries with an abstraction layer to fit arcade's physics paradigm. This obviously includes Pymunk, but I'm also interested in getting Box2D bindings working for more options.

[eschan145]

but I'm also interested in getting Box2D bindings working for more options.

I wouldn't recommend Box2D since none of its Python bindings are actively maintained, and the 3.0 release rewrote the engine in C, making future updates to those bindings very unlikely. I would suggest a physics engine built using compute shaders in glsl. I'm not sure if this is feasible because it would be very hard to develop, but it's just an idea.

[DragonMoffon]

Ah, good point. That's unfortunate news, but there are other options.

Yeah, we could definitely try to go down that route, but I'd like some cpu side stuff first for feature parity.