Fixed typos (#1906)

getting_started/scripting/gdscript/static_typing.rst

@@ -146,8 +146,8 @@ into a constant:
 Variable casting
 ~~~~~~~~~~~~~~~~
 
-Type casting is a key concept in typed languages. We call the conversion
-of a value from from one type of another casting.
+Type casting is a key concept in typed languages.
+Casting is the conversion of a value from one type to another.
 
 Imagine an Enemy in your game, that ``extends Area2D``. You want it to
 collide with the Player, a ``KinematicBody2D`` with a script called
@@ -191,7 +191,7 @@ This happens when you get a child node. Let’s take a timer for example:
 with dynamic code, you can get the node with ``$Timer``. GDScript
 supports `duck-typing <https://stackoverflow.com/a/4205163/8125343>`__,
 so even if your timer is of type ``Timer``, it is also a ``Node`` and an
-``Object``, two classes it extends. With dynamic GDScript, you also also
+``Object``, two classes it extends. With dynamic GDScript, you also
 don’t care about the node’s type as long as it has the methods you need
 to call.
 

getting_started/step_by_step/resources.rst

@@ -8,7 +8,7 @@ Nodes and resources
 
 Up to this tutorial, we focused on the :ref:`Node <class_Node>`
 class in Godot as that's the one you use to code behavior and
-and most of the engine's features rely on them. There is
+most of the engine's features rely on them. There is
 another datatype that is just as important:
 :ref:`Resource <class_Resource>`.
 

tutorials/viewports/custom_postprocessing.rst

@@ -123,7 +123,7 @@ the tree.
     You can also render your Viewports separately without nesting them like this. You just
     need to use two Viewports and to render them one after the other.
 
-Besides the node structure, the steps are the the same as with the single-pass post-processing shader.
+Besides the node structure, the steps are the same as with the single-pass post-processing shader.
 
 As an example, you could write a full screen Gaussian blur effect by attaching the following pieces of code
 to each of the :ref:`ViewportContainers <class_ViewportContainer>`. The order in which you apply the shaders

tutorials/viewports/multiple_resolutions.rst

@@ -146,7 +146,7 @@ to the region outside the blue frame you see in the 2D editor.
    .. image:: img/stretch_viewport_keep_width.gif
 
 -  Stretch Aspect = **Keep Height**: Keep aspect ratio when stretching
-   the screen. If the the screen is taller than the base size, black
+   the screen. If the screen is taller than the base size, black
    bars are added at the top and bottom (letterboxing). But if the
    screen is wider than the base resolution, the viewport will be grown
    in the horizontal direction (and more content will be visible to the

tutorials/viewports/using_viewport_as_texture.rst

@@ -91,7 +91,7 @@ Your sphere should now be colored in with the colors we rendered to the Viewport
 
 .. image:: img/planet_seam.png
 
-Notice the ugly seam that forms where the texture texture wraps around? This is because we are picking 
+Notice the ugly seam that forms where the texture wraps around? This is because we are picking
 a color based on UV coordinates and UV coordinates do not wrap around the texture. This is a classic 
 problem in 2D map projection. Gamedevs often have a 2-dimensional map they want to project 
 onto a sphere but when it wraps around it has large seams. There is an elegant work around for this 
@@ -102,7 +102,7 @@ Making the planet texture
 
 So now when we render to our :ref:`Viewport <class_Viewport>` it appears magically on the sphere. But there is an ugly
 seam created by our texture coordinates. So how do we get a range of coordinates that wrap around 
-the sphere in a nice way? One solution is to to use a function that repeats on the domain of our texture.
+the sphere in a nice way? One solution is to use a function that repeats on the domain of our texture.
 ``sin`` and ``cos`` are two such functions. Lets apply them to the texture and see what happens
 
 ::