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.
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.
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.
Using bevy
Using bevy can be interesting by isolating each example to their own plugin.