mirror of
https://github.com/godotengine/godot-docs.git
synced 2026-01-05 22:09:56 +03:00
Fix some typos with codespell -w
This commit is contained in:
@@ -336,7 +336,7 @@ that will remain unused.
|
||||
Keyframing IK
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
When editing IK chains, is is not neccesary to select the whole chain to
|
||||
When editing IK chains, is is not necessary to select the whole chain to
|
||||
add keyframes. Selecting the endpoint of the chain and inserting a
|
||||
keyframe will automatically insert keyframes until the chain base too.
|
||||
This makes the task of animating extremities much simpler.
|
||||
|
||||
@@ -98,7 +98,7 @@ but will be soon.
|
||||
Customizing a Control
|
||||
---------------------
|
||||
|
||||
If only a few controls need to be skinned. It is often not neccesary to
|
||||
If only a few controls need to be skinned. It is often not necessary to
|
||||
create a new theme. Controls offer their theme options as special kind
|
||||
of properties. If checked, overriding will take place:
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ high linear velocity and then stop as they fade.
|
||||
Initial Angle
|
||||
-------------
|
||||
|
||||
Determines the intial angle of the particle (in degress). This parameter
|
||||
Determines the initial angle of the particle (in degress). This parameter
|
||||
is mostly useful randomized.
|
||||
|
||||
.. image:: /img/paranim11.gif
|
||||
@@ -135,7 +135,7 @@ is mostly useful randomized.
|
||||
Initial & Final Size
|
||||
--------------------
|
||||
|
||||
Determines the intial and final scales of the particle.
|
||||
Determines the initial and final scales of the particle.
|
||||
|
||||
.. image:: /img/paranim12.gif
|
||||
|
||||
@@ -147,7 +147,7 @@ transparency.
|
||||
|
||||
Phases must provide an offset value from 0 to 1, and alays in
|
||||
ascending order. For example, a color will begin at offset 0 and end
|
||||
in offset 1, but 4 colors might use diferent offsets, such as 0, 0.2,
|
||||
in offset 1, but 4 colors might use different offsets, such as 0, 0.2,
|
||||
0.8 and 1.0 for the different phases:
|
||||
|
||||
.. image:: /img/particlecolorphases.png
|
||||
|
||||
@@ -183,7 +183,7 @@ CollisionObject2D derived node
|
||||
By itself it does nothing, but when created as a child of the above
|
||||
mentioned nodes, it adds collision shapes to them. Any amount of
|
||||
CollisionShape2D children can be created, meaning the parent object will
|
||||
simply have mroe collision shapes. When added/deleted/moved/edited, it
|
||||
simply have more collision shapes. When added/deleted/moved/edited, it
|
||||
updates the list of shapes in the parent node.
|
||||
|
||||
At run time, though, this node does not exist (can't be accessed with
|
||||
|
||||
@@ -73,7 +73,7 @@ visuals:
|
||||
|
||||
In the above image, the second sphere (top right) is using the same
|
||||
source for texscreen() as the first one below, so the first one
|
||||
"dissapears", or is not visible.
|
||||
"disappears", or is not visible.
|
||||
|
||||
To correct this, a
|
||||
:ref:`BackBufferCopy <class_BackBufferCopy>`
|
||||
|
||||
@@ -135,7 +135,7 @@ Painting Your World
|
||||
|
||||
With all set, make sure the TileMap node is selected. A red grid will
|
||||
appear on screen, allowing to paint on it with the selected tile on the
|
||||
left pallete.
|
||||
left palette.
|
||||
|
||||
.. image:: /img/tile_example6.png
|
||||
|
||||
|
||||
@@ -87,7 +87,7 @@ These are the base colors for the material.
|
||||
- Specular color is the color of the reflected light and responsible
|
||||
for shines. It is affected by the specular exponent.
|
||||
- Emission is the color of the light generated within the material
|
||||
(althought it will not lit anything else around unless baking). This
|
||||
(although it will not lit anything else around unless baking). This
|
||||
color is constant.
|
||||
- Specular Exponent (or "Shininess"/"Intensity" in some 3D DCCs) is the
|
||||
way light is reflected. If the value is high, light is reflected
|
||||
|
||||
@@ -68,7 +68,7 @@ of light with a single texture? There are two alternatives, the first
|
||||
one is to use DPSM (Dual Paraboloid Shadow Mapping). This technique is
|
||||
fast, but it requires DISCARD to be used (which makes it not very usable
|
||||
on mobile). DPSM can also look rather bad if the geometry is not
|
||||
tesselated enough, so more vertices might be neccesary if it doesnt'r
|
||||
tesselated enough, so more vertices might be necessary if it doesnt'r
|
||||
look tight. The second option is to simply not use a shadow map, and use
|
||||
a shadow cubemap. This is faster, but requires six passes to render all
|
||||
directions and is not supported on the current (GLES2) renderer.
|
||||
@@ -126,7 +126,7 @@ Z-Offset. This improves things a lot:
|
||||
|
||||
.. image:: /img/shadow_offset_2.png
|
||||
|
||||
But it's not quite perfect, self shadowing did not dissapear completely.
|
||||
But it's not quite perfect, self shadowing did not disappear completely.
|
||||
So close to perfection but still not there.. so in a turn of greed you
|
||||
increase the Z-Offset even more!
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ ensures that the same asset can be re-imported in another computer.
|
||||
|
||||
The usual approach to this, when using a VCS such as Subversion,
|
||||
Perforce or GIT, is to create the project in a subfolder, so both it and
|
||||
the source assets can be commited to a same repository. For example:
|
||||
the source assets can be committed to a same repository. For example:
|
||||
|
||||
Repository layout:
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ Implementation
|
||||
|
||||
Godot stores resources to disk. Anything, from a script, to a scene or a
|
||||
PNG image is a resource to the engine. If a resource contains properties
|
||||
that referece other resources on disk, the path to that resource is
|
||||
that reference other resources on disk, the path to that resource is
|
||||
included. If it has sub-resources that are built-in, the resource is
|
||||
saved in a single file together with all the bundled sub-resources. For
|
||||
example, a font resource is often saved with the character textures
|
||||
|
||||
@@ -63,7 +63,7 @@ boundary.
|
||||
|
||||
Like any class that inherits from :ref:`CanvasItem <class_CanvasItem>`
|
||||
(Control does), a :ref:`CanvasItem._draw() <class_CanvasItem__draw>`
|
||||
callback will be received at the begining and every time the control
|
||||
callback will be received at the beginning and every time the control
|
||||
needs to be redrawn (programmer needs to call
|
||||
:ref:`CanvasItem.update() <class_CanvasItem_update>`
|
||||
to enqueue the CanvasItem for redraw). If the control is not visible
|
||||
|
||||
@@ -7,7 +7,7 @@ Introduction
|
||||
------------
|
||||
|
||||
Scene Singletons are very useful things, as they represent a very common
|
||||
use case, but it's not clear at the begining where their value is.
|
||||
use case, but it's not clear at the beginning where their value is.
|
||||
|
||||
The scene system is very useful, but by itself it has a few drawbacks:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user