Misc fixes in compiling pages

reference/compiling_for_android.rst

@@ -12,20 +12,21 @@ For most cases, using the built-in deployer and export templates is good
 enough. Compiling the Android APK manually is mostly useful for custom
 builds or custom packages for the deployer.
 
-Also, you still need to do all the steps mentioned in the :ref:`doc_exporting_for_android`
-tutorial before attempting your custom export template.
+Also, you still need to do all the steps mentioned in the
+:ref:`doc_exporting_for_android` tutorial before attempting your custom
+export template.
 
 Requirements
 ------------
 
-For compiling under Windows, the following is required:
+For compiling under Windows, Linux or OSX, the following is required:
 
 -  Python 2.7+ (3.0 is untested as of now).
 -  SCons build system.
 -  Android SDK version 8 and 13
 -  Android NDK
 
-Setting Up SCons
+Setting up SCons
 ----------------
 
 Set the environment variable ANDROID_HOME to point to the Android
@@ -50,49 +51,49 @@ Go to the root dir of the engine source code and type:
 
 ::
 
-    C:\\godot> scons platform=android
+    C:\godot> scons platform=android
 
-This should result in a regular .so in \\\\bin folder as if it was
+This should result in a regular .so in ``\bin`` folder as if it was
 compiled with flags: ``tools=no target=debug``. The resulting file will
 be huge because it will contain all debug symbols, so for next builds,
 using ``target=release_debug`` or ``target=release`` is recommended.
 
-Copy the .so to the libs/armeabi Android folder (or symlink if you are
+Copy the .so to the ``libs/armeabi`` Android folder (or symlink if you are
 in Linux or OSX). Note: Git does not support empty directories so you
 will have to create it if it does not exist:
 
 ::
 
-    C:\\godot> mkdir platform/android/java/libs
-    C:\\godot> mkdir platform/android/java/libs/armeabi
+    C:\godot> mkdir platform/android/java/libs
+    C:\godot> mkdir platform/android/java/libs/armeabi
 
-Then copy or symlink:
+Then copy:
 
 ::
 
-    C:\\godot> copy bin/libgodot.android..so platform/android/java/libs/armeabi/libgodot_android.so
+    C:\godot> copy bin/libgodot.android.<version>.so platform/android/java/libs/armeabi/libgodot_android.so
 
-alternatively if you are under unix you can symlink:
+Or alternatively, if you are under a Unix system you can symlink:
 
 ::
 
-    user@host:~/godot$ ln -s bin/libgodot.android..so platform/android/java/libs/armeabi/libgodot_android.so
+    user@host:~/godot$ ln -s bin/libgodot.android.<version>.so platform/android/java/libs/armeabi/libgodot_android.so
 
 Remember that only *one* of libgodot_android.so must exist for each
 platform, for each build type (release, debug, etc), it must be
 replaced.
 
-**Note**: The file inside libs/armeabi must be renamed to
+**Note**: The file inside ``libs/armeabi`` must be renamed to
 **"libgodot_android.so"**, or else unsatisfied link error will happen
 at runtime.
 
 If you also want to include support for x86 Android, add the following
-compile flag: ``x86=yes`` , then copy/symlink the resulting folder to
-the x86 folder:
+compile flag: ``x86=yes``, then copy/symlink the resulting folder to
+the ``x86`` folder:
 
 ::
 
-    C:\\godot> cp bin/libgodot.android..x86.so platform/android/java/libs/x86/libgodot_android.so
+    C:\godot> copy bin/libgodot.android.<version>.x86.so platform/android/java/libs/x86/libgodot_android.so
 
 This will create a fat binary that works in both platforms, but will add
 about 6 megabytes to the APK.
@@ -107,7 +108,7 @@ the current numbers, then set the following environment variables:
 
 ::
 
-    NDK_TOOLCHAIN  (by default set to "arm-eabi-4.4.0")
+    NDK_TOOLCHAIN (by default set to "arm-eabi-4.4.0")
     NDK_TARGET (by default set to "arm-linux-androideabi-4.8")
 
 Building the APK
@@ -118,11 +119,11 @@ or release build:
 
 ::
 
-    C:\\godot\\platform\\android\\java> ant debug
+    C:\godot\platform\android\java> ant debug
 
 ::
 
-    C:\\godot\\platform\\android\\java> ant release
+    C:\godot\platform\android\java> ant release
 
 In the ``java/bin`` subfolder, the resulting apk can be used as export
 template.
@@ -143,14 +144,14 @@ really handy! (and required some reverse engineering of the format).
 Compiling the standard export templates is done by calling scons with
 the following arguments:
 
-(debug)
+-  (debug)
 
 ::
 
-    C:\\godot> scons platform=android target=release_debug
-    C:\\godot> cp bin/libgodot_android.opt.debug.so platform/android/java/libs/armeabi
-    C:\\godot> cd platform/android/java
-    C:\\godot\\platform\\android\\java> ant release
+    C:\godot> scons platform=android target=release_debug
+    C:\godot> cp bin/libgodot_android.opt.debug.so platform/android/java/libs/armeabi
+    C:\godot> cd platform/android/java
+    C:\godot\platform\android\java> ant release
 
 Resulting APK is in:
 
@@ -158,14 +159,14 @@ Resulting APK is in:
 
     platform/android/java/bin/Godot-release-unsigned.apk
 
-(release)
+-  (release)
 
 ::
 
-    C:\\godot> scons platform=android target=release
-    C:\\godot> cp bin/libgodot_android.opt.so platform/android/java/libs/armeabi
-    C:\\godot> cd platform/android/java
-    C:\\godot\\platform\\android\\java> ant release
+    C:\godot> scons platform=android target=release
+    C:\godot> cp bin/libgodot_android.opt.so platform/android/java/libs/armeabi
+    C:\godot> cd platform/android/java
+    C:\godot\platform\android\java> ant release
 
 Resulting APK is in:
 
@@ -189,7 +190,7 @@ here:
 .. image:: /img/andtemplates.png
 
 You don't even need to copy them, you can just reference the resulting
-file in the bin\\\\ directory of your Godot source folder, so the next
+file in the ``bin\`` directory of your Godot source folder, so the next
 time you build you automatically have the custom templates referenced.
 
 Troubleshooting
@@ -208,7 +209,7 @@ If it still fails, open a command line and run logcat:
 
 ::
 
-    C:\\android-sdk\\platform-tools> adb logcat
+    C:\android-sdk\platform-tools> adb logcat
 
 And check the output while the application is installed. Reason for
 failure should be presented there.
@@ -221,10 +222,8 @@ Application exits immediately
 If the application runs but exits immediately, there might be one of the
 following reasons:
 
--  libgodot_android.so is not in libs/armeabi
+-  libgodot_android.so is not in ``libs/armeabi``
 -  Device does not support armv7 (try compiling yourself for armv6)
 -  Device is Intel, and apk is compiled for ARM.
 
 In any case, ``adb logcat`` should also show the cause of the error.
-
-

reference/compiling_for_ios.rst

@@ -27,7 +27,7 @@ for a debug build, or:
 
     $ scons p=iphone bin/godot.iphone.opt target=release
 
-for a release build (check platform/iphone/detect.py for the compiler
+for a release build (check ``platform/iphone/detect.py`` for the compiler
 flags used for each configuration).
 
 Alternatively, you can run

reference/compiling_for_linux.rst

@@ -11,29 +11,22 @@ Requirements
 For compiling under Linux or other Unix variants, the following is
 required:
 
--  GCC or LLVM
--  Python 2.7+ (3.0 is untested as of now).
--  SCons build system.
--  X11 and MESA development Libraries
--  Xinerama Libraries
+-  GCC (G++) or Clang
+-  Python 2.7+ (3.0 is untested as of now)
+-  SCons build system
+-  X11 and Mesa development libraries
+-  Xinerama libraries
 -  ALSA development libraries
 -  Freetype (for the editor)
 -  OpenSSL (for HTTPS and TLS)
--  pkg-config (used to detect the above three)
--  libevdev-dev and libudev-dev (for facultative joypad support)
+-  libudev-dev (optional, for gamepad support)
+-  pkg-config (used to detect the above dependencies)
 
 For Ubuntu users:
 
 ::
 
-    apt-get install scons pkg-config libx11-dev libxcursor-dev build-essential libasound2-dev libfreetype6-dev libgl1-mesa-dev libglu-dev libssl-dev libxinerama-dev
-
-If you wish to have Joypad support, libevdev-dev and libudev-dev are
-required.
-
-::
-
-    apt-get install libevdev-dev libudev-dev
+    apt-get install scons pkg-config libx11-dev libxcursor-dev build-essential libasound2-dev libfreetype6-dev libgl1-mesa-dev libglu-dev libssl-dev libxinerama-dev libudev-dev
 
 Compiling
 ---------
@@ -55,14 +48,14 @@ Building export templates
 To build Linux export templates, run the build system with the following
 parameters:
 
-(32 bits)
+-  (32 bits)
 
 ::
 
     user@host:~/godot$ scons platform=x11 tools=no target=release bits=32
     user@host:~/godot$ scons platform=x11 tools=no target=release_debug bits=32
 
-(64 bits)
+-  (64 bits)
 
 ::
 
@@ -74,8 +67,8 @@ platform in linux is quite difficult and might need a chroot
 environment.
 
 In Ubuntu, compilation works without a chroot but some libraries (.so)
-might be missing from /usr/lib32. Symlinking the missing .so files from
-/usr/lib results in a working build.
+might be missing from ``/usr/lib32``. Symlinking the missing .so files from
+``/usr/lib`` results in a working build.
 
 To create standard export templates, the resulting files must be copied
 to:
@@ -102,5 +95,3 @@ here:
 You don't even need to copy them, you can just reference the resulting
 files in the bin/ directory of your Godot source folder, so the next
 time you build you automatically have the custom templates referenced.
-
-

reference/compiling_for_osx.rst

@@ -11,8 +11,8 @@ Requirements
 For compiling under Linux or other Unix variants, the following is
 required:
 
--  Python 2.7+ (3.0 is untested as of now).
--  SCons build system.
+-  Python 2.7+ (3.0 is untested as of now)
+-  SCons build system
 -  XCode
 
 Compiling
@@ -28,39 +28,39 @@ If all goes well, the resulting binary executable will be placed in the
 "bin" subdirectory. This executable file contains the whole engine and
 runs without any dependencies. Executing it will bring up the project
 manager. There is a .app template to put the binary into in
-tools/Godot.app.
+``tools/Godot.app``.
 
 Cross-compiling
 ---------------
 
-It is possible to compile for OS X in a Linux environment (and maybe
+It is possible to compile for OSX in a Linux environment (and maybe
 also in Windows with Cygwin). For that you will need
-`OSXCross <https://github.com/tpoechtrager/osxcross>`__ for being able
-to use OS X as target. First, follow the instructions to install it:
+`OSXCross <https://github.com/tpoechtrager/osxcross>`__to be able
+to use OSX as target. First, follow the instructions to install it:
 
-# Clone the OSXCross repository
-(https://github.com/tpoechtrager/osxcross) somewhere in your machine (or
-download a Zip file and extract it somewhere). E.g.
+Clone the `OSXCross repository <https://github.com/tpoechtrager/osxcross>`
+somewhere on your machine (or download a zip file and extract it somewhere),
+e.g.:
 
 ::
 
-    ~$ git clone https://github.com/tpoechtrager/osxcross.git /home/myuser/sources/osxcross
+    user@host:~$ git clone https://github.com/tpoechtrager/osxcross.git /home/myuser/sources/osxcross
 
-#. Follow the instructions to package the SDK:
+1. Follow the instructions to package the SDK:
    https://github.com/tpoechtrager/osxcross#packaging-the-sdk
-#. Follow the instructions to install OSXCross:
+2. Follow the instructions to install OSXCross:
    https://github.com/tpoechtrager/osxcross#installation
 
 After that, you will need to define the ``OSXCROSS_ROOT`` as the path to
 the OSXCross installation (the same place where you cloned the
-repository/extracted the zip. E.g.
+repository/extracted the zip), e.g.:
 
 ::
 
-    ~$ export OSXCROSS_ROOT=/home/myuser/sources/oscross
+    user@host:~$ export OSXCROSS_ROOT=/home/myuser/sources/oscross
 
 Now you can compile with SCons like you normally would:
 
 ::
 
-    ~/godot$ scons platform=osx
+    user@host:~/godot$ scons platform=osx

reference/compiling_for_universal_windows_apps.rst

@@ -29,7 +29,7 @@ Windows 8.1
 
 -  Open a "VS 2013 x64 Cross Tools Command Prompt"
 -  The value of environment variable "PLATFORM" should be "x64"
--  Run scons with platform=winrt from the root of the source tree::
+-  Run scons with ``platform=winrt`` from the root of the source tree::
 
     C:\godot_source> scons platform=winrt
 
@@ -42,7 +42,7 @@ Windows Phone 8.1
 
 -  Open a "Visual Studio 2012 ARM Phone Tools Command Prompt"
 -  The value of environment variable "PLATFORM" should be "arm"
--  Run scons with platform=winrt from the root of the source tree::
+-  Run scons with ``platform=winrt`` from the root of the source tree::
 
     C:\godot_source> scons platform=winrt
 
@@ -99,8 +99,8 @@ Angle
 ANGLE precompiled binaries are provided on platform/winrt/x64 and
 platform/winrt/arm. They are built from MSOpenTech's "future-dev"
 branch, found here: https://github.com/MSOpenTech/angle. The visual
-studio 'solutions' used are found on "projects/winrt/windows/angle.sln"
-and "projects/winrt/windowsphone/angle.sln".
+studio 'solutions' used are found on ``projects/winrt/windows/angle.sln``
+and ``projects/winrt/windowsphone/angle.sln``.
 
 What's missing
 --------------
@@ -122,10 +122,10 @@ This is what we know:
 
 -  App packages are documented here:
    http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh464929.aspx
--  There are 2 command line tools that might be useful, `App
-   Packager <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
-   and
-   `SignTool <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
+-  There are 2 command line tools that might be useful, `App Packager
+   <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh446767.aspx>`__
+   and `SignTool
+   <http://msdn.microsoft.com/en-us/library/windows/apps/xaml/ff551778.aspx>`__.
 -  There are a bunch of tools on "powershell" that deal with packages
    that might be relevant:
    http://technet.microsoft.com/library/dn448373.aspx

reference/compiling_for_windows.rst

@@ -16,19 +16,18 @@ For compiling under Windows, the following is required:
    version that can compile for C++, Desktop**.
 -  `Python 2.7+ <http://www.python.org/getit/releases/2.7/>`__ (3.0 is
    untested as of now). Using the 32-bits installer is recommended.
--  `Pywin32 Python
-   Extension <http://sourceforge.net/projects/pywin32>`__ for parallel
-   builds (which increase the build speed by a great factor).
+-  `Pywin32 Python Extension <http://sourceforge.net/projects/pywin32>`__
+   for parallel builds (which increase the build speed by a great factor).
 -  `SCons <http://www.scons.org>`__ build system.
 
 Setting up SCons
 ----------------
 
 Python adds the interpreter (python.exe) to the path. It usually
-installs in C:\\\\Python (or C:\\\\Python[Version]). SCons installs
+installs in ``C:\Python`` (or ``C:\Python[Version]``). SCons installs
 inside the python install and provides a .bat file called "scons.bat".
 The location of this file can be added to the path or it can simply be
-copied to C:\\\\Python together with the interpreter executable.
+copied to ``C:\Python`` together with the interpreter executable.
 
 Compiling
 ---------
@@ -39,10 +38,10 @@ the engine source code and type:
 
 ::
 
-    C:\\godot> scons platform=windows
+    C:\godot> scons platform=windows
 
 If all goes well, the resulting binary executable will be placed in
-C:\\\\godot\\\\bin\\\\godot.windows.tools.exe. This executable file
+``C:\godot\bin\godot.windows.tools.exe``. This executable file
 contains the whole engine and runs without any dependencies. Executing
 it will bring up the project manager.
 
@@ -58,7 +57,7 @@ following should be called in a .bat file:
 
 ::
 
-    C:\\path_to_sdk\\vcvarsall.bat &&  scons bin/godot.windows.tools.exe
+    C:\path_to_sdk\vcvarsall.bat && scons bin/godot.windows.tools.exe
 
 **NOTE:** It seems the latest Visual Studio does not include a desktop
 command prompt (No, Native tools for x86 is not it). The only way to
@@ -66,11 +65,11 @@ build it seems to be by running:
 
 ::
 
-    "C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\VC\\vcvarsall.bat" && c:\\python27\\scons p=windows
+    "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\vcvarsall.bat" && c:\python27\scons p=windows
 
 (or however your VS and Scons are installed)
 
-Cross compiling
+Cross-compiling
 ---------------
 
 If you are a Linux or Mac user, you need to install mingw32 and
@@ -80,7 +79,7 @@ mingw-w64. Under Ubuntu or Debian, just run the following commands:
 
     apt-get install mingw32 mingw-w64
 
-If you are using other distro, scons will check for the following
+If you are using another distro, scons will check for the following
 binaries:
 
 ::
@@ -110,26 +109,26 @@ Creating Windows export templates
 Windows export templates are created by compiling Godot as release, with
 the following flags:
 
-(for 32 bits, using Mingw32 command prompt or Visual Studio command
+-  (for 32 bits, using Mingw32 command prompt or Visual Studio command
 prompt)
 
 ::
 
-    C:\\godot> scons platform=windows tools=no target=release bits=32
-    C:\\godot> scons platform=windows tools=no target=release_debug bits=32
+    C:\godot> scons platform=windows tools=no target=release bits=32
+    C:\godot> scons platform=windows tools=no target=release_debug bits=32
 
-(for 64 bits, using Mingw-w64 or Visual Studio command prompt)
+-  (for 64 bits, using Mingw-w64 or Visual Studio command prompt)
 
 ::
 
-    C:\\godot> scons platform=windows tools=no target=release bits=64
-    C:\\godot> scons platform=windows tools=no target=release_debug bits=64
+    C:\godot> scons platform=windows tools=no target=release bits=64
+    C:\godot> scons platform=windows tools=no target=release_debug bits=64
 
 If you plan on replacing the standard templates, copy these to:
 
 ::
 
-    C:\\USERS\\YOURUSER\\AppData\\Roaming\\Godot\\Templates
+    C:\USERS\YOURUSER\AppData\Roaming\Godot\Templates
 
 With the following names:
 
@@ -147,7 +146,5 @@ here:
 .. image:: /img/wintemplates.png
 
 You don't even need to copy them, you can just reference the resulting
-files in the bin\\\\ directory of your Godot source folder, so the next
+files in the ``bin\`` directory of your Godot source folder, so the next
 time you build you automatically have the custom templates referenced.
-
-

reference/cross-compiling_for_ios_on_linux.rst

@@ -15,37 +15,36 @@ Disclaimer
 While it is possible to compile for iOS on a Linux environment, Apple is
 very restrictive about the tools to be used (specially hardware-wise),
 allowing pretty much only their products to be used for development. So
-this is **not official**. However, a `statement from Apple in
-2010 <http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
-says they relaxed some of the `App Store review
-guidelines <https://developer.apple.com/app-store/review/guidelines/>`__
-to allow any tool to be used, as long as the resulting binary do not
+this is **not official**. However, a `statement from Apple in 2010
+<http://www.apple.com/pr/library/2010/09/09Statement-by-Apple-on-App-Store-Review-Guidelines.html>`__
+says they relaxed some of the `App Store review guidelines
+<https://developer.apple.com/app-store/review/guidelines/>`__
+to allow any tool to be used, as long as the resulting binary does not
 download any code, which means it should be OK to use the procedure
 described here and cross-compiling the binary.
 
 Requirements
 ------------
 
--  `**XCode with the iOS
-   SDK** <https://developer.apple.com/xcode/download>`__ (a dmg image)
--  `**Clang >=3.5** <http://clang.llvm.org>`__ for your development
-   machine installed and in the ``PATH``. It needs to be version >= 3.5
+-  `XCode with the iOS SDK <https://developer.apple.com/xcode/download>`__
+   (a dmg image)
+-  `Clang >= 3.5 <http://clang.llvm.org>`__ for your development
+   machine installed and in the ``PATH``. It has to be version >= 3.5
    to target ``arm64`` architecture.
--  `**Fuse** <http://fuse.sourceforge.net>`__ for mounting and umounting
+-  `Fuse <http://fuse.sourceforge.net>`__ for mounting and umounting
    the dmg image.
--  `**darling-dmg** <https://github.com/darlinghq/darling-dmg>`__, which
+-  `darling-dmg <https://github.com/darlinghq/darling-dmg>`__, which
    needs to be built from source. The procedure for that is explained
    below.
 
    -  For building darling-dmg, you'll need the development packages of
-      the following libraries: **fuse, icu, openssl, zlib, bzip2**.
+      the following libraries: fuse, icu, openssl, zlib, bzip2.
 
--  `**cctools-port** <https://github.com/tpoechtrager/cctools-port>`__
+-  `cctools-port <https://github.com/tpoechtrager/cctools-port>`__
    for the needed build tools. The procedure for building is quite
    peculiar and is described below.
 
-   -  This also has some extra dependencies: **automake, autogen,
-      libtool**.
+   -  This also has some extra dependencies: automake, autogen, libtool.
 
 Configuring the environment
 ---------------------------
@@ -53,45 +52,45 @@ Configuring the environment
 darling-dmg
 ~~~~~~~~~~~
 
-# Clone the repository in your machine:
+Clone the repository on your machine:
 
 ::
 
-    $ git clone https://github.com/LubosD/darling-dmg.git
+    $ git clone https://github.com/darlinghq/darling-dmg.git
 
-# Build it:
+Build it:
 
 ::
 
     $ cd darling-dmg
     $ mkdir build
     $ cd build
-    $ cmake .. -DCMAKE_BUILD_TYPE=RELEASE
-    $ make -j 4  # The number is the amount of cores your processor have, for faster build
+    $ cmake .. -DCMAKE_BUILD_TYPE=Release
+    $ make -j 4  # The number is the amount of cores your processor has, for faster build
     $ cd ../..
 
 Preparing the SDK
 ~~~~~~~~~~~~~~~~~
 
-# Mount the XCode image:
+Mount the XCode image:
 
 ::
 
     $ mkdir xcode
     $ ./darling-dmg/build/darling-dmg /path/to/Xcode_7.1.1.dmg xcode
-    [...]   
+    [...]
     Everything looks OK, disk mounted
 
-# Extract the iOS SDK:
+Extract the iOS SDK:
 
 ::
 
     $ mkdir -p iPhoneSDK/iPhoneOS9.1.sdk
     $ cp -r xcode/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/* iPhoneSDK/iPhoneOS9.1.sdk
     $ cp -r xcode/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/* iPhoneSDK/iPhoneOS9.1.sdk/usr/include/c++
-    $ fusermount -u xcode # unmount the image
+    $ fusermount -u xcode  # unmount the image
 
-# Pack the SDK:
+Pack the SDK:
 
 ::
 
@@ -101,7 +100,7 @@ Preparing the SDK
 Toolchain
 ~~~~~~~~~
 
-# Build cctools:
+Build cctools:
 
 ::
 
@@ -109,7 +108,7 @@ Toolchain
     $ cd cctools-port/usage_examples/ios_toolchain
     $ ./build.sh /path/iPhoneOS9.1.sdk.tar.xz arm64
 
-# Copy the tools to a nicer place. Note that the SCons scripts for
+Copy the tools to a nicer place. Note that the SCons scripts for
 building will look under ``usr/bin`` inside the directory you provide
 for the toolchain binaries, so you must copy to such subdirectory, akin
 to the following commands:
@@ -130,14 +129,14 @@ environment: the built toolchain and the iPhoneOS SDK directory. Those
 can stay anywhere you want since you have to provide their paths to the
 SCons build command.
 
-# For the iPhone platform to be detected, you need the ``OSXCROSS_IOS``
+For the iPhone platform to be detected, you need the ``OSXCROSS_IOS``
 environment variable defined to anything.
 
 ::
 
     $ export OSXCROSS_IOS=anything
 
-# Now you can compile for iPhone using SCons like the standard Godot
+Now you can compile for iPhone using SCons like the standard Godot
 way, with some additional arguments to provide the correct paths:
 
 ::
@@ -157,5 +156,4 @@ you are in the root Godot source directory:
 
     $ /path/to/iostoolchain/usr/bin/arm-apple-darwin11-lipo -create bin/godot.iphone.opt.debug.32 bin/godot.iphone.opt.debug.64 -output bin/godot.iphone.opt.debug.fat
 
-Then you will have an iOS fat binary in
-``bin/godot.iphone.opt.debug.fat``.
+Then you will have an iOS fat binary in ``bin/godot.iphone.opt.debug.fat``.

reference/introduction_to_the_buildsystem.rst

@@ -68,19 +68,19 @@ example:
     scons: `.' is up to date.
     scons: done building targets.
 
-To build a platform (for example, x11), run with the platform= (or just
-p= to make it short) argument:
+To build for a platform (for example, x11), run with the ``platform=`` (or just
+``p=`` to make it short) argument:
 
 ::
 
     user@host:~/godot$ scons platform=x11
 
 This will start the build process, which will take a while. If you want
-scons to build faster, use the -j parameter to specify how many cores
+scons to build faster, use the ``-j`` parameter to specify how many cores
 will be used for the build. Or just leave it using one core, so you can
 use your computer for something else :)
 
-Example for using 4 processes:
+Example for using 4 cores:
 
 ::
 
@@ -94,7 +94,7 @@ generally with this naming convention:
 
 ::
 
-    godot..[opt].[tools/debug]..
+    godot.<platform>.[opt].[tools/debug].<bits>[extension]
 
 For the previous build attempt the result would look like this:
 
@@ -110,14 +110,14 @@ A Windows binary with the same configuration will look like this.
 
 ::
 
-    C:\\GODOT> DIR BIN/
+    C:\GODOT> DIR BIN/
     godot.windows.tools.64.exe
 
 Just copy that binary to wherever you like, as it self-contains the
 project manager, editor and all means to execute the game. However, it
 lacks the data to export it to the different platforms. For that the
 export templates are needed (which can be either downloaded from
-http://www.godotengine.org, or you can build them yourself).
+`godotengine.org <http://godotengine.org>`, or you can build them yourself).
 
 Aside from that, there are a few standard options that can be set in all
 build targets, and will be explained as follows.
@@ -132,7 +132,7 @@ manager.
 
 ::
 
-    scons platform= tools=yes/no
+    scons platform=<platform> tools=yes/no
 
 Target
 ------
@@ -151,10 +151,10 @@ Target controls optimization and debug flags. Each mode means:
 
 ::
 
-    scons platform= target=debug/release_debug/release
+    scons platform=<platform> target=debug/release_debug/release
 
 This flag appends ".debug" suffix (for debug), or ".tools" (for debug
-with tools enables). When optimization is enabled (release) it appends
+with tools enabled). When optimization is enabled (release) it appends
 the ".opt" suffix.
 
 Bits
@@ -173,7 +173,7 @@ else.
 
 ::
 
-    scons platform= bits=default/32/64
+    scons platform=<platform> bits=default/32/64
 
 This flag appends ".32" or ".64" suffixes to resulting binaries when
 relevant.
@@ -182,9 +182,9 @@ Export templates
 ----------------
 
 Official export templates are downloaded from the Godot Engine site:
-http://www.godotengine.org. However, you might want to build them
-yourself (in case you want newer ones, you are using custom modules, or
-simply don't trust your own shadow).
+`godotengine.org <http://godotengine.org>`. However, you might want
+to build them yourself (in case you want newer ones, you are using custom
+modules, or simply don't trust your own shadow).
 
 If you download the official export templates package and unzip it, you
 will notice that most are just optimized binaries or packages for each
@@ -208,8 +208,6 @@ platform:
     windows_32_release.exe
     windows_64_debug.exe
     windows_64_release.exe
-    windows_debug.exe
-    windows_release.exe
 
 To create those yourself, just follow the instructions detailed for each
 platform in this same tutorial section. Each platform explains how to

reference/variant_class.rst

@@ -37,7 +37,7 @@ of c++ with little effort. Become a friend of Variant today.
 References:
 ~~~~~~~~~~~
 
--  `core/variant.h <https://github.com/okamstudio/godot/blob/master/core/variant.h>`__
+-  `core/variant.h <https://github.com/godotengine/okamstudio/godot/blob/master/core/variant.h>`__
 
 Dictionary and Array
 --------------------
@@ -52,7 +52,7 @@ mode (meaning modifications to a container will modify all references to
 it), or COW mode (modifications will always alter the local copy, making
 a copy of the internal data if necessary, but will not affect the other
 copies). In COW mode, Both Dictionary and Array are thread-safe,
-otherwise a Nutex should be created to lock if multi thread access is
+otherwise a Mutex should be created to lock if multi thread access is
 desired.
 
 References: