Updated devel_faq (markdown)

reduz 2014-09-04 08:26:55 -07:00
parent 80038cfd50
commit 0e151ed20b

@ -12,7 +12,7 @@ Godot C++ API is also efficient and easy to use (the entire Godot editor is made
Letting aside the benefits of using GDScript, the main problem with other languages is more their VMs than the languages themselves. Godot has used Lua in the past (Ariel Manzur wrote tolua++ for previous engine versions, a very popular framework for binding C++ to Lua used in other engines and frameworks), Squirrel and Python. The multiple reasons why those approaches were abandoned:
* Godot ease of use and design efficiency resides in and usage pattern is based on extending, this does not work so well with existing scripting languages and requires a huge amount of binding code. This generates bottlenecks (excessive use of fallbacks, manual reference handling, etc), difficult to debug code and general unpredictability. The code for simply binding Godot to Lua or Squirrel was bigger than GDScript whole runtime and parser.
* Godot ease of use and efficiency resides in an usage pattern based on extending, this does not work so well with existing scripting languages and requires a huge amount of binding code. This generates bottlenecks (excessive use of fallbacks, manual reference handling, etc), difficult to debug code and general unpredictability. The code for simply binding Godot to Lua or Squirrel was bigger than GDScript whole runtime and parser.
* Script run-times like Lua, while proven to be very fast at executing their native types, are much slower with custom-bound types. Video games use vector-math extensively and creating such types using the standard binder system results in very slow performance. GDScript supports them natively.
* Godot supports multi-threading for a lot of operations. Script VMs such as the one for Lua, Squirrel, Python, etc. have terrible or no support for it at all.