Browse Source

Misc corrections to "Frequently asked questions"

Andrew Conrad 9 years ago
parent
commit
e4f2d41f49
1 changed files with 17 additions and 16 deletions
  1. 17 16
      reference/faq.rst

+ 17 - 16
reference/faq.rst

@@ -13,12 +13,12 @@ in a worse experience. We are OK if you would rather not give Godot a
 chance because of this, but we strongly encourage you to try it and see
 the benefits yourself.
 
-The official languges for Godot are GDScript and C++.
+The official languages for Godot are GDScript and C++.
 
 GDScript is designed to integrate from the ground to the way Godot
 works, more than any other language, and is very simple and easy to
-learn. Takes at much a day or two to get comfortable and it's very easy
-to see the benefits once you do.  Please do the effort to learn
+learn. Takes at most a day or two to get comfortable and it's very easy
+to see the benefits once you do. Please do the effort to learn
 GDScript, you will not regret it.
 
 Godot C++ API is also efficient and easy to use (the entire Godot
@@ -32,7 +32,8 @@ Lua (in fact we authored tolua++ in the past, one of the most popular
 C++ binders). None of them worked as well as GDScript does now.
 
 More information about getting comfortable with GDScript or dynamically
-typed languages can be found [here](tutorial_gdscript_efficiently).
+typed languages can be found in the :ref:`doc_gdscript_more_efficiently`
+tutorial.
 
 For the more technically versed, proceed to the next item.
 
@@ -42,17 +43,17 @@ I don't believe you. What are the technical reasons for the item above?
 The main reasons are:
 
 1. No good thread support in most script VMs, and Godot uses threads
-   (Lua, Python, Squirrel, JS, AS, etc)
+   (Lua, Python, Squirrel, JS, AS, etc.)
 2. No good class extending support in most script VMs, and adapting to
-   the way Godot works is highly inefficient (lua, Python, JS)
+   the way Godot works is highly inefficient (Lua, Python, JS)
 3. Horrible interface for binding to C++, results in large amount of
    code, bugs, bottlenecks and general inefficiency (Lua, Python,
-   Squirrel, JS, etc)
-4. No native vector types (vector3,matrix4,etc), resulting in highly
+   Squirrel, JS, etc.)
+4. No native vector types (vector3,matrix4,etc.), resulting in highly
    reduced performance when using custom types (Lua, Python, Squirrel,
-   JS, AS, etc)
+   JS, AS, etc.)
 5. Garbage collector results in stalls or unnecessarily large memory
-   usage (Lua, Python, JS, AS, etc)
+   usage (Lua, Python, JS, AS, etc.)
 6. Difficulty to integrate with the code editor for providing code
    completion, live editing, etc. (all of them). This is very well
    supported by GDScript.
@@ -70,13 +71,13 @@ FBX SDK has a very `restrictive license <http://www.blender.org/bf/Autodesk_FBX_
 that is incompatible with the `open license <http://opensource.org/licenses/MIT>`_
 provided by Godot.
 
-That said, Godot Collada support is really good, please use the
+That said, Godot's Collada support is really good, please use the
 `OpenCollada <https://github.com/KhronosGroup/OpenCOLLADA/wiki/OpenCOLLADA-Tools>`_
 exporter for maximum compatibility if you are using Maya or 3DS Max.
 If you are use Blender, take a look at our own
 `Better Collada Exporter <https://godotengine.org/download>`_.
 
-Will [Insert closed SDK such as PhysX, Gameworks, etc.] be supported in Godot?
+Will [Insert closed SDK such as PhysX, GameWorks, etc.] be supported in Godot?
 ------------------------------------------------------------------------------
 
 No, the aim of Godot is to create a complete open source engine
@@ -118,7 +119,7 @@ Cameara XFov or YFov.
    works best. Check the :ref:`doc_multiple_resolutions` tutorial
    on how to achieve this.
 
-3. Determine a minimun resolution and then decide if you want your game
+3. Determine a minimum resolution and then decide if you want your game
    to stretch vertically or horizontally for different aspect ratios, or
    whether there is a minimum one and you want black bars to appear
    instead. This is also explained in the previous step.
@@ -127,7 +128,7 @@ Cameara XFov or YFov.
    to determine where controls should stay and move. If UIs are more
    complex, consider learning about Containers.
 
-And that's it! your game should work in multiple resolutions.
+And that's it! Your game should work in multiple resolutions.
 
 If there really is a desire to make your game also work on ancient
 devices with tiny screens (less than 300 pixels in width), you can use
@@ -144,7 +145,7 @@ ignored by the developers:
 -  Let's do this because it will make Godot better
 -  Let's do this in Godot because another game engine does it
 -  Let's remove this because I think it's not needed
--  Let's remove clutter and bloat and make godot look nicer
+-  Let's remove clutter and bloat and make Godot look nicer
 -  Let's add an alternative workflow for people who prefer it
 
 Developers are always willing to talk to you and listen to your feedback
@@ -181,7 +182,7 @@ and developers will most likely not understand you. Instead, try to
 reformulate your problem as a story such as:
 
 -  I try to move objects around but always end up picking the wrong one
--  I tried to make a game like Battlefield but i'm not managing to
+-  I tried to make a game like Battlefield but I'm not managing to
    understand how to get lighting to look the same.
 -  I always forget which script I was editing, and it takes me too many
    steps to go back to it.