FAQ: Convert to LF line endings

reference/faq.rst

@@ -1,193 +1,193 @@
-.. _doc_faq:
-
-Frequently asked questions
-==========================
-
-GDScript? Why your own scripting language? Why not Lua, Javascript, C#, etc.?
------------------------------------------------------------------------------
-
-The short answer is, we'd rather a programmer does the small effort to
-learn GDScript so he or she later has a seamless experience, than
-attracting him or her with a familiar programming language that results
-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 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 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
-editor is made with this API), and an excellent tool to optimize parts
-of a project, but trying to use it instead of GDScript for an entire
-game is, in most cases, a waste of time.
-
-Yes, for more than a decade we tried in the past integrating several
-VMs (and even shipped games using them), such as Python, Squirrel and
-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 in the :ref:`doc_gdscript_more_efficiently`
-tutorial.
-
-For the more technically versed, proceed to the next item.
-
-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.)
-2. No good class extending support in most script VMs, and adapting to
-   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
-   reduced performance when using custom types (Lua, Python, Squirrel,
-   JS, AS, etc.)
-5. Garbage collector results in stalls or unnecessarily large memory
-   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.
-
-GDScript was designed to solve the issues above, and performs very well
-in all the above scenarios. Please learn GDScript, and enjoy from a
-very smooth integration of scripting with the game engine (yes, it's a
-rare but very enjoyable situation when things just work). It's worth
-it, give it a try!
-
-Why is FBX not supported for import?
-------------------------------------
-
-FBX SDK has a very `restrictive license <http://www.blender.org/bf/Autodesk_FBX_License.rtf>`_,
-that is incompatible with the `open license <http://opensource.org/licenses/MIT>`_
-provided by Godot.
-
-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?
-------------------------------------------------------------------------------
-
-No, the aim of Godot is to create a complete open source engine
-licensed under MIT, so you have complete control about over single
-piece of it. Open versions of functionality or features from such SDKs
-may be eventually added though.
-
-That said, because it is open source, and modular, nothing prevents you
-or anyone else interested into adding those libraries as a module and
-ship your game using them, as either open or closed source. Everything
-is allowed.
-
-How should assets be created to handle multiple resolutions and aspect ratios?
-------------------------------------------------------------------------------
-
-This question pops up often and it's probably thanks to the
-misunderstanding created by Apple when they originally doubled the
-resolution of their devices. It made people think that having the same
-assets in different resolutions was a good idea, so many continued
-towards that path. That originally worked to a point and only for
-Apple devices, but then several Android and Apple devices with
-different resolutions and aspect ratios were created, with a very
-wide range of sizes an DPIs.
-
-The most common and proper way to this is to, instead, is to use a
-single base resolution for the game and only handle different screen
-aspects. This is mostly needed for 2D, as in 3D it's just a matter of
-Cameara XFov or YFov.
-
-1. Choose a single base resolution for your game. Even if there are
-   devices that go up to 2K and devices that go down to 400p, regular
-   hardware scaling in your device will take care of this at little or
-   no performance cost. Most common choices are either near 1080p
-   (1920x1080) or 720p (1280x720). Keep in mind the higher the
-   resolution, the larger your assets, the more memory they will take
-   and the longer the time it will take for loading.
-
-2. Use the stretch options in Godot, 2D stretching with keeping aspect
-   works best. Check the :ref:`doc_multiple_resolutions` tutorial
-   on how to achieve this.
-
-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.
-
-4. For user interfaces, use the :ref:`anchoring <doc_size_and_anchors>`
-   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.
-
-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
-the :ref:`export option <doc_exporting_images>` to shrink
-images, and set that build to be used for certain screen sizes in the
-App Store or Google Play.
-
-I have a great idea that will make Godot better, What do you think?
--------------------------------------------------------------------
-
-Your idea will most certainly be ignored. Examples of stuff that is
-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 add an alternative workflow for people who prefer it
-
-Developers are always willing to talk to you and listen to your feedback
-very openly, to an extent rarely seen in open source projects, but they
-will care mostly about real issues you have while using Godot, not ideas
-solely based on personal belief. Developers are interested in (for
-example):
-
--  Your experience using the software and the problems you have, (we
-   care about this much more than ideas on how to improve it)
--  The features you would like to see implemented because you need them
-   for your project.
--  The concepts that were difficult to understand in order to learn the
-   software.
--  The parts of your workflow you would like to see optimized.
-
-Once one of the above points is stated, we can work together on a
-solution and this is where your ideas and suggestions are most valuable
-and welcome, they need to be in context of a real issue.
-
-As such, please don't feel that your ideas for Godot are unwelcome.
-Instead, try to reformulate them as a problem first, so developers and
-the community have a base ground to discuss first.
-
-Examples of how NOT to state problems generally are like this:
-
--  Certain feature is ugly
--  Certain workflow is slow
--  Certain feature needs optimization
--  Certain aspect of the UI looks cluttered
-
-Associating something with an adjective will not get you much attention
-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
-   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.
-
-This will allow you to convey what you are thinking much better and set
-a common ground for discussion. Please try your best to state your
-problems as stories to the developers and the community, before
-discussing any idea.
+.. _doc_faq:
+
+Frequently asked questions
+==========================
+
+GDScript? Why your own scripting language? Why not Lua, Javascript, C#, etc.?
+-----------------------------------------------------------------------------
+
+The short answer is, we'd rather a programmer does the small effort to
+learn GDScript so he or she later has a seamless experience, than
+attracting him or her with a familiar programming language that results
+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 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 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
+editor is made with this API), and an excellent tool to optimize parts
+of a project, but trying to use it instead of GDScript for an entire
+game is, in most cases, a waste of time.
+
+Yes, for more than a decade we tried in the past integrating several
+VMs (and even shipped games using them), such as Python, Squirrel and
+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 in the :ref:`doc_gdscript_more_efficiently`
+tutorial.
+
+For the more technically versed, proceed to the next item.
+
+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.)
+2. No good class extending support in most script VMs, and adapting to
+   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
+   reduced performance when using custom types (Lua, Python, Squirrel,
+   JS, AS, etc.)
+5. Garbage collector results in stalls or unnecessarily large memory
+   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.
+
+GDScript was designed to solve the issues above, and performs very well
+in all the above scenarios. Please learn GDScript, and enjoy from a
+very smooth integration of scripting with the game engine (yes, it's a
+rare but very enjoyable situation when things just work). It's worth
+it, give it a try!
+
+Why is FBX not supported for import?
+------------------------------------
+
+FBX SDK has a very `restrictive license <http://www.blender.org/bf/Autodesk_FBX_License.rtf>`_,
+that is incompatible with the `open license <http://opensource.org/licenses/MIT>`_
+provided by Godot.
+
+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?
+------------------------------------------------------------------------------
+
+No, the aim of Godot is to create a complete open source engine
+licensed under MIT, so you have complete control about over single
+piece of it. Open versions of functionality or features from such SDKs
+may be eventually added though.
+
+That said, because it is open source, and modular, nothing prevents you
+or anyone else interested into adding those libraries as a module and
+ship your game using them, as either open or closed source. Everything
+is allowed.
+
+How should assets be created to handle multiple resolutions and aspect ratios?
+------------------------------------------------------------------------------
+
+This question pops up often and it's probably thanks to the
+misunderstanding created by Apple when they originally doubled the
+resolution of their devices. It made people think that having the same
+assets in different resolutions was a good idea, so many continued
+towards that path. That originally worked to a point and only for
+Apple devices, but then several Android and Apple devices with
+different resolutions and aspect ratios were created, with a very
+wide range of sizes an DPIs.
+
+The most common and proper way to this is to, instead, is to use a
+single base resolution for the game and only handle different screen
+aspects. This is mostly needed for 2D, as in 3D it's just a matter of
+Cameara XFov or YFov.
+
+1. Choose a single base resolution for your game. Even if there are
+   devices that go up to 2K and devices that go down to 400p, regular
+   hardware scaling in your device will take care of this at little or
+   no performance cost. Most common choices are either near 1080p
+   (1920x1080) or 720p (1280x720). Keep in mind the higher the
+   resolution, the larger your assets, the more memory they will take
+   and the longer the time it will take for loading.
+
+2. Use the stretch options in Godot, 2D stretching with keeping aspect
+   works best. Check the :ref:`doc_multiple_resolutions` tutorial
+   on how to achieve this.
+
+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.
+
+4. For user interfaces, use the :ref:`anchoring <doc_size_and_anchors>`
+   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.
+
+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
+the :ref:`export option <doc_exporting_images>` to shrink
+images, and set that build to be used for certain screen sizes in the
+App Store or Google Play.
+
+I have a great idea that will make Godot better, What do you think?
+-------------------------------------------------------------------
+
+Your idea will most certainly be ignored. Examples of stuff that is
+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 add an alternative workflow for people who prefer it
+
+Developers are always willing to talk to you and listen to your feedback
+very openly, to an extent rarely seen in open source projects, but they
+will care mostly about real issues you have while using Godot, not ideas
+solely based on personal belief. Developers are interested in (for
+example):
+
+-  Your experience using the software and the problems you have, (we
+   care about this much more than ideas on how to improve it)
+-  The features you would like to see implemented because you need them
+   for your project.
+-  The concepts that were difficult to understand in order to learn the
+   software.
+-  The parts of your workflow you would like to see optimized.
+
+Once one of the above points is stated, we can work together on a
+solution and this is where your ideas and suggestions are most valuable
+and welcome, they need to be in context of a real issue.
+
+As such, please don't feel that your ideas for Godot are unwelcome.
+Instead, try to reformulate them as a problem first, so developers and
+the community have a base ground to discuss first.
+
+Examples of how NOT to state problems generally are like this:
+
+-  Certain feature is ugly
+-  Certain workflow is slow
+-  Certain feature needs optimization
+-  Certain aspect of the UI looks cluttered
+
+Associating something with an adjective will not get you much attention
+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
+   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.
+
+This will allow you to convey what you are thinking much better and set
+a common ground for discussion. Please try your best to state your
+problems as stories to the developers and the community, before
+discussing any idea.