mirror of
https://github.com/stan220/godot-docs.git
synced 2026-09-08 21:29:07 +00:00
Proofing/review: Remove filler words, adhere to style guide
This commit is contained in:
@@ -109,7 +109,7 @@ due to the two directions being added together.
|
||||
We can prevent that if we *normalize* the velocity, which means we set
|
||||
its *length* to ``1``, and multiply by the desired speed.
|
||||
|
||||
.. tip:: If you've never used vector math before, or just need a refresher,
|
||||
.. tip:: If you've never used vector math before, or need a refresher,
|
||||
you can see an explanation of vector usage in Godot at :ref:`doc_vector_math`.
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ Again, pressing both keys at once will cancel out and result in no rotation.
|
||||
The rotation is applied directly to the body's ``rotation`` property.
|
||||
|
||||
To set the velocity, we use the ``Vector2.rotated()`` method so that it points
|
||||
in the same direction as the body. ``rotated()`` is a very useful vector function
|
||||
in the same direction as the body. ``rotated()`` is a useful vector function
|
||||
that you can use in many circumstances where you would otherwise need to apply
|
||||
trigonometric functions.
|
||||
|
||||
|
||||
@@ -192,11 +192,11 @@ Remember the number of points our shape has to be decomposed into? We fixed this
|
||||
|
||||
The next step consists of computing the actual positions of these 32 points that compose an arc. This is done in the first for-loop: we iterate over the number of points for which we want to compute the positions, plus one to include the last point. We first determine the angle of each point, between the starting and ending angles.
|
||||
|
||||
The reason why each angle is reduced by 90° is that we will compute 2D positions out of each angle using trigonometry (you know, cosine and sine stuff...). However, to be simple, cos() and sin() use radians, not degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to start counting at 0 o'clock. So, we just reduce each angle by 90° in order to start counting from 0 o'clock.
|
||||
The reason why each angle is reduced by 90° is that we will compute 2D positions out of each angle using trigonometry (you know, cosine and sine stuff...). However, to be simple, cos() and sin() use radians, not degrees. The angle of 0° (0 radian) starts at 3 o'clock, although we want to start counting at 0 o'clock. So we reduce each angle by 90° in order to start counting from 0 o'clock.
|
||||
|
||||
The actual position of a point located on a circle at angle 'angle' (in radians) is given by Vector2(cos(angle), sin(angle)). Since cos() and sin() return values between -1 and 1, the position is located on a circle of radius 1. To have this position on our support circle, which has a radius of 'radius', we simply need to multiply the position by 'radius'. Finally, we need to position our support circle at the 'center' position, which is performed by adding it to our Vector2 value. Finally, we insert the point in the PoolVector2Array which was previously defined.
|
||||
|
||||
Now, we need to actually draw our points. As you can imagine, we will not simply draw our 32 points: we need to draw everything that is between each of them. We could have computed every point ourselves using the previous method, and drew it one by one. But this is too complicated and inefficient (except if explicitly needed). So, we simply draw lines between each pair of points. Unless the radius of our support circle is very big, the length of each line between a pair of points will never be long enough to see them. If this happens, we simply would need to increase the number of points.
|
||||
Now, we need to actually draw our points. As you can imagine, we will not simply draw our 32 points: we need to draw everything that is between each of them. We could have computed every point ourselves using the previous method, and drew it one by one. But this is too complicated and inefficient (except if explicitly needed). So, we simply draw lines between each pair of points. Unless the radius of our support circle is big, the length of each line between a pair of points will never be long enough to see them. If this happens, we simply would need to increase the number of points.
|
||||
|
||||
Draw the arc on screen
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -273,7 +273,7 @@ We can take this a step further and not only write a function that draws the pla
|
||||
|
||||
Dynamic custom drawing
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
Alright, we are now able to draw custom stuff on screen. However, it is very static: let's make this shape turn around the center. The solution to do this is simply to change the angle_from and angle_to values over time. For our example, we will simply increment them by 50. This increment value has to remain constant, else the rotation speed will change accordingly.
|
||||
Alright, we are now able to draw custom stuff on screen. However, it is static: let's make this shape turn around the center. The solution to do this is simply to change the angle_from and angle_to values over time. For our example, we will simply increment them by 50. This increment value has to remain constant, else the rotation speed will change accordingly.
|
||||
|
||||
First, we have to make both angle_from and angle_to variables global at the top of our script. Also note that you can store them in other nodes and access them using get_node().
|
||||
|
||||
@@ -413,5 +413,5 @@ Drawing your own nodes might also be desired while running them in the
|
||||
editor, to use as preview or visualization of some feature or
|
||||
behavior.
|
||||
|
||||
Remember, to just use the "tool" keyword at the top of the script
|
||||
Remember to use the "tool" keyword at the top of the script
|
||||
(check the :ref:`doc_gdscript` reference if you forgot what this does).
|
||||
|
||||
@@ -76,7 +76,7 @@ Preprocess
|
||||
~~~~~~~~~~
|
||||
|
||||
Particle systems begin with zero particles emitted, then start emitting.
|
||||
This can be an inconvenience when just loading a scene and systems like
|
||||
This can be an inconvenience when loading a scene and systems like
|
||||
a torch, mist, etc. begin emitting the moment you enter. Preprocess is
|
||||
used to let the system process a given number of seconds before it is
|
||||
actually drawn the first time.
|
||||
|
||||
@@ -176,7 +176,7 @@ one that looks better for you:
|
||||
|
||||
- Disable filtering and mipmaps for either the tileset texture or all tile textures if using separate images (see the :ref:`doc_import_images` asset pipeline tutorial).
|
||||
- Enable pixel snap (Set ``Project > Project Settings >
|
||||
Rendering > Quality > 2d > Use Pixel Snap`` to true, you can also just search for ``Pixel Snap``).
|
||||
Rendering > Quality > 2d > Use Pixel Snap`` to true, you can also search for ``Pixel Snap``).
|
||||
- Viewport Scaling can often help with shrinking the map (see the
|
||||
:ref:`doc_viewports` tutorial). Simply adding a camera, setting it to ``Current`` and playing around with it's ``Zoom`` may be a good starting point.
|
||||
- You can use a single, separate image for each tile. This will remove all artifacts, but
|
||||
|
||||
Reference in New Issue
Block a user