I'm making a 2D turn-based game. Various Node2D objects move when a player action happens.
But when they move, they make physics-based checks. Since I want that move that the previous node made to affect the moves that are made by the nodes that go after, I have something like this:
for individual in individuals:
# We need to wait for the move to take effect so that the next
# collision calculations take it into account.
await get_tree().physics_frame
individual.do_thing_using_area2d()
This makes sure that physics updates happen so that the next physics check is valid. (e.g. if an individual just moved in front of the one that's about to move, a bump will happen.)
The problem with this is that Sprite2Ds are attached to the nodes being moved. So they get redrawn in separate frames and cause flickering.
To make all the sprites to update in one frame, I did this:
# Stop _process and draw calls, but keep physics going.
get_tree().paused = true
PhysicsServer2D.set_active(true)
Then after all of the individuals have moved and updated the physics objects, I unpause:
await get_tree().create_timer(0.1).timeout
# Unpause to get _process and _draw going again.
get_tree().paused = false
This works, but it kind of feels like Too Much and like there may be Consequences. Is there a cleaner and more conventional way to batch up Sprite2D updates?
The closest I can think to disabling redraw for a
Nodeis disabling automatic redraw for aViewport.So I'm not answering the question as stated...
Instead, this is what I'm thinking: you can set
top_leveltotrueon theNode2D, so it does not move with its parent (while still being in its position in the scene tree) and then you have to move it...For example, you could give it a script something like this:
Or save a few cycles like this:
Here I'm using
set_physics_processto enable or disable_physics_processdepending on the parent. Let us step it up with a configuration warning:Or you could use
_processwhich is how you can start writing your own physics interpolation.Addendum: The above approach for interpolation is a good frame rate independent damping. But it is not the best option for physics interpolation. You might be able to do better if you know the speed at which the Node should be moving.