Wrap GDNative tutorials to 80 chars

tutorials/plugins/gdnative/gdnative-c-example.rst

@@ -5,14 +5,25 @@ GDNative C example
 
 Introduction
 ------------
-This tutorial will introduce you to the bare minimum required to create GDNative modules. This should be your starting point into the world of GDNative, understanding the contents of this tutorial will help you in understanding all that is to come after this.
 
-Before we begin, you can download the source code to the example object we'll be describing here by following this link:
+This tutorial will introduce you to the bare minimum required to create GDNative
+modules. This should be your starting point into the world of GDNative,
+understanding the contents of this tutorial will help you in understanding all
+that is to come after this.
+
+Before we begin, you can download the source code to the example object we'll be
+describing here by following this link:
 https://github.com/GodotNativeTools/GDNative-demos/tree/master/c/SimpleDemo
 
-This example project also contains a SConstruct file that makes compiling a little easier but in this tutorial we'll be doing things by hand.
+This example project also contains a SConstruct file that makes compiling a
+little easier but in this tutorial we'll be doing things by hand.
 
-:ref:`GDNative <class_GDNative>` can be used to create several types of additions to Godot, from PluginScript to ARVR interfaces. In this tutorial we are going to look at creating a :ref:`NativeScript <class_NativeScript>` module. NativeScript allows you to write logic in C or C++ in similar fashion as you would write a GDScript file. We'll be creating the C equivalent of this GDScript:
+:ref:`GDNative <class_GDNative>` can be used to create several types of
+additions to Godot, from PluginScript to ARVR interfaces. In this tutorial we
+are going to look at creating a :ref:`NativeScript <class_NativeScript>` module.
+NativeScript allows you to write logic in C or C++ in similar fashion as you
+would write a GDScript file. We'll be creating the C equivalent of this
+GDScript:
 
 ::
 
@@ -26,19 +37,24 @@ This example project also contains a SConstruct file that makes compiling a litt
     func get_data():
         return data
 
-We'll be writing separate tutorials on the other types of GDNative modules and explain what each of them is for as we go through them.
+We'll be writing separate tutorials on the other types of GDNative modules and
+explain what each of them is for as we go through them.
 
 Prerequisites
 -------------
+
 Before we start you'll need a few things.
 
 1) A Godot 3.0 executable
 2) A C compiler
 3) A copy of this repository: https://github.com/GodotNativeTools/godot_headers
 
-The first two pretty much speak for themselves. On Linux, you'll likely have a C compiler, on macOS, it's easiest to install Xcode from the Mac App Store and, on Windows, we've tested this with both MSVC 2015 and 2017.
+The first two pretty much speak for themselves. On Linux, you'll likely have a C
+compiler, on macOS, it's easiest to install Xcode from the Mac App Store and, on
+Windows, we've tested this with both MSVC 2015 and 2017.
 
-For number 3, we suggest that you create a folder somewhere that you use to store your code, open up a terminal and CD into that folder. Then execute:
+For number 3, we suggest that you create a folder somewhere that you use to
+store your code, open up a terminal and CD into that folder. Then execute:
 
 .. code-block:: none
 
@@ -46,52 +62,78 @@ For number 3, we suggest that you create a folder somewhere that you use to stor
 
 This will download the required files into that folder.
 
-.. note:: On this repository you will now find different branches. As Godot evolves, so does GDNative. With the exception of one breaking change in ARVR between 3.0 and 3.1, GDNative modules build for older versions of Godot will work with newer versions of Godot but not the other way around.
+.. note::
+
+    On this repository you will now find different branches. As Godot evolves, so
+    does GDNative. With the exception of one breaking change in ARVR between 3.0
+    and 3.1, GDNative modules build for older versions of Godot will work with
+    newer versions of Godot but not the other way around.
 
-The master branch of the ``godot_headers`` repository is kept in line with the master branch of Godot and thus contains the GDNative class and structure definitions that will work with the latest Godot master.
+The master branch of the ``godot_headers`` repository is kept in line with the
+master branch of Godot and thus contains the GDNative class and structure
+definitions that will work with the latest Godot master.
 
-The 3.0 branch of the ``godot_headers`` repository contains the GDNative class and structure definitions that will work with Godot 3.0. You can clone this branch by executing:
+The 3.0 branch of the ``godot_headers`` repository contains the GDNative class
+and structure definitions that will work with Godot 3.0. You can clone this
+branch by executing:
 
 .. code-block:: none
 
     git clone https://github.com/GodotNativeTools/godot_headers -b 3.0
 
-If you are building Godot from source with your own changes that impact GDNative, you can find the updated class and structure definition in ``<godotsource>/modules/gdnative/include``
+If you are building Godot from source with your own changes that impact
+GDNative, you can find the updated class and structure definition in
+``<godotsource>/modules/gdnative/include``
 
 Our C source
 ------------
-Let's start by writing our main code. Ideally, we want to end up with a file structure that looks something like this:
-
-.. code-block:: none
-
-  + <your development folder>
-    + godot_headers
-      - <lots of files here>
-    + simple
-      + bin
-        - libsimple.dll/so/dylib
-        - libsimple.gdnlib
-        - simple.gdns
-      + src
-        - .gdignore
-        - simple.c
-      main.tscn
-      project.godot
-
-Open up Godot and create a new project called simple. This will create the ``simple`` folder and ``project.godot`` file. Then manually create a ``bin`` and ``src`` subfolder in this folder.
-
-We're going to start by having a look at what our ``simple.c`` file contains. Now, for our example here we're making a single C source file without a header to keep things simple. Once you start writing bigger projects it is advisable you break your project up into multiple files. That however falls outside of the scope of this tutorial.
-
-We'll be looking at the source code bit by bit so all the parts below should all be put together into one big file. I'll explain each section as we add it.
-
-The below code includes our header files that we need and then defines two pointers to two different structs.
-GDNative supports a large collection for functions for calling back into the main Godot executable. In order for your module to have access to these functions, GDNative provides your application with a struct containing pointers to all these functions.
 
-To keep this implementation modular and easily extendable, the core functions are available directly through the "core" API struct, but additional functions have their own "GDNative structs" that are accessible through extensions.
+Let's start by writing our main code. Ideally, we want to end up with a file
+structure that looks something like this:
 
-In our example, we access one of these extension to gain access to the functions specifically needed for NativeScript.
+.. code-block:: none
 
-.. code:: C
+    + <your development folder>
+      + godot_headers
+        - <lots of files here>
+      + simple
+        + bin
+          - libsimple.dll/so/dylib
+          - libsimple.gdnlib
+          - simple.gdns
+        + src
+          - .gdignore
+          - simple.c
+        main.tscn
+        project.godot
+
+Open up Godot and create a new project called simple. This will create the
+``simple`` folder and ``project.godot`` file. Then manually create a ``bin`` and
+``src`` subfolder in this folder.
+
+We're going to start by having a look at what our ``simple.c`` file contains.
+Now, for our example here we're making a single C source file without a header
+to keep things simple. Once you start writing bigger projects it is advisable
+you break your project up into multiple files. That however falls outside of the
+scope of this tutorial.
+
+We'll be looking at the source code bit by bit so all the parts below should all
+be put together into one big file. I'll explain each section as we add it.
+
+The below code includes our header files that we need and then defines two
+pointers to two different structs. GDNative supports a large collection for
+functions for calling back into the main Godot executable. In order for your
+module to have access to these functions, GDNative provides your application
+with a struct containing pointers to all these functions.
+
+To keep this implementation modular and easily extendable, the core functions
+are available directly through the "core" API struct, but additional functions
+have their own "GDNative structs" that are accessible through extensions.
+
+In our example, we access one of these extension to gain access to the functions
+specifically needed for NativeScript.
+
+.. code-block:: C
 
     #include <gdnative_api_struct.gen.h>
     #include <stdio.h>
@@ -101,22 +143,34 @@ In our example, we access one of these extension to gain access to the functions
     const godot_gdnative_core_api_struct *api = NULL;
     const godot_gdnative_ext_nativescript_api_struct *nativescript_api = NULL;
 
-A NativeScript behaves like any other script in Godot. Because the NativeScript API is rather low level, it requires the library to specify many things more verbosely than other scripting systems, such as GDScript. When a NativeScript instance gets created, a library-given constructor gets called. When that instance gets destroyed, the given destructor will be executed.
+A NativeScript behaves like any other script in Godot. Because the NativeScript
+API is rather low level, it requires the library to specify many things more
+verbosely than other scripting systems, such as GDScript. When a NativeScript
+instance gets created, a library-given constructor gets called. When that
+instance gets destroyed, the given destructor will be executed.
 
-These are forward declarations for the functions we'll be implementing for our object. A constructor and destructor is needed. Additionally, the object will have a single method called get_data.
+These are forward declarations for the functions we'll be implementing for our
+object. A constructor and destructor is needed. Additionally, the object will
+have a single method called get_data.
 
-.. code:: C
+.. code-block:: C
 
     void *simple_constructor(godot_object *p_instance, void *p_method_data);
     void simple_destructor(godot_object *p_instance, void *p_method_data, void *p_user_data);
     godot_variant simple_get_data(godot_object *p_instance, void *p_method_data
         , void *p_user_data, int p_num_args, godot_variant **p_args);
 
-Next up is the first of the entry points Godot will call when our dynamic library is loaded. These methods are all prefixed with Godot (you can change this later on) followed by their name. ``gdnative_init`` is a function that initialises our dynamic library. Godot will give it a pointer to a structure that contains various bits of information we may find useful amongst which the pointers to our API structures.
+Next up is the first of the entry points Godot will call when our dynamic
+library is loaded. These methods are all prefixed with Godot (you can change
+this later on) followed by their name. ``gdnative_init`` is a function that
+initialises our dynamic library. Godot will give it a pointer to a structure
+that contains various bits of information we may find useful amongst which the
+pointers to our API structures.
 
-For any additional API structures we need to loop through our extensions array and check the type of extension.
+For any additional API structures we need to loop through our extensions array
+and check the type of extension.
 
-.. code:: C
+.. code-block:: C
 
     void GDN_EXPORT godot_gdnative_init(godot_gdnative_init_options *p_options) {
         api = p_options->api_struct;
@@ -132,24 +186,48 @@ For any additional API structures we need to loop through our extensions array a
         }
     }
 
-Next up is ``gdnative_terminate`` which is called before the library is unloaded. Godot will unload the library when no object uses it anymore. Here, you can do any cleanup you may need to do. For our example, we're simply going to clear our API pointers.
+Next up is ``gdnative_terminate`` which is called before the library is
+unloaded. Godot will unload the library when no object uses it anymore. Here,
+you can do any cleanup you may need to do. For our example, we're simply going
+to clear our API pointers.
 
-.. code:: C
+.. code-block:: C
 
     void GDN_EXPORT godot_gdnative_terminate(godot_gdnative_terminate_options *p_options) {
         api = NULL;
         nativescript_api = NULL;
     }
 
-Finally we have ``nativescript_init`` which is the most important function we'll need today. This function will be called by Godot as part of loading a GDNative library and communicates back to Godot what objects we make available to Godot.
-
-We first tell Godot which classes are implemented by calling ``nativescript_register_class``. The first parameter here is the handle pointer given to us. The second is the name of our object class. The third is the type of object in Godot that we 'inherit' from, this is not true inheritance but it's close enough. Finally, our fourth and fifth parameters are descriptions for our constructor and destructor.
-
-We then tell Godot about our methods (well our one method in this case), by calling ``nativescript_register_method`` for each method of our class. In our case, that is just ``get_data``. Our first parameter is yet again our handle pointer. The second is again the name of the object class we're registering. The third is the name of our function as it will be known to GDScript. The fourth is our attributes setting. The fifth and final parameter is a description of which function to call when the method gets called.
-
-The descriptions contain the function pointers to the functions themselves. The other two fields in these structs are for specifying per-method userdata. The value in the ``method_data`` field will be passed on every function call as the ``p_method_data`` argument. This is useful to reuse one function for different methods on possibly multiple different script-classes. If the ``method_data`` value is a pointer to memory that needs to be freed, the ``free_func`` field can contain a pointer to a function that will free that memory. That free function gets called when the script itself (not instance!) gets unloaded (so usually at library-unload time).
-
-.. code:: C
+Finally we have ``nativescript_init`` which is the most important function we'll
+need today. This function will be called by Godot as part of loading a GDNative
+library and communicates back to Godot what objects we make available to Godot.
+
+We first tell Godot which classes are implemented by calling
+``nativescript_register_class``. The first parameter here is the handle pointer
+given to us. The second is the name of our object class. The third is the type
+of object in Godot that we 'inherit' from, this is not true inheritance but it's
+close enough. Finally, our fourth and fifth parameters are descriptions for our
+constructor and destructor.
+
+We then tell Godot about our methods (well our one method in this case), by
+calling ``nativescript_register_method`` for each method of our class. In our
+case, that is just ``get_data``. Our first parameter is yet again our handle
+pointer. The second is again the name of the object class we're registering. The
+third is the name of our function as it will be known to GDScript. The fourth is
+our attributes setting. The fifth and final parameter is a description of which
+function to call when the method gets called.
+
+The descriptions contain the function pointers to the functions themselves. The
+other two fields in these structs are for specifying per-method userdata. The
+value in the ``method_data`` field will be passed on every function call as the
+``p_method_data`` argument. This is useful to reuse one function for different
+methods on possibly multiple different script-classes. If the ``method_data``
+value is a pointer to memory that needs to be freed, the ``free_func`` field can
+contain a pointer to a function that will free that memory. That free function
+gets called when the script itself (not instance!) gets unloaded (so usually at
+library-unload time).
+
+.. code-block:: C
 
     void GDN_EXPORT godot_nativescript_init(void *p_handle) {
         godot_instance_create_func create = { NULL, NULL, NULL };
@@ -170,19 +248,27 @@ The descriptions contain the function pointers to the functions themselves. The
             attributes, get_data);
     }
 
-Now, it's time to start working on the functions of our object. First, we define a structure that we use to store the member data of an instance of our GDNative class.
+Now, it's time to start working on the functions of our object. First, we define
+a structure that we use to store the member data of an instance of our GDNative
+class.
 
-.. code:: C
+.. code-block:: C
 
     typedef struct user_data_struct {
         char data[256];
     } user_data_struct;
 
-And then, we define our constructor. All we do in our constructor is allocate memory for our structure and fill it with some data. Note that we use Godot's memory functions so the memory gets tracked and then return the pointer to our new structure. This pointer will act as our instance identifier in case multiple objects are instantiated.
+And then, we define our constructor. All we do in our constructor is allocate
+memory for our structure and fill it with some data. Note that we use Godot's
+memory functions so the memory gets tracked and then return the pointer to our
+new structure. This pointer will act as our instance identifier in case multiple
+objects are instantiated.
 
-This pointer will be passed to any of our functions related to our object as a parameter called ``p_user_data``, and can both be used to identify our instance and to access its member data.
+This pointer will be passed to any of our functions related to our object as a
+parameter called ``p_user_data``, and can both be used to identify our instance
+and to access its member data.
 
-.. code:: C
+.. code-block:: C
 
     void *simple_constructor(godot_object *p_instance, void *p_method_data) {
         user_data_struct *user_data = api->godot_alloc(sizeof(user_data_struct));
@@ -191,23 +277,36 @@ This pointer will be passed to any of our functions related to our object as a p
         return user_data;
     }
 
-Our destructor is called when Godot is done with our object and we free our instances' member data.
+Our destructor is called when Godot is done with our object and we free our
+instances' member data.
 
-.. code:: C
+.. code-block:: C
 
     void simple_destructor(godot_object *p_instance, void *p_method_data, void *p_user_data) {
         api->godot_free(p_user_data);
     }
 
-And finally, we implement our get_data function. Data is always sent and returned as variants so in order to return our data, which is a string, we first need to convert our C string to a Godot string object, and then copy that string object into the variant we are returning.
+And finally, we implement our get_data function. Data is always sent and
+returned as variants so in order to return our data, which is a string, we first
+need to convert our C string to a Godot string object, and then copy that string
+object into the variant we are returning.
 
-Strings are heap-allocated in Godot, so they have a destructor which frees the memory. Destructors are named ``godot_TYPENAME_destroy``. When a Variant gets created with a String, it references the String. That means that the original String can be "destroyed" to decrease the ref-count. If that does not happen the String memory will leak since the ref-count will never be zero and the memory never deallocated. The returned variant gets automatically destroyed by Godot.
+Strings are heap-allocated in Godot, so they have a destructor which frees the
+memory. Destructors are named ``godot_TYPENAME_destroy``. When a Variant gets
+created with a String, it references the String. That means that the original
+String can be "destroyed" to decrease the ref-count. If that does not happen the
+String memory will leak since the ref-count will never be zero and the memory
+never deallocated. The returned variant gets automatically destroyed by Godot.
 
-(In more complex operations it can be confusing the keep track of which value needs to be deallocated and which does not. As a general rule: call godot_XXX_destroy when a C++ destructor would be called instead. The String destructor would be called in C++ after the Variant was created, so the same is necessary in C)
+(In more complex operations it can be confusing the keep track of which value
+needs to be deallocated and which does not. As a general rule: call
+godot_XXX_destroy when a C++ destructor would be called instead. The String
+destructor would be called in C++ after the Variant was created, so the same is
+necessary in C)
 
 The variant we return is destroyed automatically by Godot.
 
-.. code:: C
+.. code-block:: C
 
     godot_variant simple_get_data(godot_object *p_instance, void *p_method_data,
             void *p_user_data, int p_num_args, godot_variant **p_args) {
@@ -225,13 +324,19 @@ The variant we return is destroyed automatically by Godot.
 
 And that is the whole source code of our module.
 
-If you add a blank ``.gdignore`` file to the src folder, Godot will not try to import the compiler-generated temporary files.
+If you add a blank ``.gdignore`` file to the src folder, Godot will not try to
+import the compiler-generated temporary files.
 
 Compiling
 ---------
-We now need to compile our source code. As mentioned our example project on GitHub contains a Scons configuration that does all the hard work for you but for our tutorial here we are going to call the compilers directly.
 
-Assuming you are sticking to the folder structure suggested above it is best to CD into the src subfolder in a terminal session and execute the commands from there. Make sure to create the bin folder before you proceed.
+We now need to compile our source code. As mentioned our example project on
+GitHub contains a Scons configuration that does all the hard work for you but
+for our tutorial here we are going to call the compilers directly.
+
+Assuming you are sticking to the folder structure suggested above it is best to
+CD into the src subfolder in a terminal session and execute the commands from
+there. Make sure to create the bin folder before you proceed.
 
 On Linux:
 
@@ -254,11 +359,22 @@ On Windows:
     cl /Fosimple.obj /c simple.c /nologo -EHsc -DNDEBUG /MD /I. /IC:\PATH\TO\GODOT\HEADERS
     link /nologo /dll /out:..\bin\libsimple.dll /implib:..\bin\libsimple.lib simple.obj
 
-.. note:: on the Windows build you also end up with a libsimple.lib library. This is a library that you can compile into a project to provide access to the DLL. We get it as a bonus and we do not need it :) When exporting your game for release this file will be ignored.
+.. note::
+
+    on the Windows build you also end up with a libsimple.lib library. This is a
+    library that you can compile into a project to provide access to the DLL. We
+    get it as a bonus and we do not need it :) When exporting your game for
+    release this file will be ignored.
 
 Creating our GDNLIB file
 ------------------------
-With our module compiled we now need to create a gdnlib file for our module which we place alongside our dynamic libraries. This file tells Godot what dynamic libraries are part of our module and need to be loaded per platform. At the time of writing this tutorial work is still being done on making this configurable from within Godot so for now grab your favourite text editor, create a file called libsimple.gdnlib and add the following into this file:
+
+With our module compiled we now need to create a gdnlib file for our module
+which we place alongside our dynamic libraries. This file tells Godot what
+dynamic libraries are part of our module and need to be loaded per platform. At
+the time of writing this tutorial work is still being done on making this
+configurable from within Godot so for now grab your favourite text editor,
+create a file called libsimple.gdnlib and add the following into this file:
 
 .. code-block:: none
 
@@ -282,25 +398,47 @@ With our module compiled we now need to create a gdnlib file for our module whic
 
 This file contains 3 sections.
 
-The **general** section contains some info that tells Godot how to use our module.
+The **general** section contains some info that tells Godot how to use our
+module.
 
-If singleton is true our library is automatically loaded and a function called godot_singleton_init is called. We'll leave that for another tutorial.
+If singleton is true our library is automatically loaded and a function called
+godot_singleton_init is called. We'll leave that for another tutorial.
 
-If load_once is true our library is loaded only once and each individual script that uses our library will use the same data. Any variable you define globally will be accessible from any instance of your object you create. If load_once is false a new copy of the library is loaded into memory each time a script access the library.
+If load_once is true our library is loaded only once and each individual script
+that uses our library will use the same data. Any variable you define globally
+will be accessible from any instance of your object you create. If load_once is
+false a new copy of the library is loaded into memory each time a script access
+the library.
 
-The symbol_prefix is a prefix for our core functions. So the Godot in godot_nativescript_init for instance. If you use multiple GDnative libraries that you wish to statically link you'll have to use different prefixes. This again is a subject to dive into deeper in a separate tutorial, it is only needed at this time for deployment to iOS as this platform does not like dynamic libraries.
+The symbol_prefix is a prefix for our core functions. So the Godot in
+godot_nativescript_init for instance. If you use multiple GDnative libraries
+that you wish to statically link you'll have to use different prefixes. This
+again is a subject to dive into deeper in a separate tutorial, it is only needed
+at this time for deployment to iOS as this platform does not like dynamic
+libraries.
 
-The **entry** section tells us for each platform and feature combination which dynamic library has to be loaded. This also informs the exporter which files need to be exported when exporting to a specific platform.
+The **entry** section tells us for each platform and feature combination which
+dynamic library has to be loaded. This also informs the exporter which files
+need to be exported when exporting to a specific platform.
 
-The **dependencies** section tells Godot what other files need to be exported for each platform in order for our library to work. Say that your GDNative module uses another DLL to implement functionality from a 3rd party library, this is where you list that DLL.
+The **dependencies** section tells Godot what other files need to be exported
+for each platform in order for our library to work. Say that your GDNative
+module uses another DLL to implement functionality from a 3rd party library,
+this is where you list that DLL.
 
 Putting it all together
 -----------------------
-Now that we should have a working GDNative library it is time to fire up Godot and use it. Open up the sample project if you haven't left it open after creating the project all the way at the beginning of this tutorial.
+
+Now that we should have a working GDNative library it is time to fire up Godot
+and use it. Open up the sample project if you haven't left it open after
+creating the project all the way at the beginning of this tutorial.
 
 Creating our GDNS file
 ----------------------
-With our GDNLIB file we've told Godot how to load our library, now we need to tell it about our "Simple" object class. This we do by creating a GDNS resource file.
+
+With our GDNLIB file we've told Godot how to load our library, now we need to
+tell it about our "Simple" object class. This we do by creating a GDNS resource
+file.
 
 Start by clicking the create resource button in the Inspector:
 
@@ -310,7 +448,10 @@ And select NativeScript:
 
 .. image:: img/nativescript_resource.png
 
-Press Create, now the inspector will show a few fields we need to enter. In Class Name we enter "SIMPLE" which is the object class name we used in our C source when calling godot_nativescript_register_class. We also need to select our GDNLIB file by clicking on Library and selecting Load:
+Press Create, now the inspector will show a few fields we need to enter. In
+Class Name we enter "SIMPLE" which is the object class name we used in our C
+source when calling godot_nativescript_register_class. We also need to select
+our GDNLIB file by clicking on Library and selecting Load:
 
 .. image:: img/nativescript_library.png
 
@@ -318,7 +459,9 @@ Finally click on the save icon and save this as bin/simple.gdns:
 
 .. image:: img/save_gdns.gif
 
-Now it's time to build our scene. Add a control node to your scene as your root and call it main. Then add a button and a label as subnodes. Place them somewhere nice on screen and give your button a name.
+Now it's time to build our scene. Add a control node to your scene as your root
+and call it main. Then add a button and a label as subnodes. Place them
+somewhere nice on screen and give your button a name.
 
 .. image:: img/c_main_scene_layout.png
 
@@ -344,6 +487,7 @@ Now we can implement our main.gd code:
     func _on_Button_pressed():
         $Label.text = "Data = " + data.get_data()
 
-After all that, our project should work. The first time you run it Godot will ask you what your main scene is and you select your main.tscn file and presto:
+After all that, our project should work. The first time you run it Godot will
+ask you what your main scene is and you select your main.tscn file and presto:
 
 .. image:: img/c_sample_result.png

tutorials/plugins/gdnative/gdnative-cpp-example.rst

@@ -7,24 +7,22 @@ Introduction
 ------------
 
 This tutorial builds on top of the information given in the
-:ref:`GDNative C example <doc_gdnative_c_example>`, so we highly
-recommend you read that first.
+:ref:`GDNative C example <doc_gdnative_c_example>`, so we highly recommend you
+read that first.
 
-The C++ bindings for GDNative are built on top of the
-NativeScript GDNative API and provide a nicer way to "extend" nodes
-in Godot using C++. This is equivalent to writing scripts in GDScript,
-but in C++ instead.
+The C++ bindings for GDNative are built on top of the NativeScript GDNative API
+and provide a nicer way to "extend" nodes in Godot using C++. This is equivalent
+to writing scripts in GDScript, but in C++ instead.
 
-Godot 3.1 saw the introduction of the NativeScript 1.1 additions that
-enabled the GDNative team to build a nicer C++ bindings library.
-These changes have now been merged into the master branch and will
-be the way we go forward. If you want to write a C++ GDNative plugin
-that also supports Godot 3.0 you will need to use the 3.0 branch and
-the NativeScript 1.0 syntax. We'll be showing them side by side in
-this writeup.
+Godot 3.1 saw the introduction of the NativeScript 1.1 additions that enabled
+the GDNative team to build a nicer C++ bindings library. These changes have now
+been merged into the master branch and will be the way we go forward. If you
+want to write a C++ GDNative plugin that also supports Godot 3.0 you will need
+to use the 3.0 branch and the NativeScript 1.0 syntax. We'll be showing them
+side by side in this writeup.
 
-You can download the full example we'll be creating in this tutorial
-`on GitHub <https://github.com/BastiaanOlij/gdnative_cpp_example>`_.
+You can download the full example we'll be creating in this tutorial `on
+GitHub <https://github.com/BastiaanOlij/gdnative_cpp_example>`__.
 
 Setting up the project
 ----------------------
@@ -34,23 +32,22 @@ There are a few prerequisites you'll need:
 - a Godot 3.x executable,
 - a C++ compiler,
 - SCons as a build tool,
-- a copy of the `godot-cpp repository <https://github.com/GodotNativeTools/godot-cpp>`_.
+- a copy of the `godot-cpp
+  repository <https://github.com/GodotNativeTools/godot-cpp>`__.
 
 See also :ref:`Compiling <toc-devel-compiling>` as the build tools are identical
 to the ones you need to compile Godot from source.
 
-You can download these repositories from GitHub or let Git
-do the work for you.
-Note that these repositories now have different branches for different
-versions of Godot. GDNative modules written for an earlier version of
-Godot will work in newer versions (with the exception of one breaking
-change in ARVR interfaces between 3.0 and 3.1) but not vice versa so
-make sure you download the correct branch.
-Also note that the version of Godot you use to generate the ``api.json``
+You can download these repositories from GitHub or let Git do the work for you.
+Note that these repositories now have different branches for different versions
+of Godot. GDNative modules written for an earlier version of Godot will work in
+newer versions (with the exception of one breaking change in ARVR interfaces
+between 3.0 and 3.1) but not vice versa so make sure you download the correct
+branch. Also note that the version of Godot you use to generate the ``api.json``
 with becomes your minimum version.
 
-If you are versioning your project using Git,
-it is a good idea to add them as Git submodules:
+If you are versioning your project using Git, it is a good idea to add them as
+Git submodules:
 
 .. tabs::
  .. code-tab:: none Godot
@@ -71,10 +68,10 @@ it is a good idea to add them as Git submodules:
     cd godot-cpp
     git submodule update --init
 
-If you decide to just download the repositories or clone them
-into your project folder, make sure to keep the folder layout identical
-to the one described here, as much of the code we'll be showcasing here
-assumes the project follows this layout.
+If you decide to just download the repositories or clone them into your project
+folder, make sure to keep the folder layout identical to the one described here,
+as much of the code we'll be showcasing here assumes the project follows this
+layout.
 
 Do make sure you clone recursive to pull in both repositories:
 
@@ -91,13 +88,20 @@ Do make sure you clone recursive to pull in both repositories:
     cd gdnative_cpp_example
     git clone --recursive -b 3.0 https://github.com/GodotNativeTools/godot-cpp
 
-.. note:: ``godot-cpp`` now includes ``godot_headers`` as a nested submodule, if you've manually downloaded them please make sure to place ``godot_headers`` inside of the ``godot-cpp`` folder.
+.. note::
+
+    ``godot-cpp`` now includes ``godot_headers`` as a nested submodule, if you've
+    manually downloaded them please make sure to place ``godot_headers`` inside
+    of the ``godot-cpp`` folder.
 
-          You don't have to do it this way but we've found it easiest to manage. If you decide to just download the repositories or just clone them into your folder, make sure to keep the folder layout the same as we've setup here as much of the code we'll be showcasing here assumes the project has this layout.
+    You don't have to do it this way but we've found it easiest to manage. If you
+    decide to just download the repositories or just clone them into your folder,
+    make sure to keep the folder layout the same as we've setup here as much of
+    the code we'll be showcasing here assumes the project has this layout.
 
-If you cloned the example from the link specified in
-the introduction, the submodules are not automatically initialized.
-You will need to execute the following commands:
+If you cloned the example from the link specified in the introduction, the
+submodules are not automatically initialized. You will need to execute the
+following commands:
 
 .. code-block:: none
 
@@ -109,21 +113,23 @@ This will clone these two repositories into your project folder.
 Building the C++ bindings
 -------------------------
 
-Now that we've downloaded our prerequisites, it is time to build
-the C++ bindings.
+Now that we've downloaded our prerequisites, it is time to build the C++
+bindings.
 
 The repository contains a copy of the metadata for the current Godot release,
-but if you need to build these bindings for a newer version of Godot,
-simply call the Godot executable:
+but if you need to build these bindings for a newer version of Godot, simply
+call the Godot executable:
 
 .. code-block:: none
 
     godot --gdnative-generate-json-api api.json
 
-Place the resulting ``api.json`` file in the project folder and add ``use_custom_api_file=yes custom_api_file=../api.json`` to the scons command below.
+Place the resulting ``api.json`` file in the project folder and add
+``use_custom_api_file=yes custom_api_file=../api.json`` to the scons command
+below.
 
-To generate and compile the bindings, use this command (replacing
-``<platform>`` with ``windows``, ``x11`` or ``osx`` depending on your OS):
+To generate and compile the bindings, use this command (replacing ``<platform>``
+with ``windows``, ``x11`` or ``osx`` depending on your OS):
 
 .. code-block:: none
 
@@ -134,31 +140,34 @@ To generate and compile the bindings, use this command (replacing
 This step will take a while. When it is completed, you should have static
 libraries that can be compiled into your project stored in ``godot-cpp/bin/``.
 
-At some point in the future, compiled binaries will be available,
-making this step optional.
+At some point in the future, compiled binaries will be available, making this
+step optional.
+
+.. note::
 
-.. note:: You may need to add ``bits=64`` to the command on Windows or Linux. We're still working on better auto detection.
+    You may need to add ``bits=64`` to the command on Windows or Linux. We're
+    still working on better auto detection.
 
 Creating a simple plugin
 ------------------------
 
-Now it's time to build an actual plugin. We'll start by creating an
-empty Godot project in which we'll place a few files.
+Now it's time to build an actual plugin. We'll start by creating an empty Godot
+project in which we'll place a few files.
 
-Open Godot and create a new project. For this example, we will place it
-in a folder called ``demo`` inside our GDNative module's folder structure.
+Open Godot and create a new project. For this example, we will place it in a
+folder called ``demo`` inside our GDNative module's folder structure.
 
-In our demo project, we'll create a scene containing a Node called "Main"
-and we'll save it as ``main.tscn``. We'll come back to that later.
+In our demo project, we'll create a scene containing a Node called "Main" and
+we'll save it as ``main.tscn``. We'll come back to that later.
 
-Back in the top-level GDNative module folder, we're also going to create
-a subfolder called ``src`` in which we'll place our source files.
+Back in the top-level GDNative module folder, we're also going to create a
+subfolder called ``src`` in which we'll place our source files.
 
-You should now have ``demo``, ``godot-cpp``, ``godot_headers``,
-and ``src`` directories in your GDNative module.
+You should now have ``demo``, ``godot-cpp``, ``godot_headers``, and ``src``
+directories in your GDNative module.
 
-In the ``src`` folder, we'll start with creating our header file
-for the GDNative node we'll be creating. We will name it ``gdexample.h``:
+In the ``src`` folder, we'll start with creating our header file for the
+GDNative node we'll be creating. We will name it ``gdexample.h``:
 
 .. tabs::
  .. code-tab:: C++ NativeScript 1.1
@@ -221,32 +230,30 @@ for the GDNative node we'll be creating. We will name it ``gdexample.h``:
 
     #endif
 
-There are a few things of note to the above.
-We're including ``Godot.hpp`` which contains all our basic definitions.
-After that, we include ``Sprite.hpp`` which contains bindings
-to the Sprite class. We'll be extending this class in our module.
+There are a few things of note to the above. We're including ``Godot.hpp`` which
+contains all our basic definitions. After that, we include ``Sprite.hpp`` which
+contains bindings to the Sprite class. We'll be extending this class in our
+module.
 
-We're using the namespace ``godot``, since everything in GDNative
-is defined within this namespace.
+We're using the namespace ``godot``, since everything in GDNative is defined
+within this namespace.
 
-Then we have our class definition, which inherits from our Sprite
-through a container class. We'll see a few side effects of this later on.
-The ``GODOT_CLASS`` macro sets up a few internal things for us.
+Then we have our class definition, which inherits from our Sprite through a
+container class. We'll see a few side effects of this later on. The
+``GODOT_CLASS`` macro sets up a few internal things for us.
 
 After that, we declare a single member variable called ``time_passed``.
 
-In the next block we're defining our methods, we obviously have
-our constructor and destructor defined, but there are two other
-functions that will likely look familiar to some, and one new method.
+In the next block we're defining our methods, we obviously have our constructor
+and destructor defined, but there are two other functions that will likely look
+familiar to some, and one new method.
 
-The first is ``_register_methods``, which is a static function that Godot
-will call to find out which methods can be called on our NativeScript
-and which properties it exposes.
-The second is our ``_process`` function,
-which will work exactly the same as the ``_process`` function
-you're used to in GDScript.
-The third is our ``_init`` function which is called after Godot has properly
-set up our object. It has to exist even if you don't place any code in it.
+The first is ``_register_methods``, which is a static function that Godot will
+call to find out which methods can be called on our NativeScript and which
+properties it exposes. The second is our ``_process`` function, which will work
+exactly the same as the ``_process`` function you're used to in GDScript. The
+third is our ``_init`` function which is called after Godot has properly set up
+our object. It has to exist even if you don't place any code in it.
 
 Let's implement our functions by creating our ``gdexample.cpp`` file:
 
@@ -308,28 +315,27 @@ Let's implement our functions by creating our ``gdexample.cpp`` file:
         owner->set_position(new_position);
     }
 
-This one should be straightforward. We're implementing each method of
-our class that we defined in our header file.
-Note that the ``register_method`` call **must** expose the ``_process`` method,
-otherwise Godot will not be able to use it. However, we do not have to tell Godot
-about our constructor, destructor and ``_init`` functions.
+This one should be straightforward. We're implementing each method of our class
+that we defined in our header file. Note that the ``register_method`` call
+**must** expose the ``_process`` method, otherwise Godot will not be able to use
+it. However, we do not have to tell Godot about our constructor, destructor and
+``_init`` functions.
 
 The other method of note is our ``_process`` function, which simply keeps track
-of how much time has passed and calculates a new position for our sprite
-using a simple sine and cosine function.
-What stands out is calling ``owner->set_position`` to call one of the build
-in methods of our Sprite. This is because our class is a container class;
-``owner`` points to the actual Sprite node our script relates to.
-In the upcoming NativeScript 1.1, ``set_position`` can be called
-directly on our class.
-
-There is one more C++ file we need; we'll name it ``gdlibrary.cpp``.
-Our GDNative plugin can contain multiple NativeScripts, each with their
-own header and source file like we've implemented ``GDExample`` up above.
-What we need now is a small bit of code that tells Godot about all the
-NativeScripts in our GDNative plugin.
-
-.. code:: C++
+of how much time has passed and calculates a new position for our sprite using a
+simple sine and cosine function. What stands out is calling
+``owner->set_position`` to call one of the build in methods of our Sprite. This
+is because our class is a container class; ``owner`` points to the actual Sprite
+node our script relates to. In the upcoming NativeScript 1.1, ``set_position``
+can be called directly on our class.
+
+There is one more C++ file we need; we'll name it ``gdlibrary.cpp``. Our
+GDNative plugin can contain multiple NativeScripts, each with their own header
+and source file like we've implemented ``GDExample`` up above. What we need now
+is a small bit of code that tells Godot about all the NativeScripts in our
+GDNative plugin.
+
+.. code-block:: C++
 
     #include "gdexample.h"
 
@@ -347,37 +353,37 @@ NativeScripts in our GDNative plugin.
         godot::register_class<godot::GDExample>();
     }
 
-Note that we are not using the ``godot`` namespace here, since the
-three functions implemented here need to be defined without a namespace.
+Note that we are not using the ``godot`` namespace here, since the three
+functions implemented here need to be defined without a namespace.
 
-The ``godot_gdnative_init`` and ``godot_gdnative_terminate`` functions
-get called respectively when Godot loads our plugin and when it unloads it.
-All we're doing here is parse through the functions in our bindings module
-to initialize them, but you might have to set up more things depending
-on your needs.
+The ``godot_gdnative_init`` and ``godot_gdnative_terminate`` functions get
+called respectively when Godot loads our plugin and when it unloads it. All
+we're doing here is parse through the functions in our bindings module to
+initialize them, but you might have to set up more things depending on your
+needs.
 
-The important function is the third function called
-``godot_nativescript_init``. We first call a function in our bindings
-library that does its usual stuff. After that, we call the function
-``register_class`` for each of our classes in our library.
+The important function is the third function called ``godot_nativescript_init``.
+We first call a function in our bindings library that does its usual stuff.
+After that, we call the function ``register_class`` for each of our classes in
+our library.
 
 Compiling the plugin
 --------------------
 
-We cannot easily write by hand a ``SConstruct`` file that SCons would
-use for building. For the purpose of this example, just use
-:download:`this hardcoded SConstruct file <files/cpp_example/SConstruct>`
-we've prepared. We'll cover a more customizable, detailed example on
-how to use these build files in a subsequent tutorial.
+We cannot easily write by hand a ``SConstruct`` file that SCons would use for
+building. For the purpose of this example, just use
+:download:`this hardcoded SConstruct file <files/cpp_example/SConstruct>` we've
+prepared. We'll cover a more customizable, detailed example on how to use these
+build files in a subsequent tutorial.
+
+.. note::
 
-.. note:: This ``SConstruct`` file was written to be used with the latest
-          ``godot-cpp`` master, you may need to make small changes using it with
-          older versions or refer to the ``SConstruct`` file in the Godot 3.0
-          documentation.
+    This ``SConstruct`` file was written to be used with the latest ``godot-cpp``
+    master, you may need to make small changes using it with older versions or
+    refer to the ``SConstruct`` file in the Godot 3.0 documentation.
 
-Once you've downloaded the ``SConstruct`` file, place it in your
-GDNative module folder besides ``godot-cpp``, ``godot_headers``
-and ``demo``, then run:
+Once you've downloaded the ``SConstruct`` file, place it in your GDNative module
+folder besides ``godot-cpp``, ``godot_headers`` and ``demo``, then run:
 
 .. code-block:: none
 
@@ -387,19 +393,19 @@ You should now be able to find the module in ``demo/bin/<platform>``.
 
 .. note::
 
-    Here, we've compiled both godot-cpp and our gdexample library
-    as debug builds. For optimized builds, you should compile them using
-    the ``target=release`` switch.
+    Here, we've compiled both godot-cpp and our gdexample library as debug
+    builds. For optimized builds, you should compile them using the
+    ``target=release`` switch.
 
 Using the GDNative module
 -------------------------
 
-Before we jump back into Godot, we need to create two more files
-in ``demo/bin/``. Both can be created using the Godot editor,
-but it may be faster to create them directly.
+Before we jump back into Godot, we need to create two more files in
+``demo/bin/``. Both can be created using the Godot editor, but it may be faster
+to create them directly.
 
-The first one is a file that lets Godot know what dynamic libraries
-should be loaded for each platform and is called ``gdexample.gdnlib``.
+The first one is a file that lets Godot know what dynamic libraries should be
+loaded for each platform and is called ``gdexample.gdnlib``.
 
 .. code-block:: none
 
@@ -423,31 +429,30 @@ should be loaded for each platform and is called ``gdexample.gdnlib``.
     OSX.64=[]
 
 This file contains a ``general`` section that controls how the module is loaded.
-It also contains a prefix section which should be left on ``godot_`` for now.
-If you change this, you'll need to rename various functions that are
-used as entry points. This was added for the iPhone platform because it doesn't
-allow dynamic libraries to be deployed, yet GDNative modules
-are linked statically.
-
-The ``entry`` section is the important bit: it tells Godot the location of
-the dynamic library in the project's filesystem for each supported platform.
-It will also result in *just* that file being exported when you export the
-project, which means the data pack won't contain libraries that are
-incompatible with the target platform.
-
-Finally, the ``dependencies`` section allows you to name additional
-dynamic libraries that should be included as well. This is important when
-your GDNative plugin implements someone else's library and requires you
-to supply a third-party dynamic library with your project.
-
-If you double click on the ``gdexample.gdnlib`` file within Godot,
-you'll see there are far more options to set:
+It also contains a prefix section which should be left on ``godot_`` for now. If
+you change this, you'll need to rename various functions that are used as entry
+points. This was added for the iPhone platform because it doesn't allow dynamic
+libraries to be deployed, yet GDNative modules are linked statically.
+
+The ``entry`` section is the important bit: it tells Godot the location of the
+dynamic library in the project's filesystem for each supported platform. It will
+also result in *just* that file being exported when you export the project,
+which means the data pack won't contain libraries that are incompatible with the
+target platform.
+
+Finally, the ``dependencies`` section allows you to name additional dynamic
+libraries that should be included as well. This is important when your GDNative
+plugin implements someone else's library and requires you to supply a
+third-party dynamic library with your project.
+
+If you double click on the ``gdexample.gdnlib`` file within Godot, you'll see
+there are far more options to set:
 
 .. image:: img/gdnative_library.png
 
-The second file we need to create is a file used by each NativeScript
-we've added to our plugin. We'll name it ``gdexample.gdns`` for our
-gdexample NativeScript.
+The second file we need to create is a file used by each NativeScript we've
+added to our plugin. We'll name it ``gdexample.gdns`` for our gdexample
+NativeScript.
 
 .. code-block:: none
 
@@ -462,21 +467,20 @@ gdexample NativeScript.
     library = ExtResource( 1 )
     _sections_unfolded = [ "Resource" ]
 
-This is a standard Godot resource; you could just create it directly
-in your scene, but saving it to a file makes it much easier to reuse it
-in other places. This resource points to our gdnlib file, so that Godot
-can know which dynamic library contains our NativeScript. It also defines
-the ``class_name`` which identifies the NativeScript in our plugin
-we want to use.
+This is a standard Godot resource; you could just create it directly in your
+scene, but saving it to a file makes it much easier to reuse it in other places.
+This resource points to our gdnlib file, so that Godot can know which dynamic
+library contains our NativeScript. It also defines the ``class_name`` which
+identifies the NativeScript in our plugin we want to use.
 
-Time to jump back into Godot. We load up the main scene we created way back
-in the beginning and now add a Sprite to our scene:
+Time to jump back into Godot. We load up the main scene we created way back in
+the beginning and now add a Sprite to our scene:
 
 .. image:: img/gdnative_cpp_nodes.png
 
-We're going to assign the Godot logo to this sprite as our texture,
-disable the ``centered`` property and drag our ``gdexample.gdns`` file
-onto the ``script`` property of the sprite:
+We're going to assign the Godot logo to this sprite as our texture, disable the
+``centered`` property and drag our ``gdexample.gdns`` file onto the ``script``
+property of the sprite:
 
 .. image:: img/gdnative_cpp_sprite.png
 
@@ -487,9 +491,10 @@ We're finally ready to run the project:
 Adding properties
 -----------------
 
-GDScript allows you to add properties to your script using the ``export`` keyword.
-In GDNative you have to register the properties and there are two ways of doing this.
-You can either bind directly to a member or use a setter and getter function.
+GDScript allows you to add properties to your script using the ``export``
+keyword. In GDNative you have to register the properties and there are two ways
+of doing this. You can either bind directly to a member or use a setter and
+getter function.
 
 .. note::
 
@@ -497,12 +502,12 @@ You can either bind directly to a member or use a setter and getter function.
     ``_get_property_list``, ``_get`` and ``_set`` methods of an object but that
     goes far beyond the scope of this tutorial.
 
-We'll examine both starting with the direct bind.
-Lets add a property that allows us to control the amplitude of our wave.
+We'll examine both starting with the direct bind. Lets add a property that
+allows us to control the amplitude of our wave.
 
 In our ``gdexample.h`` file we simply need to add a member variable like so:
 
-.. code:: C++
+.. code-block:: C++
 
     ...
     private:
@@ -510,8 +515,8 @@ In our ``gdexample.h`` file we simply need to add a member variable like so:
         float amplitude;
     ...
 
-In our ``gdexample.cpp`` file we need to make a number of changes, we will only show
-the methods we end up changing, don't remove the lines we're omitting:
+In our ``gdexample.cpp`` file we need to make a number of changes, we will only
+show the methods we end up changing, don't remove the lines we're omitting:
 
 .. tabs::
  .. code-tab:: C++ NativeScript 1.1
@@ -562,22 +567,26 @@ the methods we end up changing, don't remove the lines we're omitting:
         owner->set_position(new_position);
     }
 
-Once you compile the module with these changes in place you will see that
-a property has been added to our interface.
-You can now change this property and when you run your project, you will
-see that our Godot icon travels along a larger figure.
+Once you compile the module with these changes in place you will see that a
+property has been added to our interface. You can now change this property and
+when you run your project, you will see that our Godot icon travels along a
+larger figure.
 
 .. note::
-    The ``reloadable`` property in the ``gdexample.gdnlib`` file must be set to ``true`` for the Godot editor
-    to automatically pick up the newly added property.
-    
-    However, this setting should be used with care especially when tool classes are used, 
-    as the editor might hold objects then that have script instances attached to them that are managed by a GDNative library.
 
-Lets do the same but for the speed of our animation and use a setter and getter function.
-Our ``gdexample.h`` header file again only needs a few more lines of code:
+    The ``reloadable`` property in the ``gdexample.gdnlib`` file must be set to
+    ``true`` for the Godot editor to automatically pick up the newly added
+    property.
 
-.. code:: C++
+    However, this setting should be used with care especially when tool classes
+    are used, as the editor might hold objects then that have script instances
+    attached to them that are managed by a GDNative library.
+
+Lets do the same but for the speed of our animation and use a setter and getter
+function. Our ``gdexample.h`` header file again only needs a few more lines of
+code:
+
+.. code-block:: C++
 
     ...
         float amplitude;
@@ -588,8 +597,8 @@ Our ``gdexample.h`` header file again only needs a few more lines of code:
         float get_speed();
     ...
 
-This requires a few more changes to our ``gdexample.cpp`` file, again we're only showing the
-methods that have changed so don't remove anything we're omitting:
+This requires a few more changes to our ``gdexample.cpp`` file, again we're only
+showing the methods that have changed so don't remove anything we're omitting:
 
 .. tabs::
  .. code-tab:: C++ NativeScript 1.1
@@ -663,36 +672,32 @@ methods that have changed so don't remove anything we're omitting:
 Now when the project is compiled we'll see another property called speed.
 Changing its value will make the animation go faster or slower.
 
-For this example there is no obvious advantage of using a setter and getter.
-It is just more code to write. For a simple example as this there may be a
-good reason for a setter if you want to react on the variable being changed
-but in many cases just binding the variable will be enough.
+For this example there is no obvious advantage of using a setter and getter. It
+is just more code to write. For a simple example as this there may be a good
+reason for a setter if you want to react on the variable being changed but in
+many cases just binding the variable will be enough.
 
-Getters and setters become far more useful in more complex scenarios
-where you need to make additional choices based on the state of your
-object.
+Getters and setters become far more useful in more complex scenarios where you
+need to make additional choices based on the state of your object.
 
 .. note::
 
     For simplicity we've left out the optional parameters in the
     register_property<class, type> method call. These parameters are
-    ``rpc_mode``, ``usage``, ``hint`` and ``hint_string``. These can
-    be used to further configure how properties are displayed and set
-    on the Godot side.
+    ``rpc_mode``, ``usage``, ``hint`` and ``hint_string``. These can be used to
+    further configure how properties are displayed and set on the Godot side.
 
-    Modern C++ compilers are able to infer the class and variable type
-    and allow you to omit the ``<GDExample, float>`` part of our
-    ``register_property`` method. we've had mixed experiences with this
-    however.
+    Modern C++ compilers are able to infer the class and variable type and allow
+    you to omit the ``<GDExample, float>`` part of our ``register_property``
+    method. we've had mixed experiences with this however.
 
 Signals
 -------
 
-Last but not least, signals fully work in GDNative as well.
-Having your module react to a signal given out by another object requires
-you to call ``connect`` on that object. We can't think of a good example for
-our wobbling Godot icon, we would need to showcase a far more complete
-example.
+Last but not least, signals fully work in GDNative as well. Having your module
+react to a signal given out by another object requires you to call ``connect``
+on that object. We can't think of a good example for our wobbling Godot icon, we
+would need to showcase a far more complete example.
 
 This however is the required syntax:
 
@@ -705,17 +710,17 @@ This however is the required syntax:
 
     some_other_node->connect("the_signal", owner, "my_method");
 
-Note that you can only call ``my_method`` if you've previously registered
-it in your ``_register_methods`` method.
+Note that you can only call ``my_method`` if you've previously registered it in
+your ``_register_methods`` method.
 
 Having your object sending out signals is far more common. For our wobbling
-Godot icon we'll do something silly just to show how it works. We're going
-to emit a signal every time a second has passed and pass the new location
-along.
+Godot icon we'll do something silly just to show how it works. We're going to
+emit a signal every time a second has passed and pass the new location along.
 
-In our ``gdexample.h`` header file we just need to define a new member ``time_emit``:
+In our ``gdexample.h`` header file we just need to define a new member
+``time_emit``:
 
-.. code:: C++
+.. code-block:: C++
 
     ...
         float time_passed;
@@ -723,9 +728,9 @@ In our ``gdexample.h`` header file we just need to define a new member ``time_em
         float amplitude;
     ...
 
-The changes in ``gdexample.cpp`` are a bit more elaborate this time.
-First you'll need to set ``time_emit = 0.0;`` in either our ``_init`` method or
-in our constructor. But the other two needed changes we'll look at one by one.
+The changes in ``gdexample.cpp`` are a bit more elaborate this time. First
+you'll need to set ``time_emit = 0.0;`` in either our ``_init`` method or in our
+constructor. But the other two needed changes we'll look at one by one.
 
 In our ``_register_methods`` method we need to declare our signal and we do this
 as follows:
@@ -808,15 +813,14 @@ Next we'll need to change our ``_process`` method:
         }
     }
 
-After a second has passed we emit our signal and reset our counter.
-Again in the new version of godot-cpp we can add our parameter values
-directly to ``emit_signal``.
-In NativeScript 1.0 We first build an array of values and then
+After a second has passed we emit our signal and reset our counter. Again in the
+new version of godot-cpp we can add our parameter values directly to
+``emit_signal``. In NativeScript 1.0 We first build an array of values and then
 call ``emit_signal``.
 
-Once compiled we can go into Godot and select our sprite node.
-On our ``Node`` tab we find our new signal and link it up by pressing connect.
-We've added a script on our main node and implemented our signal like this:
+Once compiled we can go into Godot and select our sprite node. On our ``Node``
+tab we find our new signal and link it up by pressing connect. We've added a
+script on our main node and implemented our signal like this:
 
 .. code-block:: none
 
@@ -827,26 +831,25 @@ We've added a script on our main node and implemented our signal like this:
 
 Every second we simply output our position to the console.
 
-
 NativeScript 1.1 vs NativeScript 1.0
 ------------------------------------
 
-So far in our example above there doesn't seem to be a lot of difference
-between the old and new syntax. The class is defined slightly differently
-and we no longer use the ``owner`` member to call methods on the Godot
-side of our object. A lot of the improvements are hidden under the hood.
+So far in our example above there doesn't seem to be a lot of difference between
+the old and new syntax. The class is defined slightly differently and we no
+longer use the ``owner`` member to call methods on the Godot side of our object.
+A lot of the improvements are hidden under the hood.
 
-This example only deals with simple variables and simple methods.
-Especially once you start passing references to other objects or when you
-start calling methods that require more complex parameters, NativeScript 1.1
-does start to show its benefits.
+This example only deals with simple variables and simple methods. Especially
+once you start passing references to other objects or when you start calling
+methods that require more complex parameters, NativeScript 1.1 does start to
+show its benefits.
 
 Next steps
 ----------
 
-The above is only a simple example, but we hope it shows you the basics.
-You can build upon this example to create full-fledged scripts to control
-nodes in Godot using C++.
+The above is only a simple example, but we hope it shows you the basics. You can
+build upon this example to create full-fledged scripts to control nodes in Godot
+using C++.
 
 You should be able to edit and recompile the plugin while the Godot editor
 remains open; just rerun the project after the library has finished building.