Tracking issue for Infrastructural Changes

[sokorototo]

• [x] Correct integration with bevy_app, ensuring that most miniquad logic stays on the main thread. Using NonSendResources where necessary.
• [x] Logging facade, similar to macroquad 's warn, log, info, debug and trace.
• [x] Input Handling; keyboard events, dropped file events, read clipboard, mouse and touch events. Rather than a declarative API.
• [ ] Rendering; Enable user-defined shaders with ECS abstraction, basic ECS shapes and mesh abstraction like macroquad::shapes, Camera abstraction like macroquad::Camera2D, ClearBackground and RenderTargets eg...
• [x] Configuration; Implement a 1:1 Configuration struct with Conf, user friendly abstraction over Icon, expose Platform but user should use at their own risk.
• [x] Window Management: Update Window resource (can't update window title using miniquad to my best knowledge), user code emitting for OrderQuit, RequestQuit and CancelQuit. set_cursor_grab
• [x] Create newtypes for miniquad structures compatible with bevy_ecs. For example:

  
  use miniquad::KeyMods;
  use bevy_ecs::Component;

[derive(Component)]

pub struct KeyModifiers(pub KeyMods)

- [ ] Asset Management; Write our own `AssetServer`, `Assets` and `Handle`. Or we use an external crate

[StepanTheGreat]

I think everything is perfect, though is KeyModifiers supposed to be an example, or an actual component? And if so, why?

My last question is what to do with say math; Should we use bevy_math for graphics and everything, or do we create something of our own? (though both macroquad and bevy use glam for math, so I guess we can keep bevy_math)

[StepanTheGreat]

Also, do you mind me adding you as a collaborator? From your fork changes you look way more experienced than me, lol. I think this will simplify the workflow

[sokorototo]

Also, do you mind me adding you as a collaborator? From your fork changes you look way more experienced than me, lol. I think this will simplify the workflow

I wanted to ask you to add me :) Sure add me, I have written a lot of Rust, but I'm not quite in tune with Bevy's internals

[StepanTheGreat]

Sure, adding... I'm new to bevy internals as well, started learning after making this plugin (because bevy compile times are insufferable)

[sokorototo]

BTW you can enable dynamic linking for Bevy, using the dynamic feature. For me, it's not the compile times, I just have a thing for minimalism

[StepanTheGreat]

Yeah, it does speed up recompiles, but in my case, I have a workspace of 3 projects and my OS isn't even able to operate normally because of the amount of RAM taken (it's of course not a common issue, but the one I'm facing). Also I don't like bevy's huge binary size; for me the only reason I chose bevy is its fantastic ECS.

Back to the topic I suppose, do you mind pushing directly to the original repo's overhaul branch? So for example I can easily see your pushed commits. Furthermore, I'm removing the render branch because right now it's useless.

[sokorototo]

Sure let me try making a push right now

[sokorototo]

@StepanTheGreat bevy_app has a hard dependency on #[wasm_bindgen], meaning it's fundamentally incomaptible with sapp-jsutils. Either we scrap bevy_app (Losing Plugin support) or port miniquad to #[wasm_bindgen]. I prefer scrapping bevy_app. The other alternative is ditching the Web, which I am strongly against

[StepanTheGreat]

No way. Actually, I had a suspicion that say bevy's threading is wasm_bindgen dependent, but bevy_app as well?!? Is at least bevy_ecs itself independent from wasm_bindgen...? Answering your question - sure.

[StepanTheGreat]

Actually, yes, I think it does depend, because bevy_ecs depends on bevy_tasks, which itself depends on wasm_bindgen on wasm. So I'm guessing we either have to scrap absolutely everything, or adapt miniquad to wasm_bindgen... If we do scrap bevy - this crate loses its main purpose (Ig). In extreme case we might need to take another ECS library, and reinvent bevy's ECS main features like Resources, Events, Schedules and so on.

Maybe porting miniquad to wasm_bindgen at this point is not that extreme?

[sokorototo]

I am experimenting with a miniquad port. It's not as hard as I thought, but I'd be damned if this codebase isn't arkane 😵

[StepanTheGreat]

Sorry if a bit irrelevant, but do you have any platform where we can discuss this issue more freely?

[sokorototo]

Social Platform? Yeah, several. But shouldn't we keep discussions here?

[StepanTheGreat]

We should, but I think this will be instead for minor organizational questions that are too slow in github issues. Do you have a discord account? And if so, how about a little discord server where this all can be discussed?

[sokorototo]

I think a server is overkill, maybe a small discussion?

[StepanTheGreat]

A discussion in discord or here (github, like on bevy's repo)? If in discord, I'm proposing a temporary server link where we can then start a conversation, or we can create something simple here?

[sokorototo]

We can use a simple discord conversation, or have the conversation in the Rust Gamedev server

[sokorototo]

My Discord username is: sokorototo

Also, the miniquad wasm backend was very patchy, I am kinda happy I got to take a look at it and improve it a lot!

[sokorototo]

@StepanTheGreat so far the conversion is going great, I have converted everything except for the WebGL bindings, which are a mountain of unsafe code 💀