mirror of
https://github.com/godotengine/godot-docs.git
synced 2026-01-05 22:09:56 +03:00
Merge pull request #561 from cooperra/specially-vs-especially
Proofreading: Change most usages of "specially" to "especially"
This commit is contained in:
@@ -138,7 +138,7 @@ Member Variables
|
||||
Numeric Constants
|
||||
-----------------
|
||||
|
||||
- **ANIMATION_PROCESS_PHYSICS** = **0** --- Process animation during the physics process. This is specially useful when animating physics bodies.
|
||||
- **ANIMATION_PROCESS_PHYSICS** = **0** --- Process animation during the physics process. This is especially useful when animating physics bodies.
|
||||
- **ANIMATION_PROCESS_IDLE** = **1** --- Process animation during the idle process.
|
||||
|
||||
Description
|
||||
|
||||
@@ -13,7 +13,7 @@ Disclaimer
|
||||
----------
|
||||
|
||||
While it is possible to compile for iOS on a Linux environment, Apple is
|
||||
very restrictive about the tools to be used (specially hardware-wise),
|
||||
very restrictive about the tools to be used (especially hardware-wise),
|
||||
allowing pretty much only their products to be used for development. So
|
||||
this is **not official**. However, a `statement from Apple in 2010
|
||||
<http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
|
||||
|
||||
@@ -73,7 +73,7 @@ of the game, the programmer can configure the dynamic memory pool size.
|
||||
Allocating memory
|
||||
-----------------
|
||||
|
||||
Godot has many tools for tracking memory usage in a game, specially
|
||||
Godot has many tools for tracking memory usage in a game, especially
|
||||
during debug. Because of this, the regular C and C++ library calls
|
||||
should not be used. Instead, a few other ones are provided.
|
||||
|
||||
@@ -192,7 +192,7 @@ StringName from a string results in a unique internal pointer for all
|
||||
equal strings. StringNames are really useful for using strings as
|
||||
identifier, as comparing them is basically comparing a pointer.
|
||||
|
||||
Creation of a StringName (specially a new one) is slow, but comparison
|
||||
Creation of a StringName (especially a new one) is slow, but comparison
|
||||
is fast.
|
||||
|
||||
References:
|
||||
|
||||
@@ -99,7 +99,7 @@ Exporting
|
||||
---------
|
||||
|
||||
Exporting the project from the command line is also supported. This is
|
||||
specially useful for continuous integration setups. The version of Godot
|
||||
especially useful for continuous integration setups. The version of Godot
|
||||
that is headless (server build, no video) is ideal for this.
|
||||
|
||||
::
|
||||
@@ -120,7 +120,7 @@ Running a script
|
||||
----------------
|
||||
|
||||
It is possible to run a simple .gd script from the command line. This
|
||||
feature is specially useful in very large projects, for batch
|
||||
feature is especially useful in very large projects, for batch
|
||||
conversion of assets or custom import/export.
|
||||
|
||||
The script must inherit from SceneTree or MainLoop.
|
||||
|
||||
@@ -119,7 +119,7 @@ Damping
|
||||
-------
|
||||
|
||||
Damping applies friction to the particles, forcing them to stop. It is
|
||||
specially useful for sparks or explosions, which usually begin with a
|
||||
especially useful for sparks or explosions, which usually begin with a
|
||||
high linear velocity and then stop as they fade.
|
||||
|
||||
.. image:: img/paranim10.gif
|
||||
|
||||
@@ -12,7 +12,7 @@ the 3D platformer tutorial, or the 3D kinematic character tutorials,
|
||||
which are almost identical to their 2D counterparts.
|
||||
|
||||
In 3D, math is a little more complex than in 2D, so also checking the
|
||||
:ref:`doc_vector_math` in the wiki (which were specially created for game
|
||||
:ref:`doc_vector_math` in the wiki (which were especially created for game
|
||||
developers, not mathematicians or engineers) will help pave the way into
|
||||
efficiently developing 3D games.
|
||||
|
||||
|
||||
@@ -22,7 +22,7 @@ inside an AudioStreamPlayer.
|
||||
When using these kind of files, you should choose which one is best for your specific use case:
|
||||
|
||||
* Audio files of type *.wav* are considerably big, but use very little amount of your CPU to play. Hundreds of them can be played simultaneously with little impact to performance. This format is usually best for short sound effects, as the importer will trim them and convert them to IMA-ADPCM.
|
||||
* Audio files of type *.ogg* are much smaller, but use considerably more amount of CPU power to play back, so only a few can be played back (specially on mobile!). This format is usually best for music or long sound effect sequences. It also works well for voice at relatively low bitrates.
|
||||
* Audio files of type *.ogg* are much smaller, but use considerably more amount of CPU power to play back, so only a few can be played back (especially on mobile!). This format is usually best for music or long sound effect sequences. It also works well for voice at relatively low bitrates.
|
||||
|
||||
Keep in mind both .wav and .ogg generally don't contain looping information, so this information must be set on the import options of each:
|
||||
|
||||
|
||||
@@ -36,7 +36,7 @@ Each one has a specific function:
|
||||
be defined in this enumerator. The role will be followed even if the
|
||||
light is disabled, which allows to configure a light and then disable
|
||||
it for baking.
|
||||
- **Energy**: This value is a multiplier for the light, it's specially
|
||||
- **Energy**: This value is a multiplier for the light, it's especially
|
||||
useful for :ref:`doc_high_dynamic_range` and for Spot and Omni lights, because it can
|
||||
create very bright spots near the emitter.
|
||||
- **Diffuse and Specular**: These light values get multiplied by the
|
||||
|
||||
@@ -102,7 +102,7 @@ use the same as a parent viewport (root viewport does contain one
|
||||
though, which is the one objects are rendered to by default). A world can
|
||||
be set in a viewport using the "world" property, and that will separate
|
||||
all children nodes of that viewport from interacting with the parent
|
||||
viewport world. This is specially useful in scenarios where, for
|
||||
viewport world. This is especially useful in scenarios where, for
|
||||
example, you might want to show a separate character in 3D imposed over
|
||||
the game (like in Starcraft).
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ This tutorial aims to be a quick reference for how to use GDScript more
|
||||
efficiently. It focuses on common cases specific to the language, but
|
||||
also covers a lot of information on dynamically typed languages.
|
||||
|
||||
It's meant to be specially useful for programmers with little or no previous
|
||||
It's meant to be especially useful for programmers with little or no previous
|
||||
experience with dynamically typed languages.
|
||||
|
||||
Dynamic nature
|
||||
|
||||
@@ -1328,7 +1328,7 @@ be obtained when a call to Node._ready() is made.
|
||||
func _ready():
|
||||
mylabel = get_node("MyLabel")
|
||||
|
||||
This can get a little cumbersome, specially when nodes and external
|
||||
This can get a little cumbersome, especially when nodes and external
|
||||
references pile up. For this, GDScript has the ``onready`` keyword, that
|
||||
defers initialization of a member variable until _ready is called. It
|
||||
can replace the above code with a single line:
|
||||
|
||||
@@ -37,7 +37,7 @@ to the high integration with Godot:
|
||||
* It uses no garbage collector, so it trades a small bit of automation (most objects are reference counted anyway), by determinism.
|
||||
* The dynamic nature of it makes it easy to optimize chunks of it in C++ (via GDNative) if more performance is required at some point, without recompiling the engine.
|
||||
|
||||
If undecided, and have experience in programming (specially dynamically
|
||||
If undecided, and have experience in programming (especially dynamically
|
||||
typed languages), go for GDScript!
|
||||
|
||||
Visual Script
|
||||
|
||||
@@ -32,7 +32,7 @@ Here is a comparative chart.
|
||||
| OGG Vorbis 96kbps, Stereo | 12kb |
|
||||
+-------------------------------+---------------------+
|
||||
|
||||
In general, what is recommended, is to use WAV for most sound effects, specially those that are short and repetitive, and OGG for music, voice and long sound effects.
|
||||
In general, what is recommended, is to use WAV for most sound effects, especially those that are short and repetitive, and OGG for music, voice and long sound effects.
|
||||
|
||||
Best Practices
|
||||
--------------
|
||||
|
||||
Reference in New Issue
Block a user