|  | 
|  | 1 | +.. _doc_about_godot_cpp: | 
|  | 2 | + | 
|  | 3 | +About godot-cpp | 
|  | 4 | +=============== | 
|  | 5 | + | 
|  | 6 | +`godot-cpp <https://github.com/godotengine/godot-cpp>`__ are the official C++ GDExtension bindings, maintained | 
|  | 7 | +as part of the Godot project. | 
|  | 8 | + | 
|  | 9 | +godot-cpp is built with the :ref:`GDExtension system <doc_gdextension>`, which allows access to Godot in almost the | 
|  | 10 | +same way as :ref:`modules <doc_custom_modules_in_cpp>`: A lot of `engine code <https://github.com/godotengine/godot>`__ | 
|  | 11 | +can be used in your godot-cpp project almost exactly as it is. | 
|  | 12 | + | 
|  | 13 | +In particular, godot-cpp has access to all functions that :ref:`GDScript <doc_gdscript>` and :ref:`C# <doc_c_sharp>` | 
|  | 14 | +have, and additional access to a few more for fast low-level access of data, or deeper integration with Godot. | 
|  | 15 | + | 
|  | 16 | +Differences between godot-cpp and C++ modules | 
|  | 17 | +--------------------------------------------- | 
|  | 18 | + | 
|  | 19 | +You can use both `godot-cpp <https://github.com/godotengine/godot-cpp>`__ | 
|  | 20 | +and :ref:`C++ modules <doc_custom_modules_in_cpp>` to run C or C++ code in a Godot project. | 
|  | 21 | + | 
|  | 22 | +They also both allow you to integrate third-party libraries into Godot. The one | 
|  | 23 | +you should choose depends on your needs. | 
|  | 24 | + | 
|  | 25 | +.. warning:: | 
|  | 26 | + | 
|  | 27 | +    godot-cpp is currently *experimental*, which means that we may | 
|  | 28 | +    break compatibility in order to fix major bugs or include critical features. | 
|  | 29 | + | 
|  | 30 | + | 
|  | 31 | +Advantages of godot-cpp | 
|  | 32 | +~~~~~~~~~~~~~~~~~~~~~~~ | 
|  | 33 | + | 
|  | 34 | +Unlike modules, godot-cpp (and GDExtensions, in general) don't require | 
|  | 35 | +compiling the engine's source code, making it easier to distribute your work. | 
|  | 36 | +It gives you access to most of the API available to GDScript and C#, allowing | 
|  | 37 | +you to code game logic with full control regarding performance. It's ideal if | 
|  | 38 | +you need high-performance code you'd like to distribute as an add-on in the | 
|  | 39 | +:ref:`asset library <doc_what_is_assetlib>`. | 
|  | 40 | + | 
|  | 41 | +Also: | 
|  | 42 | + | 
|  | 43 | +- You can use the same compiled godot-cpp library in the editor and exported | 
|  | 44 | +  project. With C++ modules, you have to recompile all the export templates you | 
|  | 45 | +  plan to use if you require its functionality at runtime. | 
|  | 46 | +- godot-cpp only requires you to compile your library, not the whole engine. | 
|  | 47 | +  That's unlike C++ modules, which are statically compiled into the engine. | 
|  | 48 | +  Every time you change a module, you need to recompile the engine. Even with | 
|  | 49 | +  incremental builds, this process is slower than using godot-cpp. | 
|  | 50 | + | 
|  | 51 | +Advantages of C++ modules | 
|  | 52 | +~~~~~~~~~~~~~~~~~~~~~~~~~ | 
|  | 53 | + | 
|  | 54 | +We recommend :ref:`C++ modules <doc_custom_modules_in_cpp>` in cases where | 
|  | 55 | +godot-cpp (or another GDExtension system) isn't enough: | 
|  | 56 | + | 
|  | 57 | +- C++ modules provide deeper integration into the engine. GDExtension's access | 
|  | 58 | +  is not as deep as static modules. | 
|  | 59 | +- You can use C++ modules to provide additional features in a project without | 
|  | 60 | +  carrying native library files around. This extends to exported projects. | 
|  | 61 | + | 
|  | 62 | +.. note:: | 
|  | 63 | + | 
|  | 64 | +    If you notice that specific systems are not accessible via godot-cpp | 
|  | 65 | +    but are via custom modules, feel free to open an issue on the | 
|  | 66 | +    `godot-cpp repository <https://github.com/godotengine/godot-cpp>`__ | 
|  | 67 | +    to discuss implementation options for exposing the missing functionality. | 
|  | 68 | + | 
|  | 69 | +.. _doc_what_is_gdextension_version_compatibility: | 
|  | 70 | + | 
|  | 71 | +Version compatibility | 
|  | 72 | +--------------------- | 
|  | 73 | + | 
|  | 74 | +Usually, GDExtensions targeting an earlier version of Godot will work in later | 
|  | 75 | +minor versions, but not vice-versa. For example, a GDExtension targeting Godot 4.2 | 
|  | 76 | +should work just fine in Godot 4.3, but one targeting Godot 4.3 won't work in Godot 4.2. | 
|  | 77 | + | 
|  | 78 | +For this reason, when creating GDExtensions, you may want to target the lowest version of | 
|  | 79 | +Godot that has the features you need, *not* the most recent version of Godot. This can | 
|  | 80 | +save you from needing to create multiple builds for different versions of Godot. | 
|  | 81 | + | 
|  | 82 | +However, GDExtension is currently *experimental*, which means that we may | 
|  | 83 | +break compatibility in order to fix major bugs or include critical features. | 
|  | 84 | +For example, GDExtensions created for Godot 4.0 aren't compatible with Godot | 
|  | 85 | +4.1 (see :ref:`updating_your_gdextension_for_godot_4_1`). | 
|  | 86 | + | 
|  | 87 | +GDExtensions are also only compatible with engine builds that use the same | 
|  | 88 | +level of floating-point precision the extension was compiled for. This means | 
|  | 89 | +that if you use an engine build with double-precision floats, the extension must | 
|  | 90 | +also be compiled for double-precision floats and use an ``extension_api.json`` | 
|  | 91 | +file generated by your custom engine build. See :ref:`doc_large_world_coordinates` | 
|  | 92 | +for details. | 
|  | 93 | + | 
|  | 94 | +Generally speaking, if you build a custom version of Godot, you should generate an | 
|  | 95 | +``extension_api.json`` from it for your GDExtensions, because it may have some differences | 
|  | 96 | +from official Godot builds. | 
0 commit comments