![]() ![]() The Node2d will then flip if it is facing the opposite direction of the parameter. Then, when needed, just call: set_direction(DIRECTION_LEFT) Var hor_dir_mod = hor_direction / abs(hor_direction) # get unit directionĪpply_scale(Vector2(hor_dir_mod * direction.x, 1)) # flipĭirection = Vector2(hor_dir_mod, direction.y) # update direction Hor_direction = DIRECTION_RIGHT # default to right if param is 0 Var direction = Vector2(DIRECTION_RIGHT, 1) Here is how I have horizontal flipping set up for my platform game: const DIRECTION_RIGHT = 1 You can accomplish flipping an entire Node2d and all its children through use of apply_scale. Hopefully this will eventually be fixed so that we don't need this workaround anymore.I want to provide an answer for Godot 3 users who are stumbling upon this page in 2018, like I did: This still seems like something Camera2D should be doing internally by default though, as I can't imagine the current behavior ever being desirable. This completely fixes the issue for all sprites without having to do anything specific in each sprite, while still having a nice smooth camera. It's a combination of Seel's (on Github) suggestion with a custom reimplementation of camera smoothing based on one I created in a MonoGame-based engine years ago. I put this in a script on the camera node: extends Camera2DĬurrent_position += Vector2(destination_position.x - current_position.x, destination_position.y - current_position.y) / SMOOTHING_DURATION * delta I also tried throwing in a Label (text) to see if that was affected as well, as that seems to use some of the same rendering code as sprites, and interestingly it does not seem to jitter, but I've been unable to figure out why.Īfter some discussion and suggestions in the Github issue, this is the solution I arrived at. ![]() I tried poking around in Godot's source code related to sprite rendering, but so far I haven't been able to pin down exactly where it's coming from. I tried watching the edge of the screen to see if the tilemap was jittering, and as far as I can tell it isn't - just the sprite. It's a very strange issue, and it seems to specifically affect sprites, but not the tilemap. I've tried to monitor both the player and sprite's positions and check to make sure they aren't actually somehow getting set to a lower value, and as far as I can tell, they aren't. Position = position.snapped(Vector2.ONE) in Sprite's various update functions. It is.Įnabling "Vsync via compositor" (in version built from Github master branch) - does not fix. HTML5 export to see if the issue is present in browser as well. I don't know what the root cause of it is, but my guess would be that it's caused by some sort of inconsistent rounding of pixel coordinates during rendering.Īnyone know if there is a way to get rid of this "jittering"? It looks a bit different in the Vulkan branch, due to what I assume is some sort of smoothing/blur filter being applied (there may be a way to turn that off, but I couldn't find it) to the background, but it is definitely still there. In case it was a bug that had already been fixed, I tried compiling Godot myself from both the master (presumably what will become 3.2) and vulkan (4.0?) branches to try them out, but unfortunately the problem still seems to be present in both of those. I asked about it in the #beginner-help channel in Discord, but got no reply, so I figured I'd try here as well. I imagine in a game with higher resolution art it would also be less noticeable, or in cases where the background scrolls at a different speed from the foreground sprites. It's also present with camera smoothing turned off, just harder to notice. Generally, from what I've found, it's most noticeable if you have camera smoothing turned on and the smoothing speed set to a very low value, but the problem isn't related to the camera smoothing. How noticeable it is depends on circumstances. ![]() It seems like any time the camera moves, there is some sort of inconsistency in the positions sprites are being rendered at, causing them to "jitter" back and forth by one pixel even though the camera is only moving in one direction. ![]() After a bit of testing, I've found out what it is. Pretty much as soon as I made my test level larger than a single screen, I noticed something was off. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |