#How do I avoid a 1-frame delay between cursor and something moving with cursor?
47 messages · Page 1 of 1 (latest)
I think this should mostly be a matter of figuring out when input polling happens and queueing your movement system right after
But you also need the constraint that this should still happen before rendering
I had assumed input polling would happen before the main stage
or the update stage or whatever
but maybe rendering happens in postupdate, I am moving my mesh there currently 🤔
Maybe I should just make my own stage
OK that changed nothing
Have you checked that it does? Not to sound pedantic but I recently found Rapier polls on the Update stage. Which was unexpected to say the least.
I don't know how I would check
So if you're using the default plugins it's not that hard to track it down.
https://github.com/bevyengine/bevy/blob/main/crates/bevy_internal/src/default_plugins.rs#L37
https://github.com/bevyengine/bevy/blob/main/crates/bevy_input/src/lib.rs#L59
Think you meant this line https://github.com/bevyengine/bevy/blob/main/crates/bevy_input/src/lib.rs#L69
hmm
So it looks like all the input is handled in PreUpdate
Can you like... click through to things like in IDE
Are you not using Rust Analyser?
I mean can you do that in github?
Oh no... I just searched for it.
damn, would've been nice
Trying to do the same with the render plug-in is maybe not as enlightening
So how are you adding your movement code? Just adding a single system without specifying a stage?
Not specifying a stage explicitly means CoreStage::Update doesn't it?
Yeah exactly.
Everything is in CoreStage::Update, except my mesh change, which is in CoreStage::PostUpdate
but when I tried to add a stage in between the two, for the mesh change, it didn't change outcome noticeably
I am not sure rendering happens in any particular core stage
I forgot about this earlier, but rendering always runs essentially one frame later. see this section of the 0.6 release for more detail https://bevyengine.org/news/bevy-0-6/#pipelined-rendering-extract-prepare-queue-render
Could've sworn it was smooth just once, I remember taking note of it
In other words exactly one frame delay is inevitable, but if it's noticeable it probably means either low fps, something is wrong or you are unfortunately very sensitive to input delay
You might want to give https://github.com/aevyrie/bevy_framepace a try
I remember being surprised
Don't need to be very sensitive when using OS cursor to move in-game meshes
I'm in the process of making a game cursor there
which will hide the problem somewhat
I just know I've heard people talk about noticeable input delays in things where I personally didn't notice anything. So it's always hard for me to have an opinion on this.
Damn, HoN, haven't seen that name in a long time lol
pub fn cursor_mesh() -> Mesh {
let mut mesh = Mesh::new(PrimitiveTopology::TriangleList);
mesh.insert_vertices([Vec3::ZERO, Vec3::NEG_Y, Vec3::X]);
mesh.compute_flat_normals();
mesh
}
I was thinking how I would make a placeholder cursor mesh
trying to like... reason out the triangles it would consist of
then after one triangle I was like wait I can stop here