bevy_crossterm icon indicating copy to clipboard operation
bevy_crossterm copied to clipboard

Updated to work with bevy 0.5, Help wanted

Open Nukeuler123 opened this issue 4 years ago • 7 comments

Wanted to use this with bevy 0.5, so i updated it into a state that at least allows compiling. Gonna need help fixing the examples and cleaning up my code.

Nukeuler123 avatar May 12 '21 21:05 Nukeuler123

I'll try and get this done today! Thank you for the PR.

octotep avatar May 28 '21 17:05 octotep

Everything compiles! But there's one quirk with the new Bevy I haven't worked out yet. Since multiple state updates can happen in a single frame, when you press a key once in the demo, it then immediately powers through all the states one after another since the event queue never has a chance to empty between states. Interesting dilemma, I'll ask on the bevy discord to see if there's a nice way to circumvent this problem without adding some gross extra states and hacky systems that do nothing for one frame

octotep avatar May 28 '21 20:05 octotep

Hi! what's the state of this PR? Is there any solution to the mentioned problem?

lemunozm avatar Jun 23 '21 13:06 lemunozm

Great question! I apologize for not getting back to you earlier but I've been doing a lot of travel lately and not had time to sit down and work on this problem. I asked around the bevy discord, but didn't have any luck. I feel that I'm gonna have to sit down with a debugger one of these days and step through the whole stack to see what part of the new bevy I'm not understanding correctly and fix the code.

octotep avatar Jul 24 '21 04:07 octotep

Hi! I investigated this a bit. It seems the issue is exactly what you mentioned, transitioning from one state to another never empties the EventReader.

From this page of the cheatbook :

You can do arbitrarily many state transitions in a single frame update. Bevy will handle all of them and execute all the relevant systems (before moving on to the next stage).

This is a cool feature that admittedly turns out to be annoying in this particular case. Now, it doesn't seem that the problem is on bevy's side, neither is it on the plugin's side, but rather on the demo code.

It does seem that given the design of bevy (which does not allow to specify a behaviour for the same stage when changing states), the solution is indeed to add an extra piece of state (a flag to skip the run of just_wait_and_advance that then needs to be reset), and to fix the demo that way.

Would you like me to do a commit that fixes the demo ? That would allow merging this branch and releasing the new version that is compatible with bevy 0.5.

AlisCode avatar Nov 12 '21 23:11 AlisCode

Yeah! I would love a commit that fixes the demo. I appreciate you looking into this further

octotep avatar Nov 15 '21 23:11 octotep

I looked at this. I think it's a one liner...

https://github.com/brianbruggeman/bevy_crossterm/blob/trunk/examples/demo/main.rs#L111

That said, when the one-liner is added, I no longer see a correct transition. Artifacts from the previous pipeline stages are not despawning correctly (from what I can tell) and as a result, subsequent stage entities will spawn on top of previous stage entities. Visually, it's a mess.

I tried a few different things to a) clear the screen just using a simple stdout clear call from crossterm and b) modifying the despawn logic to attempt to remove entities. However, I was unsuccessful.

brianbruggeman avatar Dec 02 '21 13:12 brianbruggeman