Merge pull request #497 from AndreaCatania/pp

Renamed fixed_process to physics_process

learning/features/audio/audio_streams.rst

@@ -81,4 +81,4 @@ Both have this property, which must be enabled manually:
 
 .. image:: /img/audio_stream_doppler.png
 
-Simply enable it by setting it depending on how objects will be moved (whether on regular *process* or *fixed_process* step) and the tracking will happen automatically!
+Simply enable it by setting it depending on how objects will be moved (whether on regular *process* or *physics_process* step) and the tracking will happen automatically!

learning/features/misc/pausing_games.rst

@@ -30,7 +30,7 @@ with a "true" argument:
 Doing so will have the following behavior:
 
 -  2D and 3D physics will be stopped.
--  _process and _fixed_process will not be called anymore in nodes.
+-  _process and _physics_process will not be called anymore in nodes.
 -  _input and _input_event will not be called anymore either.
 
 This effectively stops the whole game. Calling this function from a

learning/features/physics/kinematic_character_2d.rst

@@ -48,7 +48,8 @@ Fixed process
 ~~~~~~~~~~~~~
 
 To manage the logic of a kinematic body or character, it is always
-advised to use fixed process, which is called the same amount of times
+advised to use physics process, because it's called before physics step and its execution is
+in sync with physics server, also it is called the same amount of times
 per second, always. This makes physics and motion calculation work in a
 more predictable way than using regular process, which might have spikes
 or lose precision if the frame rate is too high or too low.
@@ -57,11 +58,11 @@ or lose precision if the frame rate is too high or too low.
 
     extends KinematicBody2D
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         pass
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 Scene setup
 ~~~~~~~~~~~
@@ -109,11 +110,11 @@ So, let's move our sprite downwards until it hits the floor:
 
     extends KinematicBody2D
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         move( Vector2(0,1) ) #move down 1 pixel per physics frame
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 The result is that the character will move, but stop right when
 hitting the floor. Pretty cool, huh?
@@ -128,15 +129,15 @@ little more like an actual game character:
     const GRAVITY = 200.0
     var velocity = Vector2()
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
 
         velocity.y += delta * GRAVITY
 
         var motion = velocity * delta
-        move( motion )  
+        move( motion )
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 Now the character falls smoothly. Let's make it walk to the sides, left
 and right when touching the directional keys. Remember that the values
@@ -153,7 +154,7 @@ This adds simple walking support by pressing left and right:
 
     var velocity = Vector2()
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
 
         velocity.y += delta * GRAVITY
 
@@ -165,10 +166,10 @@ This adds simple walking support by pressing left and right:
             velocity.x = 0
 
         var motion = velocity * delta
-        move(motion)  
+        move(motion)
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 And give it a try.
 
@@ -214,7 +215,7 @@ this way:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
 
         velocity.y += delta * GRAVITY
         if (Input.is_action_pressed("ui_left")):
@@ -225,17 +226,17 @@ this way:
             velocity.x = 0
 
         var motion = velocity * delta
-        motion = move(motion) 
+        motion = move(motion)
 
         if (is_colliding()):
             var n = get_collision_normal()
-            motion = n.slide(motion) 
+            motion = n.slide(motion)
             velocity = n.slide(velocity)
             move(motion)
 
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 Note that not only the motion has been modified but also the velocity.
 This makes sense as it helps keep the new direction too.

learning/features/physics/physics_introduction.rst

@@ -62,7 +62,7 @@ Transforming shapes
 
 As seen before in the collide functions, 2D shapes in Godot can be
 transformed by using a regular :ref:`Transform2D <class_Transform2D>`
-transform, meaning the functions can check for collisions while the 
+transform, meaning the functions can check for collisions while the
 shapes are scaled, moved and
 rotated. The only limitation to this is that shapes with curved sections
 (such as circle and capsule) can only be scaled uniformly. This means
@@ -239,7 +239,7 @@ They have two main uses:
 
 -  **Simulated Motion**: When these bodies are moved manually, either
    from code or from an :ref:`AnimationPlayer <class_AnimationPlayer>`
-   (with process mode set to fixed!), the physics will automatically
+   (with process mode set to physics!), the physics will automatically
    compute an estimate of their linear and angular velocity. This makes
    them very useful for moving platforms or other
    AnimationPlayer-controlled objects (like a door, a bridge that opens,
@@ -269,8 +269,8 @@ by the simulation from a position, linear velocity and angular velocity.
 As a result, [STRIKEOUT:this node can't be scaled]. Scaling the children
 nodes should work fine though.
 
-A RigidBody2D has a ``Mode`` flag to change its behavior (something 
-which is very common in games). It can behave like a rigid body, 
+A RigidBody2D has a ``Mode`` flag to change its behavior (something
+which is very common in games). It can behave like a rigid body,
 a character (a rigid body without the ability to rotate so that it is
 always upright), a kinematic body or a static body. This flag can be
 changed dynamically according to the current situation. For example,
@@ -294,13 +294,13 @@ object's parameters.  Since physics may run in its own thread, parameter
 changes outside that callback will not take place until the next frame.
 
 .. note::
-    
-    When a RigidBody goes to sleep then the :ref:`_integrate_forces() <class_RigidBody2D__integrate_forces>` 
-    method will not be called (I.E. they act like a static body until a 
-    collision or a force is applied to them). To override this behavior you will 
-    need to keep the rigid body "awake" by creating a collision, applying a force to it 
-    (e.g. :ref:`set_linear_velocity <class_RigidBody2D_set_linear_velocity>`) 
-    or by disabling the `can_sleep` property (see :ref:`set_can_sleep <class_RigidBody2D_set_can_sleep>`). 
+
+    When a RigidBody goes to sleep then the :ref:`_integrate_forces() <class_RigidBody2D__integrate_forces>`
+    method will not be called (I.E. they act like a static body until a
+    collision or a force is applied to them). To override this behavior you will
+    need to keep the rigid body "awake" by creating a collision, applying a force to it
+    (e.g. :ref:`set_linear_velocity <class_RigidBody2D_set_linear_velocity>`)
+    or by disabling the `can_sleep` property (see :ref:`set_can_sleep <class_RigidBody2D_set_can_sleep>`).
     Be aware that this can have an effect on performance.
 
 Contact reporting
@@ -404,23 +404,24 @@ it can use up to a full frame to process physics. Because of this, when
 accessing physics variables such as position, linear velocity, etc. they
 might not be representative of what is going on in the current frame.
 
-To solve this, Godot has a fixed process callback, which is like process
-but it's called once per physics frame (by default 60 times per second).
+To solve this, Godot has a physics process callback, which is like process
+but it's called before each physics step always at the same frame rate
+(by default 60 times per second).
 During this time, the physics engine is in *synchronization* state and
 can be accessed directly and without delays.
 
-To enable a fixed process callback, use the ``set_fixed_process()``
+To enable a physics process callback, use the ``set_physics_process()``
 function, example:
 
 ::
 
     extends KinematicBody2D
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         move(direction * delta)
 
     func _ready():
-        set_fixed_process(true)
+        set_physics_process(true)
 
 Casting rays and motion queries
 -------------------------------
@@ -435,7 +436,7 @@ server must be used directly. For this, the
 :ref:`Physics2DDirectspaceState <class_Physics2DDirectspaceState>`
 class must be used. To obtain it, the following steps must be taken:
 
-1. It must be used inside the ``_fixed_process()`` callback, or at
+1. It must be used inside the ``_physics_process()`` callback, or at
    ``_integrate_forces()``
 
 2. The 2D RIDs for the space and physics server must be obtained.
@@ -444,7 +445,7 @@ The following code should work:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space = get_world_2d().get_space()
         var space_state = Physics2DServer.space_get_direct_state(space)
 

learning/features/physics/ray-casting.rst

@@ -40,7 +40,7 @@ Accessing space
 Godot physics runs by default in the same thread as game logic, but may
 be set to run on a separate thread to work more efficiently. Due to
 this, the only time accessing space is safe is during the
-:ref:`Node._fixed_process() <class_Node__fixed_process>`
+:ref:`Node._physics_process() <class_Node__physics_process>`
 callback. Accessing it from outside this function may result in an error
 due to space being *locked*.
 
@@ -53,7 +53,7 @@ In code, for 2D spacestate, this code must be used:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space_rid = get_world_2d().get_space()
         var space_state = Physics2DServer.space_get_direct_state(space_rid)
 
@@ -61,14 +61,14 @@ Of course, there is a simpler shortcut:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space_state = get_world_2d().get_direct_space_state()
 
 For 3D:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space_state = get_world().get_direct_space_state()
 
 Raycast query
@@ -80,7 +80,7 @@ must be used, for example:
 
 ::
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space_state = get_world().get_direct_space_state()
         # use global coordinates, not local to node
         var result = space_state.intersect_ray( Vector2(0,0), Vector2(50,100) )
@@ -129,7 +129,7 @@ collisionobject based node:
 
     extends KinematicBody2D
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         var space_state = get_world().get_direct_space_state()
         var result = space_state.intersect_ray( get_global_pos(), enemy_pos, [ self ] )
 
@@ -166,4 +166,4 @@ To obtain it using a camera, the following code can be used:
               var to = from + camera.project_ray_normal(ev.position) * ray_length
 
 Of course, remember that during ``_input()``, space may be locked, so save
-your query for ``_fixed_process()``.
+your query for ``_physics_process()``.

learning/scripting/gdscript/gdscript_basics.rst

@@ -597,7 +597,7 @@ pass it to another function as an argument) one must use the ``call`` or
 
 Remember that default functions like  ``_init``, and most
 notifications such as ``_enter_tree``, ``_exit_tree``, ``_process``,
-``_fixed_process``, etc. are called in all base classes automatically.
+``_physics_process``, etc. are called in all base classes automatically.
 So there is only a need to call the function explicitly when overloading
 them in some way.
 

learning/step_by_step/scripting_continued.rst

@@ -11,7 +11,7 @@ functions, so there is no need to check for writing code that runs all
 the time. Additionally, a lot can be done with animation players.
 
 However, it is still a very common case to have a script process on every
-frame. There are two types of processing: idle processing and fixed
+frame. There are two types of processing: idle processing and physics
 processing.
 
 Idle processing is activated automatically when the method :ref:`Node._process() <class_Node__process>`
@@ -29,9 +29,13 @@ frames per second (FPS) of the application:
 The delta parameter describes the time elapsed (in seconds, as
 floating point) since the previous call to "_process()".
 
-Fixed processing is similar, but only needed for synchronization with
-the physics engine. It is called a fixed amount of times per second
-(defined in the Project Settings, but 60 by default).
+Physics processing is similar, but it should be used for all the processes that
+must happen before each physics step. For example, to move a character.
+It is always runs before a physics step and it is called at fixed time intervals,
+60 times per second by default. Change the value in the Project Settings.
+
+The function _process() instead is not sync with physics, and its frame rate is not constant and depend by hardware and game optimization.
+Its execution is done after physics step on single thread games.
 
 A simple way to test this is to create a scene with a single Label node,
 with the following script:
@@ -104,7 +108,7 @@ function in your script:
     func _notification(what):
         if (what == NOTIFICATION_READY):
             print("This is the same as overriding _ready()...")
-        elif (what == NOTIFICATION_PROCESS):     
+        elif (what == NOTIFICATION_PROCESS):
             var delta = get_process_time()
             print("This is the same as overriding _process()...")
 
@@ -121,21 +125,21 @@ follows:
 ::
 
     func _enter_tree():
-        # When the node enters the _Scene Tree_, it becomes active 
-        # and  this function is called. Children nodes have not entered 
-        # the active scene yet. In general, it's better to use _ready() 
+        # When the node enters the _Scene Tree_, it becomes active
+        # and  this function is called. Children nodes have not entered
+        # the active scene yet. In general, it's better to use _ready()
         # for most cases.
         pass
 
     func _ready():
-        # This function is called after _enter_tree, but it ensures 
-        # that all children nodes have also entered the _Scene Tree_, 
+        # This function is called after _enter_tree, but it ensures
+        # that all children nodes have also entered the _Scene Tree_,
         # and became active.
-        pass 
+        pass
 
     func _exit_tree():
-        # When the node exits the _Scene Tree_, this function is called. 
-        # Children nodes have all exited the _Scene Tree_ at this point 
+        # When the node exits the _Scene Tree_, this function is called.
+        # Children nodes have all exited the _Scene Tree_ at this point
         # and all became inactive.
         pass
 
@@ -143,12 +147,12 @@ follows:
         # This function is called every frame.
         pass
 
-    func _fixed_process(delta):
+    func _physics_process(delta):
         # This is called every physics frame.
         pass
 
     func _paused():
-        # Called when game is paused. After this call, the node will not receive 
+        # Called when game is paused. After this call, the node will not receive
         # any more process callbacks.
         pass