An issue with web builds

[sokorototo]

macroquad has custom environment code for Web builds, while Bevy uses wasm-bindgen. You'll have to load both the macroquad and the wasm-bindgen glue JS code for Web builds. There's a lot of overlap and I am not quite sure it would work. This means that the code needs to take care hooking into certain platform-dependent Bevy features, like logging and time management.

See here

[StepanTheGreat]

Thanks for reporting, I honestly as well have no idea what would be the right approach. miniquad is simply too manual, so I'm sure it will not only affect web builds, but iOS or Android as well.

My radical option right now is cloning and making changes to the miniquad crate, so it can use wasm-bindgen for its wasm glue code instead. This way we can at least use existing plugins like bevy_window or the ones you mentioned. It will also mean that this crate has to either reinvent all macroquad's wheels like sprite batching, or use the local macroquad copy that uses the local miniquad version instead (mentioning this because currently it's useful to have some starting point functionality from macroquad. Reinventing everything again will take some time).

It's a really important fundamental problem, so thank you for showing it. Quite silly that I didn't see it at first, lol. Let me know what you think though, maybe there's a better way.

[sokorototo]

I get the appeal of how the quad crates do things, manually and minimally. Bevy does things more aligned with the larger Rust ecosystem. If we are writing a bevy_app wrapper for macroquad it's best to take Bevy's approach, and fork macroquad to use wasm_bindgen. One small thing is that now our fork will need constant maintenance. If we instead reimplement most of macroquad in bevy_ecs and only use miniquad as a backend, the only part we get to maintain into the future is our wrapper. The second approach is a lot of work initially, but the wrapper can stand for itself better in the future and we are afforded more flexibility. Besides, we have macroquad as a reference. The second approach is what I vote for; Since then we can express miniquad correctly in bevy_ecs, for example having windows be a resource instead of a Component since miniquad only really works with one window. We'll have to learn to use sapp_jsutils and other quad helper crates too

[StepanTheGreat]

I absolutely agree, and the example with windows as entities is indeed bizarre with miniquad. I guess I initially wanted this crate to be a "drop-in" replacement, but I think it's a bit silly and too much. And besides, yes, it's really difficult to merge two different ecosystems like in this case with wasm_bindgen. I as well think this crate should more represent macroquad than bevy.

One thing I think I misunderstood from your message is, are you proposing to avoid bevy_app at all? Because I think having this crate as a plugin is quite comfortable for both users and developers.

In any other case, I fully agree with this, I think merging two different ecosystems loses the whole point of miniquad's minimalism, and this crate should focus more on re implementing macroquad with bevy_ecs, than reimplementing bevy with macroquad.

[sokorototo]

bevy_app is quite amazing, we can't miss out on the Schedules and free multithreading

[sokorototo]

Do we start the conversion asap or is there anything left to discuss?

[StepanTheGreat]

Sure, though I guess I need to remove my previous basic code 🥲

[sokorototo]

Sure thing, I already have a fork on. I will try and see what I can do o'er there

[StepanTheGreat]

So, I created a new branch overhaul, where we can push all changes before overhauling the main branch (and render). I've commited some bare minimum rendering interface there as well.

[sokorototo]

So, I created a new branch overhaul, where we can push all changes before overhauling the main branch (and render). I've commited some bare minimum rendering interface there as well.

I'm updating my fork :)

[sokorototo]

Closing this in favour of: #3