Added support for latex math. All docs converted with metadata.

docs/en/manuals/physics.md

@@ -39,23 +39,23 @@ You add these shapes and can use the ordinary editor transform tools to scale, r
 
 ![Physics properties](images/physics/physics_properties.png)
 
-The "Collision Shape" property is used for tile map geometry that does not use ordinary primitive shapes. We’ll look at that <<anchor-tcs, below>>.
+The *Collision Shape* property is used for tile map geometry that does not use ordinary primitive shapes. We’ll look at that below.
 
-The *Type* property is used to set the type of collision object: "Dynamic", "Kinematic", "Static" or "Trigger". If you set the object to "Dynamic" you _must_ set the *Mass* property to a non zero value. For dynamic or static objects you should also set the *Friction* and *Restitution* values.
+The *Type* property is used to set the type of collision object: `Dynamic`, `Kinematic`, `Static` or `Trigger`. If you set the object to `Dynamic` you _must_ set the *Mass* property to a non zero value. For dynamic or static objects you should also set the *Friction* and *Restitution* values.
 
 ::: important
-If you set the type to "Dynamic" and forget to set the mass to non zero you will get a compilation error: *"ERROR:GAMESYS: Invalid mass 0.000000 for shape type 0"*
+If you set the type to `Dynamic` and forget to set the mass to non zero you will get a compilation error: `"ERROR:GAMESYS: Invalid mass 0.000000 for shape type 0"`
 :::
 
 ## Friction
 
-Friction makes it possible to make object slide realistically against each other. The friction value is usually set between 0 (no friction at all—a very slippery object) and 1 (strong friction—an abrasive object). However, any positive value is valid.
+Friction makes it possible to make object slide realistically against each other. The friction value is usually set between `0` (no friction at all---a very slippery object) and `1` (strong friction---an abrasive object). However, any positive value is valid.
 
-The friction strength is proportional to the normal force (this is called Coulomb friction). When the friction force is computed between two shapes, the friction values of both objects are combined by the geometric mean:
+The friction strength is proportional to the normal force (this is called Coulomb friction). When the friction force is computed between two shapes (`A` and `B`), the friction values of both objects are combined by the geometric mean:
 
-----
-combined_friction = math.sqrt(shape1_friction * shape2_friction)
-----
+$$
+F_{combined} = \sqrt{ F_A \times F_B }
+$$
 
 This means that if one of the objects has zero friction then the contact between them will have zero friction.
 
@@ -63,11 +63,11 @@ This means that if one of the objects has zero friction then the contact between
 
 The restitution value sets the bounciness of the object. The value is usually between 0 (inelastic collision—the object does not bounce at all) and 1 (perfectly elastic collision—the object's velocity will be exactly reflected in the bounce)
 
-Restitution values between two objects are combined using the following formula:
+Restitution values between two shapes (`A` and `B`) are combined using the following formula:
 
-----
-combined_restitution = math.max(shape1_restitution, shape2_restitution)
-----
+$$
+R = \max{ \left( R_A, R_B \right) }
+$$
 
 ::: sidenote
 When a shape develops multiple contacts, restitution is simulated approximately because Box2D uses an iterative solver. Box2D also uses inelastic collisions when the collision velocity is small to prevent bounce-jitter
@@ -87,11 +87,11 @@ Setting this property totally disables rotation on the collision object, no matt
 
 It is often desirable to be able to filter collision so that some types of objects collide with some other type, but not with a third kind. For instance, in a multiplayer shooter game you might want:
 
- . Player characters that shoot bullet objects
- . Bullet objects should collide with enemy objects
- . Bullet objects should not collide with player characters
- . Player characters should collide with enemy objects
- . Player and enemies collide with the game world tiles
+- Player characters that shoot bullet objects
+- Bullet objects should collide with enemy objects
+- Bullet objects should not collide with player characters
+- Player characters should collide with enemy objects
+- Player and enemies collide with the game world tiles
 
 The physics engine allows you to group your physics objects and filter how they should collide. This is handled by named _collision groups_. For each collision object you create two properties control how the object collides with other objects:
 
@@ -111,19 +111,17 @@ Note that each collision involves two objects and it is important that both obje
 To achieve the collision scheme outlined for the hypothetical shooter game above, the following setup would work:
 
 Players
-: _Group_: "players", _Mask_: "world, enemies"
+: *Group* = `players`, *Mask* =  `world, enemies`
 
 Bullet
-: _Group_: "bullets", _Mask_: "enemies"
+: *Group*: `bullets`, *Mask*: `enemies`
 
 Enemies
-: _Group_: "enemies", _Mask_: "players, bullets"
+: *Group*: `enemies`, *Mask*: `players, bullets`
 
 World
-: _Group_: "world", _Mask_: "players, enemies"
+: *Group*: `world`, *Mask*: `players, enemies`
 
-
-[[anchor-tcs]]
 ## Tilesource collision shapes
 
 The Defold editor has a tool that allows you to quickly generate physics shapes for a tilesource. In the tilesource editor, simply choose the image you wish to use as basis for collision. The editor will automatically generate a convex shape around each tile, taking into account pixels that are not 100% transparent:
@@ -154,59 +152,57 @@ To use the collision shapes from the Tile Source, create a collisionobject in th
 
 When two objects collide, the engine will broadcast messages to all components in both objects:
 
-## `collision_response`
+**`collision_response`**
 
 This message is sent for all collision objects. It has the following fields set:
 
-other_id
-: the id of the instance the collision object collided with (hash)
-
-other_position
-: the world position of the instance the collision object collided with (vector3)
+`other_id`
+: the id of the instance the collision object collided with (`hash`)
 
-group
-: the collision group of the other collision object (hash)
+`other_position`
+: the world position of the instance the collision object collided with (`vector3`)
 
+`group`
+: the collision group of the other collision object (`hash`)
 
 The collision_response message is only adequate to resolve collisions where you don't need any details on the actual intersection of the objects, for example if you want to detect if a bullet hits an enemy. There is only one of these messages sent for any colliding pair of objects each frame.
 
-## `contact_point_response`
+**`contact_point_response`**
 
 This message is sent when one of the colliding objects is Dynamic or Kinematic. It has the following fields set:
 
-position
-: world position of the contact point (vector3)
+`position`
+: world position of the contact point (`vector3`).
 
-normal
-: normal in world space of the contact point, which points from the other object towards the current object (vector3)
+`normal`
+: normal in world space of the contact point, which points from the other object towards the current object (`vector3`).
 
-relative_velocity
-: the relative velocity of the collision object as observed from the other object (vector3)
+`relative_velocity`
+: the relative velocity of the collision object as observed from the other object (`vector3`).
 
-distance
-: the penetration distance between the objects -- non negative (number)
+`distance`
+: the penetration distance between the objects -- non negative (`number`).
 
-applied_impulse
-: the impulse the contact resulted in (number)
+`applied_impulse`
+: the impulse the contact resulted in (`number`).
 
-life_time
-: life time of the contact (not currently used!) (number)
+`life_time`
+: (*not currently used!*) life time of the contact (`number`).
 
-mass
-: the mass of the current collision object in kg (number)
+`mass`
+: the mass of the current collision object in kg (`number`).
 
-other_mass
-: the mass of the other collision object in kg (number)
+`other_mass`
+: the mass of the other collision object in kg (`number`).
 
-other_id
-: the id of the instance the collision object is in contact with (hash)
+`other_id`
+: the id of the instance the collision object is in contact with (`hash`).
 
-other_position
-: the world position of the other collision object (vector3)
-
-group
-: the collision group of the other collision object (hash)
+`other_position`
+: the world position of the other collision object (`vector3`).
 
+`group`
+: the collision group of the other collision object (`hash`).
 
 For a game or application where you need to separate objects perfectly, the `contact_point_response` message gives you all information you need. However, note that for any given collision pair, a number of `contact_point_response` message can be received each frame.
 
@@ -214,11 +210,11 @@ For a game or application where you need to separate objects perfectly, the `con
 
 Triggers are light weight collision objects. In a trigger collision `collision_response` messages are sent. In addition, triggers also send a special `trigger_response` message when the collision begins and end. The message has the following fields:
 
-other_id
-: the id of the instance the collision object collided with (hash)
+`other_id`
+: the id of the instance the collision object collided with (`hash`).
 
-enter
-: `true` if the interaction was an entry into the trigger, `false` if it was an exit.
+`enter`
+: `true` if the interaction was an entry into the trigger, `false` if it was an exit. (`boolean`).
 
 
 ## Resolving Kinematic collisions
@@ -281,26 +277,24 @@ end
 
 ## Best practices
 
-## Triggers
-
-Trigger collision objects are sometimes too limited. Suppose you want a trigger that controls the intensity of a sound--the further the player moves into the trigger, the more intense the sound. This scenario requires a trigger that provides the penetration distance in the trigger. For this, a plain trigger collision object won’t do. Instead, you can set up a Kinematic object and never performing any separation of collisions but instead only registering them and use the collision data.
+Triggers
+: Trigger collision objects are sometimes too limited. Suppose you want a trigger that controls the intensity of a sound--the further the player moves into the trigger, the more intense the sound. This scenario requires a trigger that provides the penetration distance in the trigger. For this, a plain trigger collision object won’t do. Instead, you can set up a Kinematic object and never performing any separation of collisions but instead only registering them and use the collision data.
 
 ::: sidenote
 Kinematic objects are more expensive than triggers, so use them wisely.
 :::
 
-## Choosing between Dynamic or Kinematic objects
-
-If you are making a game with a player character (of some sort) that you maneuver through a level, it might seem like a good idea to create the player character as a Dynamic physics object and the world as a Static physics object. Player input is then handled by applying various forces on the player object.
+Choosing between Dynamic or Kinematic objects
+: If you are making a game with a player character (of some sort) that you maneuver through a level, it might seem like a good idea to create the player character as a Dynamic physics object and the world as a Static physics object. Player input is then handled by applying various forces on the player object.
 
-Going down that path is possible, but it is extremely hard to achieve great results. Your game controls will likely feel generic—like thousands of other games, since it is implemented the same way on the same physics engine. The problem boils down to the fact that the Box2D physics simulation is a realistic Newtonian simulation whereas a platformer is usually fundamentally different. You will therefore have to fight hard to make a Newtonian simulation behave in non-Newtonian fashion.
+  Going down that path is possible, but it is extremely hard to achieve great results. Your game controls will likely feel generic—like thousands of other games, since it is implemented the same way on the same physics engine. The problem boils down to the fact that the Box2D physics simulation is a realistic Newtonian simulation whereas a platformer is usually fundamentally different. You will therefore have to fight hard to make a Newtonian simulation behave in non-Newtonian fashion.
 
-One immediate problem is what should happen at edges. With a dynamic simulation running, the player physics object (here set up as a box) behaves like a realistic box and will tip over any edges.
+  One immediate problem is what should happen at edges. With a dynamic simulation running, the player physics object (here set up as a box) behaves like a realistic box and will tip over any edges.
 
-![Dynamic physics](images/physics/physics_dynamic.png)
+  ![Dynamic physics](images/physics/physics_dynamic.png)
 
-This particular problem can be solved by setting the "Locked Rotation" property in the character's collision object. However, the example illustrates the core of the problem which is that the behavior of the character should be under the control of _you_, the designer/programmer and not being directly controlled by a physics simulation over which you have very limited control.
+  This particular problem can be solved by setting the "Locked Rotation" property in the character's collision object. However, the example illustrates the core of the problem which is that the behavior of the character should be under the control of _you_, the designer/programmer and not being directly controlled by a physics simulation over which you have very limited control.
 
-So it is highly recommended that you implement your player character as a Kinematic physics object. Use the physics engine to detect collisions and deal with collisions and object separations as you need. Such an approach will initially require more work, but allows you to really design and fine-tune the player experience into something really good and unique.
+  So it is highly recommended that you implement your player character as a Kinematic physics object. Use the physics engine to detect collisions and deal with collisions and object separations as you need. Such an approach will initially require more work, but allows you to really design and fine-tune the player experience into something really good and unique.
 
 (Some of the graphic assets used are made by Kenney: http://kenney.nl/assets)

docs/en/manuals/project-settings.md

@@ -1,8 +1,11 @@
-# Project settings
+---
+title: Defold project settings
+brief: This manual describes how project specific settings work in Defold.
+---
 
-This manual describes how project specific Defold settings work.
+# Project settings
 
-The file "game.project" contains all project wide settings. It must stay in the root of the project and must be named "game.project". The first thing the engine does when starting up and launching your game is looking for this file.
+The file *game.project* contains all project wide settings. It must stay in the root of the project and must be named *game.project*. The first thing the engine does when starting up and launching your game is looking for this file.
 
 Every setting in the file belongs to a category. The format of the file is simple text and can be edited by any standard text editor. The format looks like this:
 
@@ -23,13 +26,13 @@ main_collection = /main/main.collectionc
 
 which means that the setting *main_collection* belongs to the *bootstrap* category.
 Whenever a file reference is used, like the example above, the path needs to be appended with a 'c' character, which means you're referencing the compiled version of the file.
-Also note that your project root is treated as the real root, which is why there is an initial '/' in the setting path.
+Also note that the folder containing *game.project* will be the project root, which is why there is an initial '/' in the setting path.
 
-Below are all the available settings, arranged by section. Some settings are not yet exposed in the settings editor (these are marked "hidden setting" below), but can be set manually by right clicking "game.project" and selecting "Open With > Text Editor".
+Below are all the available settings, arranged by section. Some settings are not yet exposed in the settings editor (these are marked "hidden setting" below), but can be set manually by right clicking "game.project" and selecting <kbd>Open With ▸ Text Editor</kbd>.
 
 ## Setting config values on engine startup
 
-When the engine starts, it is possible to provide config values from the command line that override the "game.project" settings:
+When the engine starts, it is possible to provide config values from the command line that override the *game.project* settings:
 
 ```bash
 # Specify a bootstap collection
@@ -39,7 +42,7 @@ $ dmengine --config=bootstrap.main_collection=/my.collectionc
 $ dmengine --config=test.my_value=4711
 ```
 
-Custom values can (just as any other config value) be read with [sys.get_config()](/ref/sys/#sys.get_config).
+Custom values can---just as any other config value---be read with [`sys.get_config()`](/ref/sys/#sys.get_config).
 
 ## Project
 
@@ -50,7 +53,7 @@ version
 : The version of the application.
 
 write_log
-: When checked the engine will write a log file "log.txt" in the project root. When running on iOS, the log file can be accessed through iTunes and the *Apps* tab and the *File Sharing* section. On Android, the file is stored in the apps external storage. When running the "dmengine" development app, you can view the log with:
+: When checked the engine will write a log file *log.txt* in the project root. When running on iOS, the log file can be accessed through iTunes and the *Apps* tab and the *File Sharing* section. On Android, the file is stored in the apps external storage. When running the *dmengine* development app, you can view the log with:
 
 ```bash
 $ adb shell cat /mnt/sdcard/Android/data/com.defold.dmengine/files/log.txt
@@ -66,8 +69,7 @@ custom_resources (hidden setting)
 : A comma separated list of resources that will be included in the project. If directories are specified, all files and directories in that directory are recursively included.
 
 bundle_resources (hidden setting)
-: A directory containing resource files and folders that should be copied as-is into the resulting package when bundling. The directory is specified with an absolute path from the project root, for example "/res". The resource directory should contain subfolders named by `platform`, or `architecure-platform`. Supported platforms are `ios`, `android` and `osx`. Supported arc-platform pairs are `armv7-ios`, `arm64-ios`, `armv7-android` and `x86_64-osx`. A subfolder named `common` is also allowed, containing resource files common for all platforms.
-
+: A directory containing resource files and folders that should be copied as-is into the resulting package when bundling. The directory is specified with an absolute path from the project root, for example `/res`. The resource directory should contain subfolders named by `platform`, or `architecure-platform`. Supported platforms are `ios`, `android` and `osx`. Supported arc-platform pairs are `armv7-ios`, `arm64-ios`, `armv7-android` and `x86_64-osx`. A subfolder named `common` is also allowed, containing resource files common for all platforms.
 
 ## Bootstrap
 
@@ -77,25 +79,21 @@ main_collection
 render
 : Which render file to use, which defines the render pipeline, `/builtins/render/default.renderc` by default.
 
-
 ## Library
 
 include_dirs
 : A space separated list of directories that should be shared from your project via library sharing.
 
-
 ## Script
 
 shared_state
-: Check to share a single LUA state between all script types, checked by default.
-
+: Check to share a single Lua state between all script types, checked by default.
 
 ## Tracking
 
 app_id
 : A unique tracking ID for this project. The project tracking ID an be found on the project dashboard.
 
-
 ## Display
 
 width
@@ -114,7 +112,7 @@ fullscreen
 : Check if the application should start full screen. If unchecked, the application runs windowed.
 
 update_frequency
-: Frame update frequency, `60` by default. Valid values are `60`, `30`, `20`, `15`, `12`, `10`, `6`, `5`, `4`, `3`, `2` and `1`.
+: Frame update frequency, `60` by default. Valid values are `60`, `30`, `20`, `15`, `12`, `10`, `6`, `5`, `4`, `3`, `2` or `1`.
 
 variable_dt
 : Check if time step should be measured against actual time or be fixed (set to *update_frequency*).
@@ -125,7 +123,6 @@ display_profiles
 dynamic_orientation
 : Check if the app should dynamically switch between portrait and landscape on device rotation. Note that the development app does not currently respect this setting.
 
-
 ## Physics
 
 type
@@ -138,7 +135,7 @@ debug
 : Check if physics should be visualized for debugging.
 
 debug_alpha
-: Alpha component value for visualized physics, `0` -- `1`. `0.9` by default.
+: Alpha component value for visualized physics, `0`--`1`. The value is `0.9` by default.
 
 world_count
 : Max number of concurrent physics worlds, `4` by default (careful, they waste memory).
@@ -150,7 +147,7 @@ gravity_z
 : World gravity along z-axis, `0` by default.
 
 scale
-: How to scale the physics worlds in relation to the game world for numerical precision,  `0.01` -- `1`. `0.02` by default.
+: How to scale the physics worlds in relation to the game world for numerical precision, `0.01`--`1`. The value is `0.02` by default.
 
 debug_scale
 : How big to draw unit objects in physics, like triads and normals, `30` by default.
@@ -164,7 +161,6 @@ max_contacts
 contact_impulse_limit
 : Ignore contact impulses with values less than this setting, `0` by default.
 
-
 ## Graphics
 
 default_texture_min_filter
@@ -179,7 +175,6 @@ max_debug_vertices
 texture_profiles
 : The texture profiles file to use for this project, `/builtins/graphics/default.texture_profiles` by default.
 
-
 ## Input
 
 repeat_delay
@@ -194,7 +189,6 @@ gamepads
 game_binding
 : File reference of the input config file, which maps hardware inputs to actions, `/input/game.input_bindingc` by default.
 
-
 ## Resource
 
 http_cache
@@ -206,23 +200,20 @@ uri
 max_resources
 : The max number of resources that can be loaded at the same time, `1024` by default.
 
-
 ## Network
 
 http_timeout
 : The HTTP timeout in seconds. Set to `0` to disable timeout, which is the default.
 
-
 ## Collection
 
 max_instances
 : Max number of game object instances in a collection, `1024` by default.
 
-
 ## Sound
 
 gain
-: Global gain (volume), `0` -- `1`, `1` by default.
+: Global gain (volume), `0`--`1`, The value is `1` by default.
 
 max_sound_data
 : Max number of different sounds, `128` by default.
@@ -236,7 +227,6 @@ max_sound_sources
 max_sound_instances
 : Max number of concurrent sound instances, `256` by default.
 
-
 ## Sprite
 
 max_count
@@ -245,19 +235,16 @@ max_count
 subpixels
 : Check to allow sprites to appear unaligned with respect to pixels, checked by default.
 
-
 ## Spine
 
 max_count
 : Max number of spine models, `128` by default.
 
-
 ## GUI
 
 max_count
 : Max number of GUI components, `64` by default.
 
-
 ## Label
 
 max_count
@@ -266,7 +253,6 @@ max_count
 sub_pixels
 : Check to allow lables to appear unaligned with respect to pixels, checked by default.
 
-
 ## Particle FX
 
 max_emitter_count
@@ -275,32 +261,28 @@ max_emitter_count
 max_particle_count
 : The max number of concurrent particles, `1024` by default.
 
-
 ## Collection proxy
 
 max_count
 : Max number of collection proxies, `8` by default.
 
-
 ## Collection factory
 
 max_count
 : Max number of collection factories, `128` by default.
 
-
 ## Factory
 
 max_count
 : Max number of game object factories, `128` by default.
 
-
 ## iOS
 
 app_icon_WxH
-: Image file to use as application icon at given width and height dimensions W &times; H.
+: Image file to use as application icon at given width and height dimensions `W` &times; `H`.
 
 launch_image_WxH
-: Image file to use as application launch image for resolution width and height dimensions W &times; H. Note that iOS selects the display resolution based on the launch image.
+: Image file to use as application launch image for resolution width and height dimensions `W` &times; `H`. Note that iOS selects the display resolution based on the launch image.
 
 pre_rendered_icons
 : (iOS 6 and earlier) Check if your icons are pre-rendered. If this is unchecked the icons will get a glossy highlight added automatically.
@@ -311,16 +293,15 @@ bundle_identifier
 infoplist
 : If specified, use this info.plist file when bundling your app.
 
-
 ## Android
 
 app_icon_WxH
-: Image file to use as application icon at given width and height dimensions W &times; H.
+: Image file to use as application icon at given width and height dimensions `W` &times; `H`.
 
 version_code
 : An integer value indicating the version of the app. Increase the value for each subsequent update.
 
-push_icon_NNN
+push_icon_SIZE
 : Image files to be used as custom push notification icon on Android. The icons will automatically be used for both local or remote push notifications. If not set the application icon will be used by default.
 
 push_field_title
@@ -344,7 +325,6 @@ iap_provider
 input_method
 : Specifies which method to use to get keyboard input on Android devices. Valid options are `KeyEvent` (old method) and `HiddenInputField` (new). `KeyEvent` by default.
 
-
 ## OS X
 
 app_icon
@@ -356,13 +336,11 @@ infoplist
 bundle_identifier
 : The bundle identifier lets OS X recognize updates to your app. Your bundle ID must be registered with Apple and be unique to your app. You cannot use the same identifier for both iOS and OS X apps.
 
-
 ## Windows
 
 app_icon
 : Image file to use as application icon on Windows.
 
-
 ## HTML5
 
 set_custom_heap_size
@@ -394,7 +372,6 @@ archive_location_suffix
 appid (hidden setting)
 : The application id as issued by Facebook.
 
-
 ## IAP
 
 auto_finish_transactions

docs/en/manuals/properties.md

@@ -1,20 +1,20 @@
-Properties
-==========
+---
+title: Properties in Defold
+brief: This manual explains what types of properties exist in Defold, and how they are used and animated.
+---
 
-This manual explains what types of properties exist in Defold, and how they are used and animated.
+# Properties
 
-## Property types
-
-In Defold, there are different sets of properties:
+Defold exposes properties for game objects, components and GUI nodes that can be read, set and animated. The following types of properties exist:
 
 * System defined game object transforms (position, rotation and scale) and component specific properties (for example a sprite's pixel size or a collision object's mass)
-* Script component properties defined in Lua scripts (see [Script properties documentation](/manuals/script-properties) for details)
+* User defined script component properties defined in Lua scripts (see [Script properties documentation](/manuals/script-properties) for details)
 * GUI node properties
 * Shader constants defined in shaders and material files (see [Material documentation](/manuals/material) for details)
 
 Depending on where a property is found, you access it via a generic function, or a property-specific function. Many of the properties can be automatically animated. Animating properties through the built-in system is highly recommended over manipulating the properties yourself (inside an `update()` function), both for performance reasons as well as convenience.
 
-Composite properties of type vector3, vector4 or quaternion also expose their sub-components (x, y, z and w). You can address the components individually by suffixing the name with a dot '.' and the name of the component. For example, to set the x-component of a game object's position:
+Composite properties of type `vector3`, `vector4` or `quaternion` also expose their sub-components (`x`, `y`, `z` and `w`). You can address the components individually by suffixing the name with a dot (`.`) and the name of the component. For example, to set the x-component of a game object's position:
 
 ```lua
 -- Set the x positon of "game_object" to 10.
@@ -38,220 +38,105 @@ local node = gui.get_node("button")
 local color = gui.get_color(node)
 ```
 
-## System defined game object and component properties
-
-All game objects, and some component types have properties that can be read and manipulated in runtime. Read these values with `[go.get()](/ref/go#go.get)` and write them with `[go.set()](/ref/go#go.set)`. Depending on the property value type, you can animate the values with `[go.animate()](/ref/go#go.animate)`. A small set of the properties are read only.
+## Game object and component properties
 
-[mark]#get#
-: Can be read with `[go.get()](/ref/go#go.get)`.
+All game objects, and some component types have properties that can be read and manipulated in runtime. Read these values with [`go.get()`](/ref/go#go.get) and write them with [`go.set()`](/ref/go#go.set). Depending on the property value type, you can animate the values with [`go.animate()`](/ref/go#go.animate). A small set of the properties are read only.
 
+`get`{.mark}
+: Can be read with [`go.get()`](/ref/go#go.get).
 
-[mark]#get`set#
-: Can be read with `[go.get()](/ref/go#go.get)+ and written with `[go.set()](/ref/go#go.set)`. Numerical values can be animated with `[go.animate()](/ref/go#go.animate)`
-
+`get+set`{.mark}
+: Can be read with [`go.get()`](/ref/go#go.get) and written with [`go.set()`](/ref/go#go.set). Numerical values can be animated with [`go.animate()`](/ref/go#go.animate).
 
 ::: sidenote
 Legacy functions for reading and writing game object properties also exist. They are `go.get_position()`, `go.set_position()`, `go.get_rotation()`, `go.set_rotation()`,  and so forth.
 :::
 
-## GAME OBJECT PROPERTIES
-
-[.table-striped,cols="2,6,2,2"]
-|===
-|*position*
-|The local position of the game object.
-|[type]#vector3#
-|[mark]#get`set#
-
-|*rotation*
-|The local rotation of the game object, expressed as a quaternion.
-|[type]#quaternion#
-|[mark]#get`set#
-
-|*euler*
-|The local rotation of the game object, expressed as Euler angles in degrees.
-|[type]#vector3#
-|[mark]#get`set#
-
-|*scale*
-|The local uniform scale of the game object, expressed as a multiplier. 1 is 100% (original) scale.
-|[type]#number#
-|[mark]#get`set#
-|===
-
-## SPRITE COMPONENT PROPERTIES
-
-[.table-striped,cols="2,6,2,2"]
-|===
-|*size*
-|The non scaled size of the sprite--its size as taken from the source atlas.
-|[type]#vector3#
-|[mark]#get#
-
-|*scale*
-|Non uniform scaling of the sprite, expressed as a vector where each component contains a multiplier along each axis. To double the size in x and y, provide vmath.vector3(2.0, 2.0, 0)
-|[type]#vector3#
-|[mark]#get`set#
-|===
-
-## COLLISION OBJECT COMPONENT PROPERTIES
-
-[.table-striped,cols="2,6,2,2"]
-|===
-|*mass*
-|The mass of the collision object.
-|[type]#number#
-|[mark]#get#
-
-|*linear_velocity*
-|The current linear velocity for the collision object.
-|[type]#vector3#
-|[mark]#get#
-
-|*angular_velocity*
-|The current angular velocity for the collision object.
-|[type]#vector3#
-|[mark]#get#
-
-|*linear_damping*
-|Linear damping for the collision object.
-|[type]#vector3#
-|[mark]#get`set#
-
-|*angular_damping*
-|Angular damping for the collision object.
-|[type]#vector3#
-|[mark]#get`set#
-|===
-
-## SPINE MODEL COMPONENT PROPERTIES
-
-[.table-striped,cols="2,6,2,2"]
-|===
-|*animation*
-|The current animation.
-|[type]#hash#
-|[mark]#get#
-
-|*skin*
-|The currently applied model skin. (cannot be animated!)
-|[type]#hash#
-|[mark]#get`set#
-
-|*cursor*
-|The current position (between 0-1) of the animation playback cursor.
-|[type]#number#
-|[mark]#get`set#
-
-|*playback_rate*
-|The playback rate of the animation. A multiplier to the animation playback rate.
-|[type]#number#
-|[mark]#get`set#
-|===
-
-## MODEL (3D) COMPONENT PROPERTIES
-
-[.table-striped,cols="2,6,2,2"]
-|===
-|*animation*
-|The current animation.
-|[type]#hash#
-|[mark]#get#
-
-|*cursor*
-|The current position (between 0-1) of the animation playback cursor.
-|[type]#number#
-|[mark]#get`set#
-
-|*playback_rate*
-|The playback rate of the animation. A multiplier to the animation playback rate.
-|[type]#number#
-|[mark]#get`set#
-|===
+*GAME OBJECT PROPERTIES*
+
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *position* | The local position of the game object. | `vector3`.      | `get+set`{.mark} |
+| *rotation* | Local rotation of game object, expressed as quaternion.  | `quaternion` | `get+set`{.mark} |
+| *euler*    | Local rotation of game object, Euler angles. | `vector3` | `get+set`{.mark} |
+| *scale*    | Local uniform scale of the game object, multiplier. | `number` | `get+set`{.mark} |
+
+*SPRITE COMPONENT PROPERTIES*
+
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *size*.    | The non scaled size of the sprite--its size as taken from the source atlas. | `vector3` | `get`{.mark} |
+| *scale* | Non uniform scaling of the sprite, expressed as a vector where each component contains a multiplier along each axis. To double the size in x and y, provide vmath.vector3(2.0, 2.0, 0) | `vector3` | `get+set`{.mark}|
+
+*COLLISION OBJECT COMPONENT PROPERTIES*
+
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *mass*     | The mass of the collision object. | `number` | `get`{.mark} |
+| *linear_velocity* | The current linear velocity for the collision object. | `vector3` | `get`{.mark} |
+| *angular_velocity* | The current angular velocity for the collision object. | `vector3` | `get`{.mark} |
+| *linear_damping* | Linear damping for the collision object. | `vector3` | `get+set`{.mark} |
+| *angular_damping* | Angular damping for the collision object. | `vector3` | `get+set`{.mark} |
+
+*SPINE MODEL COMPONENT PROPERTIES*
+
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *animation* | The current animation. | `hash` | `get`{.mark} |
+| *skin*.     | The currently applied model skin. (cannot be animated!) | `hash` | `get+set`{.mark} |
+| *cursor*   | The current position (between 0-1) of the animation playback cursor. | `number` | get+set`{.mark} |
+| *playback_rate* | The playback rate of the animation. A multiplier to the animation playback rate. | `number` | `get+set`{.mark} |
+
+*MODEL (3D) COMPONENT PROPERTIES*
+
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *animation* | The current animation.                | `hash`          | `get`{.mark}     |
+| *cursor*.  | Position (between 0--1) of playback cursor. | `number`   | `get+set`{.mark} |
+| *playback_rate* | The playback rate of the animation. A multiplier to the animation playback rate. | `number` | `get+set`{.mark} |
 
 ## GUI node properties
 
 GUI nodes also contain properties, but they are read and written through special getter and setter functions. For each property there exist one get- and one set- function. There is also a set of constants defined to use as reference to the properties when animating them. If you need to refer to separate property components you have to use the string name of the property, or a hash of the string name.
 
-* "position" (or `gui.PROP_POSITION`)
-* "rotation" (or `gui.PROP_ROTATION`)
-* "scale" (or `gui.PROP_SCALE`)
-* "color" (or `gui.PROP_COLOR`)
-* "outline" (or `gui.PROP_OUTLINE`)
-* "shadow" (or `gui.PROP_SHADOW`)
-* "size" (or `gui.PROP_SIZE`)
-* "fill_angle" (or `gui.PROP_FILL_ANGLE`)
-* "inner_radius" (or `gui.PROP_INNER_RADIUS`)
-* "slice9" (or `gui.PROP_SLICE9`)
+* `position` (or `gui.PROP_POSITION`)
+* `rotation` (or `gui.PROP_ROTATION`)
+* `scale` (or `gui.PROP_SCALE`)
+* `color` (or `gui.PROP_COLOR`)
+* `outline` (or `gui.PROP_OUTLINE`)
+* `shadow` (or `gui.PROP_SHADOW`)
+* `size` (or `gui.PROP_SIZE`)
+* `fill_angle` (or `gui.PROP_FILL_ANGLE`)
+* `inner_radius` (or `gui.PROP_INNER_RADIUS`)
+* `slice9` (or `gui.PROP_SLICE9`)
 
 Note that all color values are encoded in a vector4 where the components correspond to the RGBA values:
 
-x
+`x`
 : The red color component
 
-y
+`y`
 : The green color component
 
-z
+`z`
 : The blue color component
 
-w
+`w`
 : The alpha component
 
-
 ## GUI NODE PROPERTIES
 
-[.table-striped,cols="2,6,2,2"]
-|===
-|*color*
-|The face color of the node.
-|[type]#vector4#
-|gui.get_color() gui.set_color()
-
-|*outline*
-|The outline color of the node.
-|[type]#vector4#
-|gui.get_outline() gui.set_outline()
-
-|*position*
-|The position of the node.
-|[type]#vector3#
-|gui.get_position() gui.set_position()
-
-|*rotation*
-|The rotation of the node expressed as Euler angles--degrees rotated around each axis.
-|[type]#vector3#
-|gui.get_rotation() gui.set_rotation()
-
-|*scale*
-|The scale of the node expressed as a multiplier along each axis.
-|[type]#vector3#
-|gui.get_scale() gui.set_scale()
-
-|*shadow*
-|The shadow color of the node.
-|[type]#vector4#
-|gui.get_shadow() gui.set_shadow()
-
-|*size*
-|The unscaled size of the node.
-|[type]#vector3#
-|gui.get_size() gui.set_size()
-
-|*fill_angle*
-|The fill angle of a pie node expressed as degrees counter-clockwise.
-|[type]#number#
-|gui.get_fill_angle() gui.set_fill_angle()
-
-|*inner_radius*
-|The inner radius of a pie node.
-|[type]#number#
-|gui.get_inner_radius() gui.set_inner_radius()
-
-|*slice9*
-|The edge distances of a slice9 node.
-|[type]#vector4#
-|-
-|===
+| property   | description                            | type            |                  |
+| ---------- | -------------------------------------- | --------------- | ---------------- |
+| *color*.   | The face color of the node.            | `vector4`.      | `gui.get_color()` `gui.set_color()` |
+| *outline*. | The outline color of the node.         | `vector4`       | `gui.get_outline()` `gui.set_outline()` |
+| *position* | The position of the node. | `vector3` | `gui.get_position()` `gui.set_position()` |
+| *rotation* | The rotation of the node expressed as Euler angles--degrees rotated around each axis. | `vector3` | `gui.get_rotation()` `gui.set_rotation()` |
+| *scale* | The scale of the node expressed as a multiplier along each axis. | `vector3` |`gui.get_scale()` `gui.set_scale()` |
+| *shadow* | The shadow color of the node. | `vector4` | `gui.get_shadow()` `gui.set_shadow()` |
+| *size* | The unscaled size of the node. | `vector3` | `gui.get_size()` `gui.set_size()` |
+| *fill_angle* | The fill angle of a pie node expressed as degrees counter-clockwise. | `number` | `gui.get_fill_angle()` `gui.set_fill_angle()` |
+| *inner_radius* | The inner radius of a pie node. | `number` | `gui.get_inner_radius()` `gui.set_inner_radius()` |
+| *slice9* | The edge distances of a slice9 node. | `vector4` | |
 
 

docs/en/manuals/push.md

@@ -1,9 +1,9 @@
-= Push notifications
-:location: documentation manuals extensions
-:type: manual
+---
+title: iOS and Android push notifications in Defold
+brief: This document describes how to set up and implement remote and local iOS and Android push notifications for your game or application.
+---
 
-This document describes how to set up and implement remote and local push
-notifications for your game or application.
+# Push notifications
 
 Push notifications are available on iOS and Android devices and allow your game to inform the player about changes and updates. The core functionality is similar between iOS and Android but there are some platform specific differences that you need to consider.
 
@@ -37,61 +37,61 @@ Make sure that you create a new provisioning profile, from the AppID and that yo
 
 Note that it can take a while for Apple's sandbox servers to update so you might not get push to work immediately. Be patient.
 
-[[above-code]]
 Now it's time to run some test code:
 
-```
+<a name="above-code"></a>
+```lua
 local function push_listener(self, payload, origin)
-	-- The payload arrives here.
-	pprint(payload)
+    -- The payload arrives here.
+    pprint(payload)
 end
 
 function init(self)
-	local sysinfo = sys.get_sys_info()
-	if sysinfo.system_name == "Android" then
-		msg.post("#", "push_android")
-	elseif sysinfo.system_name == "iPhone OS" then
-		msg.post("#", "push_ios")	
-	end
+    local sysinfo = sys.get_sys_info()
+    if sysinfo.system_name == "Android" then
+        msg.post("#", "push_android")
+    elseif sysinfo.system_name == "iPhone OS" then
+        msg.post("#", "push_ios")   
+    end
 end
 
 function on_message(self, message_id, message)
-	if message_id == hash("push_ios") then
-		local alerts = {push.NOTIFICATION_BADGE, push.NOTIFICATION_SOUND, push.NOTIFICATION_ALERT}
-		push.register(alerts, function (self, token, error)
-			if token then
-				local t = ""
-				for i = 1,#token do
-					t = t .. string.format("%02x", string.byte(token, i))
-				end
-				-- Print the device token
-				print(t)
-			else
-				-- Error
-				print(error.error)
-			end
-		end)	
-		push.set_listener(push_listener)
-	elseif message_id == hash("push_android") then
-		push.register(nil, function (self, token, error)
-			if token then
-				-- Print the device token
-				print(token)
-			else
-				-- Error
-				print(error.error)
-			end
-		end)
-		push.set_listener(push_listener)
-	end
+    if message_id == hash("push_ios") then
+        local alerts = {push.NOTIFICATION_BADGE, push.NOTIFICATION_SOUND, push.NOTIFICATION_ALERT}
+        push.register(alerts, function (self, token, error)
+            if token then
+                local t = ""
+                for i = 1,#token do
+                    t = t .. string.format("%02x", string.byte(token, i))
+                end
+                -- Print the device token
+                print(t)
+            else
+                -- Error
+                print(error.error)
+            end
+        end)    
+        push.set_listener(push_listener)
+    elseif message_id == hash("push_android") then
+        push.register(nil, function (self, token, error)
+            if token then
+                -- Print the device token
+                print(token)
+            else
+                -- Error
+                print(error.error)
+            end
+        end)
+        push.set_listener(push_listener)
+    end
 end
 ```
 
 If all goes well the notification listener will be registered and we get a token that we can use:
 
-----
+```txt
 DEBUG:SCRIPT: 1f8ba7869b84b10df69a07aa623cd7f55f62bca22cef61b51fedac643ec61ad8
-----
+```
 
 If you're running a push test app, you can now try to send notifications to your device using the device token and the APN service SSL certificate.
 
@@ -99,7 +99,7 @@ If you're running a push test app, you can now try to send notifications to your
 
 The notification should arrive to the client soon after you send it, from within your test application, arriving to the function `push_listener()`:
 
-----
+```txt
 DEBUG:SCRIPT: 
 {
   aps = {
@@ -108,7 +108,7 @@ DEBUG:SCRIPT:
     sound = default,
   }
 }
-----
+```
 
 And from the iOS homescreen:
 
@@ -127,11 +127,11 @@ On Android, you need the following information to send notifications:
 * A GCM Sender ID. This is built into the application.
 * A Server API Key to enable sending notifications through Google's servers.
 
-The setup is quite straightforward. Start by heading over to http://developers.google.com, click on "Android" and then "Google Cloud Messaging".
+The setup is quite straightforward. Start by heading over to http://developers.google.com, click on *Android* and then *Google Cloud Messaging*.
 
 ![Android getting started](images/push/push_android_get_started.png)
 
-A bit down the page there is a button saying "Get a configuration file".
+A bit down the page there is a button saying *Get a configuration file*.
 
 ![Android configuration file](images/push/push_android_configuration_file.png)
 
@@ -145,23 +145,23 @@ Copy the Sender ID and paste it into the *gcm_sender_id* field in your Defold pr
 
 Now everything is ready on the client. The [above code](#above-code) example works for Android as well. Run it and copy the device token id.
 
-----
+```txt
 DEBUG:SCRIPT: APA91bHkcKm0QHAMUCEQ_Dlpq2gzset6vh0cz46kDDV6230C5rFivyWZMCxGXcjxRDKg1PK4z1kWg3xnUVqSDiO_4_RiG8b8HeYJfaoW1ho4ukWYXjq5RE0Sy-JTyrhqRusUP_BxRTcE
-----
+```
 
 Now we have all information we need. Google's notifications are sent through a Web API so we can use *curl* to send test messages:
 
-----
+```sh
 $ curl  -X POST  -H "Content-type: application/json"  -H 'Authorization: key=SERVER_KEY' -d '{"registration_ids" : ["TOKEN_ID"], "data": {"alert": "Hello"}}' https://android.googleapis.com/gcm/send
-----
+```
 
-Replace *SERVER_KEY* and *TOKEN_ID* with your specific keys.
+Replace `SERVER_KEY` and `TOKEN_ID` with your specific keys.
 
 ## Local push notifications
 
 Local push notifications are supported as well as remote ones. After the regular setup you can schedule a local notification:
 
-```
+```lua
 -- Schedule a local push in 3 seconds
 local payload = '{"data" : {"field" : "Some value", "field2" : "Other value"}}'
 id, err = push.schedule(3, "A notification!", "Hello there", payload, { action = "get going" })
@@ -183,14 +183,14 @@ priority
 
 The API provides two functions to inspect what is currently scheduled. 
 
-```
+```lua
 n = push.get_scheduled(id)
 pprint(n)
 ```
 
 Which results in a table containing all details on the scheduled notification:
 
-----
+```txt
 DEBUG:SCRIPT: 
 {
   payload = {"data":{"field":"Some value","field2":"Other value"}},
@@ -199,18 +199,18 @@ DEBUG:SCRIPT:
   seconds = 19.991938,
   message = Hello there,
 }
-----
+```
 
-Note that *seconds* indicate the number of seconds left for the notification to fire. It is also possible to retreive a table with _all_ scheduled notifications:
+Note that `seconds` indicate the number of seconds left for the notification to fire. It is also possible to retreive a table with _all_ scheduled notifications:
 
-```
+```lua
 all_n = push.get_all_scheduled()
 pprint(all_n)
 ```
 
 Which results in a table pairing notification id:s with their respective data:
 
-----
+```txt
 DEBUG:SCRIPT: 
 {
   0 = {
@@ -235,5 +235,4 @@ DEBUG:SCRIPT:
     message = Please answer!,
   }
 }
-----
-
+```

docs/en/manuals/rendering.md

@@ -1,15 +1,15 @@
-Rendering
-=========
-:location: documentation manuals resources
-:type: manual
+---
+title: Rendering in Defold
+brief: This manual explains how Defold's render pipeline works and how you can program it.
+---
 
-Every object that is shown on screen by the engine: sprites, models, tiles, particles or GUI nodes are drawn by a rendering pipeline. This manual explains how this pipeline works and how you can program it.
+# Rendering
 
-By default, a pipeline is set up for you so every 2D object is drawn with the correct bitmap with the specified blending and at the correct Z depth--so you might not have to ever think about rendering beyond ordering and simple blending. For most 2D games, the default pipeline functions well, but your game might have special requirements. If that is the case, Defold allows you to write a tailor-made rendering pipeline.
+Every object that is shown on screen by the engine: sprites, models, tiles, particles or GUI nodes are drawn by a renderer. At the heart of the renderer is a render script that controls the render pipeline. By default, every 2D object is drawn with the correct bitmap with the specified blending and at the correct Z depth--so you might not have to ever think about rendering beyond ordering and simple blending. For most 2D games, the default pipeline functions well, but your game might have special requirements. If that is the case, Defold allows you to write a tailor-made rendering pipeline.
 
 ## The default renderer
 
-At the heart of the rendering pipeline is the _render script_. This is a regular Lua script with the functions `init()`, `update()` and `on_message()` and it is primarily used to interact with the underlying OpenGL rendering API. In the "Builtins" folder of your projects you can find the default render object ("default.render") and the default render script ("default.render_script"). The render object simply contains a reference to the current render script.
+At the heart of the rendering pipeline is the _render script_. This is a regular Lua script with the functions `init()`, `update()` and `on_message()` and it is primarily used to interact with the underlying OpenGL rendering API. In the "Builtins" folder of your projects you can find the default render resource (*default.render*) and the default render script (*default.render_script*). The render object simply contains a reference to the current render script.
 
 ::: sidenote
 Defold relies on OpenGL ES 2.0 for rendering on handheld devices. On desktops, regular Open GL is used. It is therefore possible to write shaders using features not available on OpenGL ES 2.0. Doing so will break cross compatibility.
@@ -21,10 +21,10 @@ Defold relies on OpenGL ES 2.0 for rendering on handheld devices. On desktops, r
 
 To set up a custom renderer, you can do as follows:
 
-1. Copy the files "default.render" and "default.render_script".
-2. Put the files somewhere in the project hierarchy, like in a "render" folder.
-3. Edit the new "default.render" object (or whatever you call it) and change the *script* property to refer to your copy of the render script.
-4. Change the *render* property under *Bootstrap* in the "game.project" settings file to refer to your copy of the "default.render" object.
+1. Copy the files *default.render* and *default.render_script*.
+2. Put the files somewhere in the project hierarchy, like in a *render* folder.
+3. Edit the new *default.render* object (or whatever you call it) and change the *script* property to refer to your copy of the render script.
+4. Change the *render* property under *Bootstrap* in the *game.project* settings file to refer to your copy of the *default.render* object.
 
 You can, of course, create a render script from scratch but it is a good idea to start with a copy of the default script if you are new to Defold and/or OpenGL ES rendering.
 

docs/en/manuals/scene-editing.md

@@ -1,8 +1,11 @@
-Scene editing
-=============
+---
+title: The Defold scene editor
+brief: Defold contains a number of editors, but the Scene Editor is the one used the most. This manual explains how to use it.
+---
 
-Defold contains a number of editors, but the Scene Editor is the one used the most. All Game Objects and Collections, as well as some component types are created and edited in this editor.
+# Scene editing
 
+Defold contains a number of editors, but the Scene Editor is the one used the most. All Game Objects and Collections, as well as some component types are created and edited in this editor.
 
 Pan
 : <kbd>Alt</kbd> + <kbd>Middle button</kbd> (three button mouse) or <kbd>Option + Ctrl</kbd> + <kbd>Mouse button</kbd> (one button mouse)

docs/en/manuals/script-properties.md

@@ -1,5 +1,9 @@
-Script properties
-=================
+---
+title: Script component properties
+brief: This manual explains how to add and use custom properties with script components.
+---
+
+# Script properties
 
 Script properties provide a simple and powerful way of exposing properties that control the behavior or look of a specific game object instance and allow non coders to change them in the editor.
 
@@ -55,7 +59,7 @@ function on_message(self, message_id, message, sender)
 end
 ```
 
-If the health reaches +0`, the script destroys the game object. Now suppose that you want to use the script in two different game objects, but want the game objects to have different amounts of health. With the function [go.property](/ref/go#go.property) you can declare the property a script property and it will be set by the specific game object instance:
+If the health reaches `0`, the script destroys the game object. Now suppose that you want to use the script in two different game objects, but want the game objects to have different amounts of health. With the function [`go.property()`](/ref/go#go.property) you can declare the property a script property and it will be set by the specific game object instance:
 
 ```lua
 -- self.health will be automatically set to 100 by default
@@ -71,7 +75,7 @@ function on_message(self, message_id, message, sender)
 end
 ```
 
-Any game object that includes the script can set the value specifically. Simply select the script node in the `Outline+ view in the editor and the property appears in the `Properties` view allowing you to edit it:
+Any game object that includes the script can set the value specifically. Simply select the script node in the *Outline* view in the editor and the property appears in the *Properties* view allowing you to edit it:
 
 ![Script Properties](images/script_properties/script_properties.png)
 
@@ -90,44 +94,42 @@ There are several ways the value of a script property can be referenced and used
 Through `self`
 : The `self` variable contains a reference to the script instance. Any defined script property is available as a stored member in `self`:
 
-
-```lua
-go.property("my_property", 1)
-
-...
-function init(self)
-    self.other_property = 2
-end
-
-function update(self, dt)
-    -- Read and write the property
-    if self.my_property == 1 and self.other_property == 3 then
-        self.my_property = 3
-    end
-end
-```
+  ```lua
+  go.property("my_property", 1)
+  
+  ...
+  function init(self)
+      self.other_property = 2
+  end
+  
+  function update(self, dt)
+      -- Read and write the property
+      if self.my_property == 1 and self.other_property == 3 then
+          self.my_property = 3
+      end
+  end
+  ```
 
 As a script component property
 : Many components expose properties (sprites expose `size` and `scale`, for instance). Any user-defined script property is avaliable for getting, setting and animating the same way as other component and game object properties:
 
-
-.myobject.script
-```lua
--- This script is attached to the object "myobject". The script component is called "script".
-go.property("my_property", 1)
-
-...
-```
-
-.another.script
-```lua
--- increase "my_property" in "myobject#script" by 1
-local val = go.get("myobject#script", "my_property")
-go.set("myobject#script", "my_property", val + 1)
-
--- animate "my_property" in "myobject#script"
-go.animate("myobject#script", "my_property", go.PLAYBACK_LOOP_PINGPONG, 100, go.EASING_LINEAR, 2.0)
-```
+  ```lua
+  -- myobject.script
+  -- This script is attached to the object "myobject". The script component is called "script".
+  go.property("my_property", 1)
+  
+  ...
+  ```
+  
+  ```lua
+  -- another.script
+  -- increase "my_property" in "myobject#script" by 1
+  local val = go.get("myobject#script", "my_property")
+  go.set("myobject#script", "my_property", val + 1)
+  
+  -- animate "my_property" in "myobject#script"
+  go.animate("myobject#script", "my_property", go.PLAYBACK_LOOP_PINGPONG, 100, go.EASING_LINEAR, 2.0)
+  ```
 
 ## Factory created objects
 

docs/en/manuals/shader.md

@@ -1,5 +1,9 @@
-Shaders
-=======
+---
+title: Shader programs in Defold
+brief: This manual describes vertex and fragment shaders in detail and how to use them in Defold.
+---
+
+# Shaders
 
 Shaders are at the core of graphics rendering. They are programs written in a C-like language called GLSL (GL Shading Language) that are run on the graphics hardware and perform operations on either the underlying 3D data (vertices) or the pixels that are rendered to the screen (the "fragments"). Shaders are general programs that can be used for an unlimited array of things, for instance:
 
@@ -49,42 +53,38 @@ A shader program consists of code that operate on data. Data is passed to and be
 Vertex attribute variables
 : Vertex attributes are used to send data to the vertex shader. Values are set per vertex and contain information about each vertex' position, normal, color and texture coordinate. These values are usually stored in the mesh created in a 3D modelling software and exported to Collada files that Defold can read.
 
-
 Attributes provided from the engine can be defined in the vertex shader using the `attribute` qualifier. Vertex attributes differs from uniforms in that they are set for each vertex. Uniforms are constant for all vertices. It is not possible to define attributes in the fragment shader.
 
 Uniform variables
 : Uniforms are values that are passed from the engine to vertex and fragment shader programs. They are declared in the shader programs with the `uniform` qualifier and must also be defined in the material file as *vertex_constant* or *fragment_constant* properties. Uniforms do not change from one execution of a shader program to the next within a particular rendering call (i.e. within a component). That is why they are called uniforms. In Defold, you define uniforms as material _constants_ in the component material file. The following constants are available:
 
-
-CONSTANT_TYPE_WORLD
+`CONSTANT_TYPE_WORLD`
 : The world matrix. Use to transform vertices into world space. For some component types, the vertices are already in world space when they arrive to the vertex program (due to batching). In those cases multiplying with the world matrix will yield the wrong results.
 
-CONSTANT_TYPE_VIEW
+`CONSTANT_TYPE_VIEW`
 : The view matrix. Use to transform vertices to view (camera) space.
 
-CONSTANT_TYPE_PROJECTION
+`CONSTANT_TYPE_PROJECTION`
 : The projection matrix. Use to transform vertices to screen space.
 
-CONSTANT_TYPE_VIEWPROJ
+`CONSTANT_TYPE_VIEWPROJ`
 : A matrix with the view and projection matrices already multiplied.
 
-CONSTANT_TYPE_WORLDVIEW
+`CONSTANT_TYPE_WORLDVIEW`
 : A matrix with the world and view projection matrices already multiplied.
 
-CONSTANT_TYPE_NORMAL
+`CONSTANT_TYPE_NORMAL`
 : A matrix to compute normal orientation. The world transform might include non-uniform scaling, which breaks the orthogonality of the combined world-view transform. The normal matrix is used to avoid issues with the direction when transforming normals. (The normal matrix is the transpose inverse of the world-view matrix).
 
-CONSTANT_TYPE_USER
+`CONSTANT_TYPE_USER`
 : A vector4 constant that you can use for any custom data you want to pass into your shader programs. You can set the initial value of the constant in the constant definition, but it is mutable through the functions `.set_constant()` and `.reset_constant()` for each component type (`sprite`, `model`, `spine`, `particlefx` and `tilemap`)
 
-
 Varying variables
 : Varying variables gives you an interface between the vertex and fragment shader. It is the output of a vertex shader and the input of a fragment shader. Varying variables are declared withe the `varying` qualifier and can be of type `float`, `vec2`, `vec3`, `vec4`, `mat2`, `mat3` and `mat4`.
 
-
 If you define a varying variable and set its value in the vertex shader, the value will be set for each vertex. During rasterization this value is interpolated for each fragment on the primitive being rendered. You can access the interpolated value in the fragment shader to determine what color to set on the fragment.
 
-For example, suppose that you define a varying variable +v+ and set it for each vertex of a triangle +A`, `B`, `C`, then each fragment within the boundaries of the triangle will have a value of `v+ that is an interpolation of the three values for the vertices:
+For example, suppose that you define a varying variable +v+ and set it for each vertex of a triangle `A`, `B`, `C`, then each fragment within the boundaries of the triangle will have a value of `v` that is an interpolation of the three values for the vertices:
 
 ![Varying interpolation](images/shader/varying_interpolation.png)
 
@@ -93,13 +93,11 @@ For example, suppose that you define a varying variable +v+ and set it for each
 Apart from the above types of user defined variables, a couple of built in variables also exist in GLSL:
 
 `gl_Position`​
-: A built in variable of type `vec4` that holds the output position of the current vertex in projection space. Set the value in the vertex shader. Note that this value has 4 component. +x`, `y`, `z+ and +w`. The `w+ component is used to calculate perspective correct interpolation. This value is normally 1.0 for each vertex _before any transformation matrix is applied_.
-
+: A built in variable of type `vec4` that holds the output position of the current vertex in projection space. Set the value in the vertex shader. Note that this value has 4 component. `x`, `y`, `z` and `w`. The `w` component is used to calculate perspective correct interpolation. This value is normally 1.0 for each vertex _before any transformation matrix is applied_.
 
 `gl_FragColor`
 : A built in variable of type `vec4` that holds the output RGBA color value for the current fragment. Set the value in the fragment shader.
 
-
 ## Texturing
 
 To enable texturing of primitives, image mapping and image sampling is required:
@@ -107,13 +105,11 @@ To enable texturing of primitives, image mapping and image sampling is required:
 UV map
 : This is a list mapping each vertex to a 2D texture coordinate. The map is typically generated in the 3D modelling program and stored in the mesh. The texture coordinates for each vertex are provided to the vertex shader as an attribute.
 
-
 ![UV coordinates](images/shader/uv_coordinates.png)
 
 Sampler variables
 : Samplers are uniform variables that are used to sample values from an image source. `sampler2D` and `samplerCube` type samplers are supported. `sampler2D` samples from a 2D image texture (a PNG or JPEG image) whereas `samplerCube` samples from a 6 image cubemap texture (defined in a `.cubemap` Defold resource file). You can use a sampler only in the GLSL standard library's texture lookup functions. These functions access the texture referred to by the sampler and take a texture coordinate as parameters. The [Material manual](/manuals/material) explains how to specify sampler settings.
 
-
 ## Vertex shaders
 
 The simplest possible vertex shader takes the incoming vertices and simply transform them by multiplying with the appropriate matrices that are passed to the shader as uniform values:
@@ -203,11 +199,7 @@ void main()
 }
 ```
 
-++`+
-<div class="image">
-    <iframe src="https://player.vimeo.com/video/206018645?autoplay=1&loop=1&title=0&byline=0&portrait=0" width="640" height="358" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
-</div>
-`+`+
+<iframe src="https://player.vimeo.com/video/206018645?autoplay=1&loop=1&title=0&byline=0&portrait=0" width="640" height="358" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen></iframe>
 
 ## Fragment shaders
 
@@ -229,8 +221,8 @@ A common use of fragment shaders is to texture the rendered primitives. First, t
 
 In this particular case the model is flat and square, so the texture would fit the model without any modification. But models are often complex and the fitting of the image needs to be done manually. To allow an arbitrary image texture to be mapped onto an arbitrary 3D model in an arbitrary manner, an _UV map_ is used. This map consists of 2D texture coordinates for each vertex in the model. A vertex shader program take the texture coordinate attribute and set a varying variable for each vertex, allowing the fragment shader to receive interpolated texture coordinate values for each fragment:
 
-.vertex shader
 ```glsl
+// vertex shader
 // This vertex attribute contains the UV texture coordinates for each vertex
 attribute mediump vec2 texcoord0;
 
@@ -248,10 +240,10 @@ void main()
 }
 ```
 
-In the fragment shader program, the varying texture coordinate variable is defined. A `sampler2D+ uniform variable is also defined. The sampler, together with the interpolated texture coordinates are used to perform texture lookup -- the graphics hardware samples the texture at a specified position and returns the sampled color value. The function `texture2D()` performs such lookup.
+In the fragment shader program, the varying texture coordinate variable is defined. A `sampler2D` uniform variable is also defined. The sampler, together with the interpolated texture coordinates are used to perform texture lookup---the graphics hardware samples the texture at a specified position and returns the sampled color value. The function `texture2D()` performs such lookup.
 
-.fragment shader
 ```glsl
+// fragment shader
 // The texture coordinate for the fragment
 varying mediump vec2 var_texcoord0;
 
@@ -276,8 +268,8 @@ Note that the above example only reposition the vertices. The texture coordinate
 
 We can choose fragment color based on any type of calculation. For example, it is possible to take the _normals_ of the model into account and create a simple lighting model. To get varied surface normals the example grid model has been deformed in the 3D modelling software.
 
-.vertex shader
 ```glsl
+// vertex shader
 attribute mediump vec4 position;
 attribute mediump vec4 normal;
 attribute mediump vec2 texcoord0;
@@ -303,8 +295,8 @@ void main()
 
 The fragment shader needs a position of a light source to be able to calculate the light intensity at every fragment's position. The intensity is depending on how far from the light source the fragment is, as well as the orientation of the surface normal, i.e. is the surface facing towards the light source or not?
 
-.fragment shader
 ```glsl
+// fragment shader
 varying mediump vec2 var_texcoord0;
 varying mediump vec3 var_normal;
 varying mediump vec4 var_position;

docs/en/manuals/sound.md

@@ -1,9 +1,9 @@
-Sound
-=====
-:location: documentation manuals resources
-:type: manual
+---
+title: Sound in Defold
+brief: This manual explains how you bring sounds into your Defold project, play back and control them.
+---
 
-This manual explains how you bring sounds into your Defold project, play back and control them.
+# Sound
 
 Defold's sound implementation is simple but powerful. There are only two concepts that you need to be aware of:
 
@@ -13,7 +13,6 @@ Sound components
 Sound groups
 : Each sound component can be designated to belong to a _group_. Groups offer an easy way to manage sounds that belong together in an intuitive way. For instance, a group "sound_fx" can be set up and any sound belonging to that group can be ducked by a simple function call.
 
-
 ## Creating a sound component
 
 Sound components can only be instanced in-place in a game object. Create a new game object, right click on it and select *Add Component*. Select *Sound* and press *OK*.
@@ -22,19 +21,18 @@ Sound components can only be instanced in-place in a game object. Create a new g
 
 The created component has a set of properties that should be set:
 
-Sound
+*Sound*
 : Should be set to a sound file in your project. The file should be in _Wave_ or _Ogg Vorbis_ format (See http://en.wikipedia.org/wiki/WAV and http://en.wikipedia.org/wiki/Vorbis for details).
 
-Looping
+*Looping*
 : If checked the sound will playback looping until explicitly stopped.
 
-Gain
+*Gain*
 : You can set the gain for the sound directly on the component. This allows you to easily tweak the gain for a sound without going back to your sound program and perform a re-export. See below for details on how gain is calculated.
 
-Group
+*Group*
 : The name of the sound group the sound should belong to. If this property is left empty, the sound will be assigned to the built-in "master" group.
 
-
 ![Create component](images/sound/sound_create_component.png)
 
 ## Gain
@@ -44,8 +42,8 @@ Group
 The sound system has 4 levels of gain:
 
 - The gain set on the sound component.
-- The gain set when starting the sound via a "play_sound" message or when changing the gain on the voice via a "set_gain" message.
-- The gain set on the group via a `[sound.set_group_gain()](/ref/sound#sound.set_group_gain)` function call.
+- The gain set when starting the sound via a `play_sound` message or when changing the gain on the voice via a `set_gain` message.
+- The gain set on the group via a [`sound.set_group_gain()`](/ref/sound#sound.set_group_gain) function call.
 - The gain set on the "master" group. This can be altered by `sound.set_group_gain(hash("master"))`.
 
 The output gain is the result of these 4 gains multiplied. The default gain is 1.0 everywhere (0 dB).
@@ -65,7 +63,7 @@ if sound.is_music_playing() then
 end
 ```
 
-The groups are identified with a hash value. The string name can be retrieved with `[sound.get_group_name()](/ref/sound#sound.get_group_name)` which can be used to display group names in development tools, for instance a mixer to test group levels.
+The groups are identified with a hash value. The string name can be retrieved with [`sound.get_group_name()`](/ref/sound#sound.get_group_name) which can be used to display group names in development tools, for instance a mixer to test group levels.
 
 ![Sound group mixer](images/sound/sound_mixer.png)
 
@@ -73,26 +71,30 @@ The groups are identified with a hash value. The string name can be retrieved wi
 You should not write code that rely on the string value of a sound group since it is not available in release builds.
 :::
 
-All values are linear between 0 and 1.0 (0 dB). To convert to decibel, simply use the standard formula: db = 20 * math.log10(gain).
+All values are linear between 0 and 1.0 (0 dB). To convert to decibel, simply use the standard formula:
+
+$$
+db = 20 \times \log \left( gain \right)
+$$
 
 ```lua
 for i, group_hash in ipairs(sound.get_groups()) do
-	-- The name string is only available in debug. Returns "unknown_*" in release.
-	local name = sound.get_group_name(group_hash)
+    -- The name string is only available in debug. Returns "unknown_*" in release.
+    local name = sound.get_group_name(group_hash)
     local gain = sound.get_group_gain(group_hash)
 
     -- Convert to decibel.
-	local db = 20 * math.log10(gain)
+    local db = 20 * math.log10(gain)
 
     -- Get RMS (gain Root Mean Square). Left and right channel separately.
-	local left_rms, right_rms = sound.get_rms(group_hash, 2048 / 65536.0)
+    local left_rms, right_rms = sound.get_rms(group_hash, 2048 / 65536.0)
     left_rmsdb = 20 * math.log10(left_rms)
-	right_rmsdb = 20 * math.log10(right_rms)
+    right_rmsdb = 20 * math.log10(right_rms)
 
-	-- Get gain peak. Left and right separately.
-	left_peak, right_peak = sound.get_peak(group_hash, 2048 * 10 / 65536.0)
+    -- Get gain peak. Left and right separately.
+    left_peak, right_peak = sound.get_peak(group_hash, 2048 * 10 / 65536.0)
     left_peakdb = 20 * math.log10(left_peak)
-	right_peakdb = 20 * math.log10(right_peak)
+    right_peakdb = 20 * math.log10(right_peak)
 end
 
 -- Set the master gain to +6 dB (math.pow(10, 6/20)).
@@ -112,44 +114,44 @@ The easiest way to deal with this problem is to build a gate that filters sound
 local gate_time = 0.3
 
 function init(self)
-	-- Store played sound timers in table and count down each frame until they have been 
-	-- in the table for "gate_time" seconds. Then remove them.
-	self.sounds = {}
+    -- Store played sound timers in table and count down each frame until they have been 
+    -- in the table for "gate_time" seconds. Then remove them.
+    self.sounds = {}
 end
 
 function update(self, dt)
-	-- Count down the stored timers
-	for k,_ in pairs(self.sounds) do
-		self.sounds[k] = self.sounds[k] - dt
-		if self.sounds[k] < 0 then
-			self.sounds[k] = nil
-		end
-	end
+    -- Count down the stored timers
+    for k,_ in pairs(self.sounds) do
+        self.sounds[k] = self.sounds[k] - dt
+        if self.sounds[k] < 0 then
+            self.sounds[k] = nil
+        end
+    end
 end
 
 function on_message(self, message_id, message, sender)
-	if message_id == hash("play_gated_sound") then
-		-- Only play sounds that are not currently in the gating table.
-		if self.sounds[message.soundcomponent] == nil then
-			-- Store sound timer in table
-			self.sounds[message.soundcomponent] = gate_time
-			-- Redirect the "play_sound" message to the real target
-			msg.post(message.soundcomponent, "play_sound", { gain = message.gain })
-		else
+    if message_id == hash("play_gated_sound") then
+        -- Only play sounds that are not currently in the gating table.
+        if self.sounds[message.soundcomponent] == nil then
+            -- Store sound timer in table
+            self.sounds[message.soundcomponent] = gate_time
+            -- Redirect the "play_sound" message to the real target
+            msg.post(message.soundcomponent, "play_sound", { gain = message.gain })
+        else
             -- An attempt to play a sound was gated
-			print("gated " .. message.soundcomponent)
-		end
-	end
+            print("gated " .. message.soundcomponent)
+        end
+    end
 end
 ```
 
-To use the gate, simply send it a "play_gated_sound" message and specify the target sound component and sound gain. The gate will send a "play_sound" message to the target sound component if the gate is open:
+To use the gate, simply send it a `play_gated_sound` message and specify the target sound component and sound gain. The gate will send a `play_sound` message to the target sound component if the gate is open:
 
 ```lua
-msg.post("/sound_gate#script", "play_gated_sound", { soundcomponent = "/sounds#explosion1, gain = 1.0 })
+msg.post("/sound_gate#script", "play_gated_sound", { soundcomponent = "/sounds#explosion1", gain = 1.0 })
 ```
 
 ::: important
-It does not work to have the gate listen to "play_sound" messages since that name is reserved by the Defold engine. You will get unexpected behavior if you do use reserved message names.
+It does not work to have the gate listen to `play_sound` messages since that name is reserved by the Defold engine. You will get unexpected behavior if you do use reserved message names.
 :::
 

docs/en/manuals/spine.md

@@ -1,9 +1,9 @@
-Spine animation
-===============
+---
+title: Spine bone animation in Defold
+brief: This manual explains how to bring Spine animations from _Spine_ or _Dragon Bone_ into Defold.
+---
 
-This manual explains how to bring Spine animations from _Spine_ or _Dragon Bone_ into Defold.
-
-## Spine
+# Spine animation
 
 _Spine_ is a third party animation tool by Esoteric Software that allows you to create animations where movement of _bones_ in a skeletal rig drives various parts of the animated object. It is particularly useful to animate characters and animals, but works very well for other types of objects, like ropes, vehicles or foliage.
 
@@ -20,19 +20,15 @@ Currently, Defold does not support animation keys that flip bones over the X or
 *Spine JSON data file*
 : This data file contains the skeleton, all the image slot names, skins and the actual animation data. No images are embedded in this file though. Create this file from your animation software of choice.
 
-
 *Spine scene*
 : The Defold resource tying together the Spine JSON data file and the image atlas that is used to fill bone slots with graphics.
 
-
 *Spine model*
 : The _SpineModel_ component is put in a game object to bring the graphics and animation to the screen. The component contains the skeleton game object hierarchy, which animation to play, what skin to use and it also specifies the material used for rendering the model. See [SpineModel documentation](/manuals/spinemodel) for details.
 
-
 *Spine Node*
 : If using Spine animation in a GUI scene, use Spine GUI nodes instead of Spine model components. See the [GUI spine documentation](/manuals/gui-spine) for details.
 
-
 ## Animation tools
 
 The Spine JSON data format that Defold supports can be created by Esoteric Software's _Spine_ software. In addition, _Dragon Bones_ has the ability to export Spine JSON data files.
@@ -62,7 +58,7 @@ If you work in _Dragon Bones_, simply select *Spine* as your output data type. A
 
 When you have the animation data and image files imported and set up in Defold, you need to create a _Spine scene_ resource file:
 
-- Create a new _Spine scene_ resource file (Select *New > Spine Scene File* from the main menu)
+- Create a new _Spine scene_ resource file (Select <kbd>New ▸ Spine Scene File</kbd> from the main menu)
 - Set the *spine_json* and *atlas* properties in the Spine scene file to reference the imported JSON and the newly created Atlas:
 
 ![Setup the Spine Scene](images/spine/spine_spinescene.png)
@@ -85,11 +81,11 @@ The animation data references the images used for the bones by name with the fil
 
 ![Spine images hierarchy](images/spine/spine_images.png)
 
-This example shows files laid out in a flat structure. It is, however, possible to organize the files in subfolders and the file references will reflect that. For instance, a file "head_parts/eyes.png" on disk will be referenced as "head_parts/eyes" when you use it in a slot. This is also the name used in the exported JSON file so when creating the Defold image atlas, all names must match an atlas animation.
+This example shows files laid out in a flat structure. It is, however, possible to organize the files in subfolders and the file references will reflect that. For instance, a file *head_parts/eyes.png* on disk will be referenced as *head_parts/eyes* when you use it in a slot. This is also the name used in the exported JSON file so when creating the Defold image atlas, all names must match an atlas animation.
 
-If you select *Add Images* Defold will automatically create animation groups with the same name as the added files, but with the file suffix stripped off. So, after having added the file "eyes.png" its animation group can be referenced by the name "eyes". This works with file names only, not paths.
+If you select <kbd>Add Images</kbd> Defold will automatically create animation groups with the same name as the added files, but with the file suffix stripped off. So, after having added the file *eyes.png* its animation group can be referenced by the name "eyes". This works with file names only, not paths.
 
-So how do you do if your animation references "head_parts/eyes"? The easiest way to accomplish a match is to add an animation group (right click the root node in the Atlas *Outline* view and select *Add Animation Group*). You can then name that group "head_parts/eyes" (it's just a name, not a path and '/' characters are legal) and then add the file "eyes.png" to the group.
+So how do you do if your animation references "head_parts/eyes"? The easiest way to accomplish a match is to add an animation group (right click the root node in the Atlas *Outline* view and select *Add Animation Group*). You can then name that group "head_parts/eyes" (it's just a name, not a path and `/` characters are legal) and then add the file "eyes.png" to the group.
 
 ![Atlas path names](images/spine/spine_atlas_names.png)
 

docs/en/manuals/spinemodel.md

@@ -1,11 +1,15 @@
-Spine Model
-===========
+---
+title: Spine model components in Defold
+brief: This manual explains how to create SpineModel components in Defold.
+---
+
+# Spine Model
 
 The SpineModel component is used to bring _Spine_ skeletal animations to life in Defold.
 
 ## Creating SpineModel components
 
-Create a game object and put a *SpineModel* component in the game object. You can either create the component in-place (right click the game object and select *Add Component*) or create it on file first (Select *New > Spine Model File* from the menu) and then add the file to the game object (right click the game object and select *Add Component From File*).
+Create a game object and put a *SpineModel* component in the game object. You can either create the component in-place (right click the game object and select <kbd>Add Component</kbd>) or create it on file first (Select <kbd>New ▸ Spine Model File</kbd> from the menu) and then add the file to the game object (right click the game object and select <kbd>Add Component From File</kbd>).
 
 ![Add component](images/spinemodel/spine_add_component.png)
 
@@ -26,8 +30,7 @@ Material
 : If you need to render the model with a custom material, change this property.
 
 Blend Mode
-: If you want a blend mode other than the default "Alpha", change this property.
-
+: If you want a blend mode other than the default `Alpha`, change this property.
 
 You should now be able to view your Spine model in the editor:
 

docs/en/manuals/texture-profiles.md

@@ -1,9 +1,11 @@
-Texture profiles
-=================
-:location: documentation manuals project
-:type: manual
+---
+title: Texture profiles in Defold
+brief:  Defold supports automatic texture processing and compression of image data. This manual describes the available functionality.
+---
 
-Defold supports automatic texture processing and compression of image data (in *Atlas*, *Tile sources*, *Cubemaps* and stand-alone textures used for models, GUI etc). This manual describes the available functionality.
+# Texture profiles
+
+Defold supports automatic texture processing and compression of image data (in *Atlas*, *Tile sources*, *Cubemaps* and stand-alone textures used for models, GUI etc).
 
 Compression reduce memory footprint and graphics hardware is able to manage compressed textures. Compression also reduces the  of image resources and the final bundle size. It should be noted that PNG file compression can sometimes yield smaller files, but PNG files need to be uncompressed when read into memory.
 
@@ -17,19 +19,19 @@ Compression is a resource intense and time consuming operation that can cause _v
 
 ## Texture profiles
 
-Each project contain a specific *.texture_profiles* file that contain the configuration used when compressing textures. By default, this file is "builtins/graphics/default.texture_profiles" and is has a configuration matching every texture resource to a profile that leaves the data uncompressed on all platforms.
+Each project contain a specific *.texture_profiles* file that contain the configuration used when compressing textures. By default, this file is *builtins/graphics/default.texture_profiles* and it has a configuration matching every texture resource to a profile that leaves the data uncompressed on all platforms.
 
 To add texture compression:
 
-- Select *File > New > Other...* and choose "Texture Profiles File" to create a new texture profiles file. (Alternatively copy "default.texture_profiles" to a location outside of "builtins")
-- Change the *texture_profiles* entry on "game.project" to point to the new file.
+- Select <kbd>File ▸ New ▸ Other...</kbd> and choose *Texture Profiles File* to create a new texture profiles file. (Alternatively copy *default.texture_profiles* to a location outside of *builtins*)
+- Change the *texture_profiles* entry in *game.project* to point to the new file.
 - Open the *.texture_profiles* file and configure it according to your requirements.
 
 ![New profiles file](images/texture_profiles/texture_profiles_new_file.png)
 
 ![Setting the texture profile](images/texture_profiles/texture_profiles_game_project.png)
 
-You can turn on and off the use of texture profiles in the editor preferences. Select *File > Preferences*. The *Defold* pane contains a checkbox item *Enable texture profiles*.
+You can turn on and off the use of texture profiles in the editor preferences. Select <kbd>File ▸ Preferences</kbd>. The *Defold* pane contains a checkbox item *Enable texture profiles*.
 
 ![Texture profiles preferences](images/texture_profiles/texture_profiles_preferences.png)
 
@@ -37,28 +39,26 @@ You can turn on and off the use of texture profiles in the editor preferences. S
 
 The *path_settings* section of the texture profiles file contains a list of path regular expressions and the name of which *profile* to use when processing resources that match the path expression. The path regular expressions are expressed with "Ant Glob" patterns (see http://ant.apache.org/manual/dirtasks.html#patterns for details). Patterns can be expressed using the following wildcards:
 
-'*'
-: Matches zero or more characters. For instance "sprite*.png" matches the files "sprite1.png", "sprite.png" and "sprite_with_a_long_name.png".
-
-'?'
-: Matches exactly one character. For instance: "sprite?.png" matches the files "sprite1.png", "spriteA.png" but not "sprite.png" or "sprite_with_a_long_name.png".
+`*`
+: Matches zero or more characters. For instance `sprite*.png` matches the files *sprite1.png*, *sprite.png* and *sprite_with_a_long_name.png*.
 
-\'**'
-: Matches a complete directory tree, or--when used as the name of a directory--zero or more directories. For instance: "/gui/\\**" matches all files in the directory "/gui" and all its subdirectories.
+`?`
+: Matches exactly one character. For instance: `sprite?.png` matches the files *sprite1.png*, *spriteA.png* but not *sprite.png* or *sprite_with_a_long_name.png*.
 
+`**`
+: Matches a complete directory tree, or---when used as the name of a directory---zero or more directories. For instance: `/gui/**` matches all files in the directory */gui* and all its subdirectories.
 
 ![Paths](images/texture_profiles/texture_profiles_paths.png)
 
 This example contains two path patterns and corresponding profile.
 
-"/gui/\**/*.atlas"
-: All *.atlas* files in directory "/gui" or any of its subdirectories will be processed according to profile "gui_atlas". 
+`/gui/**/*.atlas`
+: All *.atlas* files in directory */gui* or any of its subdirectories will be processed according to profile "gui_atlas". 
 
-"/\**/*.atlas"
+`/**/*.atlas`
 : All *.atlas* files anywhere in the project will be process according to the profile "atlas".
 
-
-Note that the more generic path is put last. The matcher works top down. The first occurence that matches the resource path will be used. A matching path expression further down the list never overrides the first match. Had the paths been put in the opposite order every atlas would have been processed with profile "atlas", even the ones in directory "/gui".
+Note that the more generic path is put last. The matcher works top down. The first occurence that matches the resource path will be used. A matching path expression further down the list never overrides the first match. Had the paths been put in the opposite order every atlas would have been processed with profile "atlas", even the ones in directory */gui*.
 
 Texture resources that _do not_ match any path in the profiles file will be compiled and rescaled to the closest power of 2, but will otherwise be left intact.
 
@@ -69,26 +69,24 @@ The *profiles* section of the texture profiles file contains a list of named pro
 ![Profiles](images/texture_profiles/texture_profiles_profiles.png)
 
 *os*
-: Specifies a matching OS platform. "OS_ID_GENERIC" matches all platforms including dev-app builds on device, "OS_ID_WINDOWS" matches Windows target bundles, "OS_ID_IOS" matches iOS bundles and so on.
+: Specifies a matching OS platform. `OS_ID_GENERIC` matches all platforms including dev-app builds on device, `OS_ID_WINDOWS` matches Windows target bundles, `OS_ID_IOS` matches iOS bundles and so on.
 
 *formats*
 : One or more texture formats to generate. If several formats are specified, textures for each format is generated and included in the bundle. The engine selects textures of a format that is supported by the runtime platform.
 
 *mipmaps*
-: For each platform, specify whether mipmaps should be generated. The property can be either "true" or "false".
+: For each platform, specify whether mipmaps should be generated. The property can be either `true` or `false`.
 
 *max_texture_size*
 : If set to a non-zero value, textures are limited in pixel size to the specified number. Any texture that has a width or height larger than the specified value will be scaled down.
 
-
 The *formats* added to a profile each has the following properties:
 
 *format*
 : The format to use when encoding the texture. See below for all available texture formats.
 
 *compression_level*
-: Selects the quality level for the resulting compressed image. The values range from "FAST" (low quality, fast compression) to "NORMAL", "HIGH" and "BEST" (highest quality, slowest compression).
-
+: Selects the quality level for the resulting compressed image. The values range from `FAST` (low quality, fast compression) to `NORMAL`, `HIGH` and `BEST` (highest quality, slowest compression).
 
 ## Texture formats
 
@@ -96,67 +94,29 @@ Textures can be processed into uncompressed or *lossy* compressed data with vari
 
 The following lossy compression formats are currently supported.
 
-//////////////////////////////////////////
+<!--
 DXT
 : Also called S3 Texture Compression. It can be generated on Windows platform only, but OS X supports reading it and it's possible to install support for it on Linux. The format divides the image into 4x4 pixel blocks with 4 colors set to the pixels within each block. 
-
-//////////////////////////////////////////
+-->
 
 PVRTC
 : Textures are compressed in blocks. In 4 bit mode (4BPP) one block has 4×4 pixels. In 2 bit mode (2BPP) one block are 8×4 pixels. One block always occupies 64 bits (8 bytes) of memory space.  The format is used in all generations of the iPhone, iPod Touch, and iPad. (certain Android devices, that use PowerVR GPUs also support the format). Defold supports PVRTC1, as indicated by the suffix "V1" in the format identifiers.
 
-
 ETC
 : Ericsson Texture Compression. Groups of 4x4 pixels are compressed into a single 64-bit word. The 4x4 group is divided in half and each half is assigned a base color. Each pixel is then encoded as one of four offset values from the base color of its half. Android supports ETC1 since version 2.2 (Froyo). Defold compresses ETC1 textures.
 
-
-[.table-striped]
-|===========================
-| Format | Compression | Color | Note
-
-| TEXTURE_FORMAT_LUMINANCE
-| none
-| One channel gray-scale, no alpha
-| RGB channels multiplied into one. Alpha is discarded.
-
-| TEXTURE_FORMAT_RGB
-| none
-| 3 channel color
-| Alpha is discarded
-
-| TEXTURE_FORMAT_RGBA
-| none
-| 3 channel color and full alpha
-|
-
-| TEXTURE_FORMAT_RGB_PVRTC2BPPV1
-| 1:16 fixed
-| No alpha
-| Requires square images. Non square images will be resized.
-
-| TEXTURE_FORMAT_RGB_PVRTC4BPPV1
-| 1:8 fixed
-| No alpha
-| Requires square images. Non square images will be resized.
-
-| TEXTURE_FORMAT_RGBA_PVRTC2BPPV1
-| 1:16 fixed
-| Pre-multiplied alpha
-| Requires square images. Non square images will be resized.
-
-| TEXTURE_FORMAT_RGBA_PVRTC4BPPV1
-| 1:8 fixed
-| Pre-multiplied alpha
-| Requires square images. Non square images will be resized.
-
-| TEXTURE_FORMAT_RGB_ETC1
-| 1:6 fixed
-| No alpha
-|
-
-|===========================
-
-//////////////////////////////////////////
+| Format                            | Compression | Color                            | Note |
+| --------------------------------- | ----------- | -------------------------------- | ---- | 
+| `TEXTURE_FORMAT_LUMINANCE`        | none        | One channel gray-scale, no alpha | RGB channels multiplied into one. Alpha is discarded. |
+| `TEXTURE_FORMAT_RGB`              | none        | 3 channel color                  | Alpha is discarded |
+| `TEXTURE_FORMAT_RGBA`             | none        | 3 channel color and full alpha   | |
+| `TEXTURE_FORMAT_RGB_PVRTC2BPPV1`  | 1:16 fixed. | No alpha                         | Requires square images. Non square images will be resized. |
+| `TEXTURE_FORMAT_RGB_PVRTC4BPPV1`  | 1:8 fixed   | No alpha                         | Requires square images. Non square images will be resized. |
+| `TEXTURE_FORMAT_RGBA_PVRTC2BPPV1` | 1:16 fixed | Pre-multiplied alpha | Requires square images. Non square images will be resized. |
+| `TEXTURE_FORMAT_RGBA_PVRTC4BPPV1` | 1:8 fixed. | Pre-multiplied alpha | Requires square images. Non square images will be resized. |
+| `TEXTURE_FORMAT_RGB_ETC1`         | 1:6 fixed  | No alpha | |
+
+<!---
 | TEXTURE_FORMAT_RGB_DTX1
 | 1:8 fixed
 | No alpha
@@ -176,6 +136,6 @@ ETC
 | 1:4 fixed
 | Interpolated smooth alpha
 | Can be compressed on Windows only
-//////////////////////////////////////////
+-->
 
 

docs/en/manuals/workflow.md

@@ -1,9 +1,9 @@
-Workflow
-========
+---
+title: Workflows in Defold
+brief: This manual covers how assets are handled in Defold, how you can change the structure of your project easily with the help of powerful refactoring, how collaboration works and advanced topics like external editors and the underlying Git tools.
+---
 
-This manual covers how assets are handled in Defold, how you can change the structure of your project easily with the help of powerful refactoring, how collaboration works and advanced topics like external editors and the underlying Git tools.
-
-## Assets
+# Workflow
 
 A game project usually consist of a large number of external assets that are produced in various specialized programs for producing graphics, 3D models, sound files, animations and so forth. Defold is by default set up for a workflow that encourages you to work separately with your external tools, store the working files for those tools separately and then import the assets into Defold and the project file structure as they are finalized.
 
@@ -139,14 +139,14 @@ Defold uses Git to do version tracking on all files in a simple and easily under
 
 The Git command line tool can be used to perform manual operations that the editor does not support. For instance, you can inspect the commit history of the repository:
 
-```bash
-git log
+```sh
+$ git log
 ```
 
 and then do a checkout from a specific commit:
 
-```bash
-git checkout <commit-hash> <file path>
+```sh
+$ git checkout <commit-hash> <file path>
 ```
 
 You can also set up a more advanced work flow if you want, allowing you to pull changes directly between team members. If you run into situations where more than one person work on an experimental branch, you might want to consider utilizing Git for that. Please visit http://git-scm.com to learn more about Git.
@@ -156,14 +156,13 @@ You can also set up a more advanced work flow if you want, allowing you to pull
 When you edit a text file on your computer and press *Return* on your keyboard, an invisible character sequence is inserted into the file indicating the line ending. Different operating systems use different sequences for historical reasons. These are the most common:
 
 Unix and Mac OS X
-: A single *Line Feed* character. (*LF*, '\n', 0x0A or 10 in decimal)
+: A single *Line Feed* character. (*LF*, `\n`, 0x0A or 10 in decimal)
 
 Windows
-: One *Carriage Return* character followed by a *Line Feed* character (*CR*+*LF*, '\r\n', 0x0D0A)
+: One *Carriage Return* character followed by a *Line Feed* character (*CR*+*LF*, `\r\n`, 0x0D0A)
 
 Mac OS 9 (and earlier)
-: A single *Carriage Return* character (*CR*, '\r', 0x0D or 13 in decimal)
-
+: A single *Carriage Return* character (*CR*, `\r`, 0x0D or 13 in decimal)
 
 ::: sidenote
 You can read more on line endings, or "newlines" at http://en.wikipedia.org/wiki/Newline
@@ -177,7 +176,7 @@ Meanwhile, a second team member who works on a Mac OS X machine does some editin
 
 ![Line endings conflict](images/workflow/workflow_line_endings_conflict.png)
 
-What happened is that the two files actually differs in how they encode the line endings. Since one file uses the *LF* character at the end of each line and the other the characters *CR*`*LF*, there is a legitimate conflict on each line and you will have to resolve it. If you have team members that work a lot with external tools line endings will cause merge conflicts all the time.
+What happened is that the two files actually differs in how they encode the line endings. Since one file uses the *LF* character at the end of each line and the other the characters *CR*+*LF*, there is a legitimate conflict on each line and you will have to resolve it. If you have team members that work a lot with external tools line endings will cause merge conflicts all the time.
 
 ## Line endings in Defold
 
@@ -195,7 +194,7 @@ There is also a menu option <kbd>File ▸ Convert Line Delimiters To ▸ ...</kb
 
 Git can be configured to specifically deal with line endings in a number of different ways:
 
-```bash
+```sh
 # Configure Git on OS X to properly handle line endings
 $ git config --global core.autocrlf input
 ```
@@ -203,8 +202,7 @@ $ git config --global core.autocrlf input
 The global Git setting `core.autocrlf` takes one parameter:
 
 false
-: The default. The result is that Git doesn't touch the line endings of your files. You can check in files with *LF*, *CR*`*LF* line endings, or a mix and Git does not care. If you work in a mixed operating system environment you should not use this setting.
-
+: The default. The result is that Git doesn't touch the line endings of your files. You can check in files with *LF*, *CR*+*LF* line endings, or a mix and Git does not care. If you work in a mixed operating system environment you should not use this setting.
 
 true
 : Git will process all text files and turn all *LF* line endings to *CR*`*LF* when writing them into the working directory and back to *LF* when they are checked into the repository again. This is a good setting on Windows machines.
@@ -214,7 +212,7 @@ input
 : Git will process all files and turn all *CR*+*LF* into *LF* line endings when checking files into the repository. When checking files out, the files are untouched. This is a good setting on Unix and OS X machines.
 
 
-You can configure Git with more fine grained control on how it should deal with line endings by creating a ".gitattributes" file in your repository:
+You can configure Git with more fine grained control on how it should deal with line endings by creating a *.gitattributes* file in your repository:
 
 ```txt
 # Set default behaviour, in case users don't have core.autocrlf set.
@@ -241,5 +239,5 @@ You can configure Git with more fine grained control on how it should deal with
 *.ogg binary
 ```
 
-See the Git documentation on ".gitattributes" at http://git-scm.com/docs/gitattributes for details.
+See the Git documentation on *.gitattributes* at http://git-scm.com/docs/gitattributes for details.
 

docs/sass/defold-md.sass

@@ -12,6 +12,12 @@ $text-black: #282c34
 $text-white: #d1d1d1
 $dark-grey: #282c34
 $light-grey: #e3e4e5
+$gray-light: #d0d3db
+$gray-lighter: #f2f3f5
+$gray-light-background: #f7f8fa
+$blue-dark-faded: #6a7480
+$orange-primary: #fd6623
+
 
 body
   font-family: Source Sans Pro, sans-serif
@@ -171,6 +177,23 @@ body
     font-family: 'Source Code Pro', monospace
     font-size: 0.9375em
 
+  code.type,
+  code.mark
+    font-family: Source Sans Pro, sans-serif
+    font-size: 0.9375em
+    line-height: 120%
+    border: 1px solid $gray-light
+    padding: 2px 6px
+    margin-right: 2px
+    color: $blue-dark-faded
+    background-color: $gray-lighter
+
+    .file
+        color: $orange-primary
+
+  code.mark
+        border: 1px solid $orange-primary
+
   kbd
     font-family: Source Sans Pro, sans-serif
     background-color: $light-grey

gulpfile.js

@@ -21,6 +21,7 @@ var md_container = require('markdown-it-container');
 var md_deflist = require('markdown-it-deflist')
 var md_sub = require('markdown-it-sub');
 var md_sup = require('markdown-it-sup');
+var md_katex = require('markdown-it-katex');
 
 // hljs lua highlight patched
 var lua = require('./lib/lua');
@@ -48,6 +49,7 @@ md.use(md_deflist);
 md.use(md_attrs);
 md.use(md_sub);
 md.use(md_sup);
+md.use(md_katex);
 md.use(md_container, 'sidenote', { render: rendernote });
 md.use(md_container, 'important', { render: rendernote });
 
@@ -112,7 +114,9 @@ md.renderer.rules.image = function (tokens, idx, options, env, self) {
 function markdownToPreviewHtml(file) {
     var data = frontmatter(file.contents.toString());
     // Inject some styling html for the preview. The built htmls are clean.
-    var head = '<html><head><link type="text/css" rel="stylesheet" href="/defold-md.css"></head><body>\n';
+    var head = '<!DOCTYPE html><html><head><link type="text/css" rel="stylesheet" href="/defold-md.css">' +
+                '<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.7.1/katex.min.css" integrity="sha384-wITovz90syo1dJWVh32uuETPVEtGigN07tkttEqPv+uR2SE/mbQcG7ATL28aI9H0" crossorigin="anonymous">' + 
+                '</head><body>\n';
     head += '<div class="documentation">';
     var foot = '</div></body></html>\n';
     var html = head + md.render(data.body) + foot;

package.json

@@ -20,6 +20,7 @@
     "markdown-it-attrs": "^0.8.0",
     "markdown-it-container": "^2.0.0",
     "markdown-it-deflist": "^2.0.1",
+    "markdown-it-katex": "^2.0.3",
     "markdown-it-sub": "^1.0.0",
     "markdown-it-sup": "^1.0.0",
     "mkdirp": "^0.5.1",