|
|
|
|
Reply From: |
kidscancode |
You can get the same functionality with move()
(2D) or move_and_collide()
(3D) by using the vector from your current position to your desired position:
move(destination - position)
If this was an improvement, was a very bad improvement. I hope somebody put it back.
Has anyone given an explanation for this change?
I’d tend to agree. While maybe redundant, a move_to is just way more readable than a move(A - B).
Edit: I mean redundant in the sense that the same thing can be achieved with move(). Not really talking about performance.
TheSHEEEP | 2017-09-11 09:01
Not redundant, is less scripting code and more performant, with move_to()
there is one call to the API, with move() you need to call get_position and do an aritmetic, there is x3 overhead in scripting system. And all we knows that scripting system is not fast. I hope that this is something to reimplement. If not implemented in 3.0 stable, i will open a issue to discussion.
Why wait? If you think the method should be there, open an issue now.
Also, do you have a reference for that “x3 overhead in scripting system” statement? Is this a real number?
kidscancode | 2017-09-11 15:33
Real number probably , but if you need access to members it can be worst than 3x slow, in godotdevelopers there is a battery of gdscript test in this post: https://godotdevelopers.org/forum/discussion/18435/bunny-mark-performance
Check that. Get_pos is slow that float addition,
In Gdscript most of the basic operation (ej: sum) have the same performance, API calls is worst, Vector 2 direct addition is equaly that float adition, if is needed access Vector2 members it can be x8 slow that direct Vector2 addition. Using directly move() have this implication: 1 API call (move), 1 API call (get_pos
), 1 Substraction (Vector2 - Vector2). 3x slow is probably the result compared to move_to()
.
All of this is not invention. The script to test is in the referenced post.
Edit: (Of course there will be ways to do the operation more performant, sharing “position” with other methods that doesn´t need to modificate that, etc…, but i think that is nearly imposible that move() with an internal aritmetic can execute at 1/2 of the velocity of move_to unless the method in c ++ does some kind of jedi trick.)
Edit: I change my mind, i will open an issue now.
Return move_to method to KinematicBody2D in Godot 3.0 · Issue #11184 · godotengine/godot · GitHub