Parry testbed exploration

[ThierryBerger]

• based on https://github.com/dimforge/parry/pull/275

• makes common_macroquad its own crate, it's the best solution to be able to use it from another example + reduces some warnings naturally. I think this changes is for the best and I can set this up in a different PR if need be.

• explores solution for a parry testbed, we have quite a lot of options, and an "RFC" might be best before starting to work on that, but c3cd122e8c7b6fc10b642c144f6ecbc742af120d starts to explore a "minimum effort testbed".

Minimum effort testbed

Reuse code from examples as-is, with no modifications.

We can fork our process, have 1 controller and 1 demo ; the controller can kill the demo and spawn a new one.

• advantages:
  • no modification to existing examples :tada: ; that reduces a lot of cognitive load for the user.
  • simple to implement for native, not much code.
• disadvantages:
  • wasm compatibility is not totally trivial to make
  • result is 2 windows, which is arguably not as pretty as an integrated controller.

Modular macroquad

With minimal changes to the examples, we could make them expose a function to draw their own frame, and probably pass them their own state.

Reusing egui to have something comparable to rapier / bevy_rapier seems possible through https://github.com/optozorax/egui-macroquad ; but will likely need maintenance/updating efforts.

• advantages:
  • easier wasm integration (only 1 canvas needed)
  • comparable experience to other rapier ecosystems testbeds.
• disadvantages
  • small modifications to examples needed
  • maintaining a egui / testbed using another dependency than the rest of rapier ecosystem.

Using bevy

Using bevy can be interesting by isolating each example to their own plugin.

• advantages:
  • benefiting bevy ecosystem, easier to move camera, or use 3d features.
  • same dependencies as rapier testbed
• disadvantages
  • more complex examples ; see previous attempt: https://github.com/dimforge/parry/pull/219
  • longer compile times