Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent 2D render order when removing and adding child nodes #16213

Closed
DoctorAlpaca opened this issue Jan 30, 2018 · 2 comments · Fixed by #23564
Closed

Inconsistent 2D render order when removing and adding child nodes #16213

DoctorAlpaca opened this issue Jan 30, 2018 · 2 comments · Fixed by #23564
Assignees
Milestone

Comments

@DoctorAlpaca
Copy link
Contributor

Godot version:
3.0

OS/device including version:
Arch Linux

Issue description:
Removing the first child from a node and then adding another one results in the render order of all the child nodes to scramble around, but only when more than 16 child nodes are present.

Steps to reproduce:
Click the "Remove Child" button in the test project at least 8 times, removing and adding a sprite each time. Changing the "num_children" constant to something below 17 has no such behaviour.

Minimal reproduction project:
testing.zip

@ghost ghost added this to the 3.1 milestone Jan 31, 2018
@vnen
Copy link
Member

vnen commented Jan 31, 2018

Related to #14364.

@arccoza
Copy link

arccoza commented Feb 9, 2018

I've been experiencing the same problem. When removing nodes from any Node2D the
z-order of the remaining siblings shuffle around.
This doesn't happen with 2D nodes inside a Node parent.

Godot version:
Godot 3.0

OS/device including version:
Arch Linux
OpenGL ES 3.0 Renderer: Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)

Minimal reproduction project:
Example

@reduz reduz self-assigned this Sep 6, 2018
reduz pushed a commit that referenced this issue Nov 14, 2018
akien-mga pushed a commit to akien-mga/godot that referenced this issue Jul 3, 2019
Poobslag added a commit to Poobslag/turbofat that referenced this issue Jun 24, 2020
The frosting pool size of 800 seems large, but smaller sizes such as 500
ran out of blobs occasionally when making/clearing large amounts of
blocks. It performs OK on my Galaxy Note9.

Frosting occasionally flickers due to Godot #16213
godotengine/godot#16213

Minor changes to game ending logic.
Poobslag added a commit to Poobslag/turbofat that referenced this issue Jun 24, 2020
The frosting pool size of 800 seems large, but smaller sizes such as 500
ran out of blobs occasionally when making/clearing large amounts of
boxes. It performs OK on my Galaxy Note9.

Frosting occasionally flickers due to Godot #16213
godotengine/godot#16213

Minor changes to game ending logic.
Poobslag added a commit to Poobslag/turbofat that referenced this issue Jun 24, 2020
The frosting pool size of 800 seems large, but smaller sizes such as 500
ran out of blobs occasionally when making/clearing large amounts of
boxes. It performs OK on my Galaxy Note9.

Frosting occasionally flickers due to Godot #16213
godotengine/godot#16213

Minor changes to game ending logic.

Added null check for Scenario.launched_scenario_name to avoid errors when
running Puzzle.tscn standalone
Poobslag added a commit to Poobslag/turbofat that referenced this issue Jun 24, 2020
The frosting pool size of 800 seems large, but smaller sizes such as 500
ran out of blobs occasionally when making/clearing large amounts of
boxes. It performs OK on my Galaxy Note9.

Frosting occasionally flickers due to Godot #16213
godotengine/godot#16213

Minor changes to game ending logic.

Added null check for Scenario.launched_scenario_name to avoid errors when
running Puzzle.tscn standalone
Poobslag added a commit to Poobslag/turbofat that referenced this issue Jul 18, 2020
The frosting pool size of 800 seems large, but smaller sizes such as 500
ran out of blobs occasionally when making/clearing large amounts of
boxes. It performs OK on my Galaxy Note9.

Frosting occasionally flickers due to Godot #16213
godotengine/godot#16213

Minor changes to game ending logic.

Added null check for Scenario.launched_scenario_name to avoid errors when
running Puzzle.tscn standalone
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants