New editor, introduction and glossary manuals.

docs/en/en.json

@@ -103,13 +103,17 @@
                         "path": "/manuals/introduction",
                         "name": "Introduction"
                     },
+                    {
+                        "path": "/manuals/glossary",
+                        "name": "Glossary"
+                    },
                     {
                         "path": "/manuals/install",
                         "name": "Installing Defold"
                     },
                     {
-                        "path": "/manuals/scene-editing",
-                        "name": "Scene editing"
+                        "path": "/manuals/editor",
+                        "name": "The editor"
                     },
                     {
                         "path": "/manuals/workflow",
@@ -198,8 +202,8 @@
                         "name": "Material"
                     },
                     {
-                        "path": "/manuals/rendering",
-                        "name": "Rendering"
+                        "path": "/manuals/render",
+                        "name": "Render"
                     },
                     {
                         "path": "/manuals/shader",

docs/en/faq/faq.md

@@ -226,7 +226,7 @@ If I set the z coordinate of a sprite to 100 then it's not rendered. Why?
 : The Z-position of a game object controls rendering order. Low values are drawn before
   higher values. In the default render script game objects with a depth ranging between -1 and 1
   are drawn, anything lower or higher will not be drawn. You can read more about the
-  rendering script in the official [Rendering documentation](/manuals/rendering).
+  rendering script in the official [Render documentation](/manuals/render).
   On GUI nodes the Z value is ignored and does not affect rendering order at all.
   Instead nodes are rendered in the order they are listed and according to child hierarchies
   (and layering). Read more about gui rendering and draw call optimization using layers

docs/en/manuals/3dgraphics.md

@@ -50,6 +50,6 @@ The [Shader manual](/manuals/shader) contains information on how shader programs
 
 The last thing to do to get the model into the game is to alter the *Render Script* for the project. The default render script is tailor made for 2D games and does not work with 3D models. But by copying the default render script and adding a handful of lines of Lua code we can make sure that our book is rendered as expected. For the example the render script is already set up.
 
-Read the [Rendering documentation](/manuals/rendering) for details on how render scripts work.
+Read the [Render documentation](/manuals/render) for details on how render scripts work.
 
 

docs/en/manuals/addressing.md

@@ -5,13 +5,44 @@ brief: This manual explains how Defold has solved the problem of addressing.
 
 # Addressing
 
-Every game object and component that exist in runtime must be possible to address. This manual describes how Defold solves the addressing problem.
+In a running game, every object and component must be possible to move, scale, animate, delete and manipulate in any other way. In order to do that you are able to uniquely address anything through the Defold addressing mechanism. This manual describe how it works.
 
 ## Identifiers
 
-When you create a new game object or component in the editor, a unique *Id* property is automatically set. Game objects automatically get an id called "go" with an enumerator ("go2", "go3" etc) and components get an id corresponding to the component type ("sprite", "sprite2" etc). All these identifiers can be modified and you are encouraged to pick good, descriptive names for your game objects and components.
+Let's look at a very simple example. Suppose you have a game object with a sprite and you want to disable the sprite when the game starts (so you can make it appear later). The setup in the editor would look something like this:
+
+![bean in editor](images/addressing/bean_editor.png)
+
+You then put the following code in "controller.script":
+
+```lua
+function init(self)
+    msg.post("#body", "disable") -- <1>
+end
+```
+1. Don't worry if you're puzzled by the '#' character. We'll get to that soon.
+
+When you create a new game object or component in the editor, a unique *Id* property is automatically set. Game objects automatically get an id called "go" with an enumerator ("go2", "go3" etc) and components get an id corresponding to the component type ("sprite", "sprite2" etc). Each identifier can be modified and you are encouraged to pick good, descriptive names for your game objects and components.
+
+For the above example, the game object has been given the id "bean", its sprite component is named "body" and the script component that controls the character is called "controller".
+
+Schematically, the setup looks like this:
+
+![bean](images/addressing/bean.png)
+
+The script component *addresses* the sprite component by its identifier and sends it a message "disable".
+
+Let's now add another sprite component:
+
+![bean](images/addressing/bean_shield_editor.png)
+
+You *must* give the new shield sprite a unique identifier. If you would call it "body" the script code would be ambiquous as to which sprite it should send the "disable" message.
+
+![bean](images/addressing/bean_shield.png)
+
+
+## Identifiers
 
-![identifiers](images/addressing/identifiers.png)
 
 Suppose you have created a collection file containing two separate game objects. You have given the game objects the identifiers "soldier" and "shield". Each game object also contains a single sprite component. The sprites are both named "sprite". There is also a script component in the "shield" game object that you have named "controller".
 

docs/en/manuals/overview.md → docs/en/manuals/editor.md

@@ -7,7 +7,7 @@ brief: This manual gives an overview on how the editor look and works, and how t
 
 The editor allows you to browse and manipulate all files in your game project in an efficient manner. Editing files brings up a suitable editor and shows all relevant information about the file in separate views.
 
-:[overview](../shared/overview.md)
+:[overview](../shared/editor-views.md)
 
 ## The scene editor
 

docs/en/manuals/flash.md

@@ -170,7 +170,7 @@ The result would look like the below (with the index position updated):
 
 ## Defold—z position
 
-The positions of game objects in Defold are represented by vectors consisting of three variables: x, y, and z. The z position determines the depth of a game object. In the default [render script](/manuals/rendering), the available z positions range from -1 to 1.
+The positions of game objects in Defold are represented by vectors consisting of three variables: x, y, and z. The z position determines the depth of a game object. In the default [render script](/manuals/render), the available z positions range from -1 to 1.
 
 ::: sidenote
 Game objects with a z position outside the -1 to 1 range will not be rendered and therefore not visible. This is a common pitfall for developers new to Defold, and is worth keeping in mind if a game object is not visible when you expect it to be.

docs/en/manuals/glossary.md

@@ -0,0 +1,160 @@
+---
+title: Defold glossary
+brief: This manual lists everything that you encounter working in Defold with a brief description.
+---
+
+# Defold glossary
+
+This manual gives a brief description to all the things you encounter in Defold. In most cases, more in-depth documentation is available.
+
+## Animation set
+
+![Animation set](images/icons/animationset.png){.left} An animation set resource contains a list of .dae files or other .animationset files from where to read animations. Adding one .animationset files to another is handy if you share partial sets of animations between several models. See the [3D graphics manual](/manuals/3dgraphics/) for details.
+
+## Atlas
+
+![Atlas](images/icons/atlas.png){.left} An atlas is a set of separate images that are compiled into a larger sheet for performance and memory reasons. They can contain still images or flip-book animated series of images. Atlases are used by GUI, Sprite, Spine model and ParticleFX components to share graphics resources. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
+
+## Builtins
+
+![Builtins](images/icons/builtins.png){.left} The builtins project folder is a read-only folder containing useful default resources. Here you find the default renderer, render script, materials and more. If you need custom modifications on any of these resources, simply copy them into your project and edit as you see fit.
+
+## Camera
+
+![Camera](images/icons/camera.png){.left} The camera component helps to decide what part of the game world should be visible and how it should be projected. A common use case is to attach a camera to the player game object, or to have a separate game object with a camera that follows the player around with some smoothing algorithm. See the [Camera documentation](/manuals/camera) for more information.
+
+## Collision object
+
+![Collision object](images/icons/collision-object.png){.left} Collision objects are components that extend game objects with physical properties (like spatial shape, weight, friction and restitution). These properties govern how the collision object should collide with other collision objects. The most common types of collision objects are kinematic objects, dynamic objects and triggers. A kinematic object gives detailed collision information that you have to manually respond to, a dynamic object is automatically simulated by the physics engine to obey Newtonian laws of physics. Triggers are simple shapes that detect if other shapes have entered or exited the trigger. The [Physics documentation](/manuals/physics) details how this works.
+
+## Component
+
+Components are used to give specific expression and/or functionality to game objects, like graphics, animation, coded behavior and sound. They don’t live a life of their own but have to be contained inside game objects. There are many kinds of components available in Defold. See [the Building blocks manual](/manuals/building-blocks) for a description of components.
+
+## Collection
+
+![Collection](images/icons/collection.png){.left} Collections are Defold’s mechanism for creating templates, or what in other engines are called "prefabs" in where hierarchies of game objects can be reused. Collections are tree structures that hold game objects and other collections. A collection is always stored on file and brought into the game either statically by placing it manually in the editor, or dynamically by spawning. See [the Building blocks manual](/manuals/building-blocks) for a description of collections.
+
+## Collection factory
+
+![Collection factory](images/icons/collection-factory.png){.left} A Collection factory component is used to spawn hierarchies of game objects dynamically into a running game. See the [Collection factory manual](/manuals/collection-factory) manual for details.
+
+## Collection proxy
+
+![Collection](images/icons/collection.png){.left} A Collection proxy is used to load and enable collections on the fly while an app or game is running. The most common use case for Collection proxies is to load levels as they are to be played. See the [Collection proxy documentation](/manuals/collection-proxy) for details.
+
+## Cubemap
+
+![Cubemap](images/icons/cubemap.png){.left} A cubemap is a special type of texture that consists of 6 different textures that are mapped on the sides of a cube. This is useful for rendering skyboxes and different kinds of reflection and illumination maps.
+
+## Factory
+
+![Factory](images/icons/factory.png){.left} In some situations you cannot manually place all needed game objects in a collection, you have to create the game objects dynamically, on the fly. For instance, a player might fire bullets and each shot should be dynamically spawned and sent off whenever the player presses the trigger. To create game objects dynamically (from a pre-allocated pool of objects), you use a factory component. See the [Factory manual](/manuals/factory) for details.
+
+## Font
+
+![Font file](images/icons/font.png){.left} A Font resource is built from a TrueType or OpenType font file. The Font specifies which size to render the font in and what type of decoration (outline and shadow) the rendered font should have. Fonts are used by GUI and Label components.
+
+## Fragment shader
+
+![Fragment shader](images/icons/fragment-shader.png){.left} This is a program that is run on the graphics processor for each pixel (fragment) in a polygon when it is drawn to the screen. The purpose of the fragment shader is to decide the color of each resulting fragment. This is done by calculation, texture lookups (one or several) or a combination of lookups and computations. See the [Shader manual](/manuals/shader) for more information.
+
+## Gamepads
+
+![Gamepads](images/icons/gamepad.png){.left} A gamepads resource file defines how specific gamepad device input is mapped to gamepad input triggers on a certain platform. See the [Input manual](/manuals/input) for details.
+
+## Game object
+
+![Game object](images/icons/game-object.png){.left} Game objects are simple objects that have a separate lifespan during the execution of your game. Game objects are containers and are usually equipped with visual or audible components, like a sound or a sprite. They can also be equipped with behavior through script components. You create game objects and place them in collections in the editor, or spawn them dynamically at run-time with factories. See [the Building blocks manual](/manuals/building-blocks) for a description of game objects.
+
+## GUI
+
+![GUI component](images/icons/gui.png){.left} A GUI component contains elements used to construct user interfaces: text and colored and/or textured blocks. Elements can be organized into hierarchical structures, scripted and animated. GUI components are typically used to create heads-up displays, menu systems and on-screen notifications. GUI components are controlled with GUI scripts that define the behavior of the GUI and control the user interaction with it. Read more in the [GUI documentation](/manuals/gui).
+
+## GUI script
+
+![GUI script](images/icons/script.png){.left} GUI scripts are used to define the behaviour of GUI components. They control GUI animations and how the user interacts with the GUI.
+
+## Input binding
+
+![Input binding](images/icons/input-binding.png){.left} Input binding files define how the game should interpret hardware input (mouse, keyboard, touchscreen and gamepad). The file binds hardware input to high level input _actions_ like "jump" and "move_forward". In script components that listen to input you are able to script the actions the game or app should take given certain input. See the [Input documentation](/manuals/input) for details.
+
+## Label
+
+![Label](images/icons/label.png){.left} The label component allows you to attach text content to any game object. It renders a piece of text with a particular font, on screen, in game space. See the [Label manual](/manuals/label) for more information.
+
+## Library
+
+![Game object](images/icons/builtins.png){.left} Defold allows you to share data between projects through a powerful library mechanism. You can use it to set up shared libraries that are accessible from all your projects, either for yourself or across the whole team. Read more about the library mechanism in the [Libraries documentation](/manuals/libraries).
+
+## Lua module
+
+![Lua module](images/icons/lua-module.png){.left} Lua modules allow you to structure your project and create reusable library code. Read more about it in the [Lua modules manual](/manuals/modules/)
+
+## Material
+
+![Material](images/icons/material.png){.left} Materials define how different objects should be rendered by specifying shaders and their properties. See the [Material manual](/manuals/material) for more information.
+
+## Message
+
+Components communicate with each other and other systems through message passing. Components also respond to a set of predefined messages that alter them or trigger specific actions. You send messages to hide graphics, play sounds or nudge physics objects. The engine also uses messages to notify components of events, for instance when physics shapes collide. The message passing mechanism needs a recipient for each sent message. Therefore, everything in the game is uniquely addressed. To allow communication between objects, Defold extends Lua with message passing. Defold also provides a library of useful functions.
+
+For instance, the Lua-code required to play an explosion sound from a game object looks like this:
+
+```lua
+msg.post("#explosion", "play_sound")
+```
+
+Here, `"#explosion"` is the address of the current object's sound component. `"play_sound"` is a message that sound components respond to. See the [Message passing documentation](/manuals/message-passing) for an in depth explanation of how message passing works.
+
+## Model
+
+![Model](images/icons/model.png){.left} With the 3D model component can import Collada mesh, skeleton and animation assets into your game. See the [Model manual](/manuals/model/) for more information.
+
+## ParticleFX
+
+![ParticleFX](images/icons/particlefx.png){.left} Particles are very useful for creating nice visual effects, particularly in games. you can use them to create fog, smoke, fire, rain or falling leaves. Defold contains a powerful particle effects editor that allows you to build and tweak effects while you run them real time in your game. The [ParticleFX documentation](/manuals/particlefx) gives you the details on how that works.
+
+## Render
+
+![Render](images/icons/render.png){.left} Render files contain settings used when rendering the game to the screen. Render files define which Render script to use for rendering and which materials to use. See the [Render manual](/manuals/render/) for more details.
+
+## Render script
+
+![Render script](images/icons/script.png){.left} A Render script is a Lua script that controls how the game or app should be rendered to the screen. There is a default Render script that covers most common cases, but you can write your own if you need custom lighting models and other effects. See the [Render manual](/manuals/render/) for more details.
+
+## Script
+
+![Script](images/icons/script.png){.left}  A script is a component that contains a program that defines game object behaviors. With scripts you can specify the rules of your game, how objects should respond to various interactions (with the player as well as other objects). All scripts are written in the Lua programming language. To be able to work with Defold, you or someone on your team needs to learn how to program in Lua. Read the [Lua in Defold documentation](/manuals/lua) for more information.
+
+## Sound
+
+![Sound](images/icons/sound.png){.left} The sound component is responsible for playing a specific sound. Currently, Defold supports sound files in the WAV and Ogg Vorbis formats. See the [Sound manual](/manuals/sound) for more information.
+
+## Spine model
+
+![Spine model](images/icons/spine-model.png){.left} The Spine model component is used to bring Spine skeletal animations to life in Defold. Read more about how to use it in the [Spine model manual](/manuals/spinemodel).
+
+## Spine scene
+
+![Spine scene](images/icons/spine-scene.png){.left} The Spine scene resource ties together the Spine JSON data file and the Defold image atlas file that is used to fill bone slots with graphics. The [Spine animation manual](/manuals/spine) contains more information.
+
+## Sprite
+
+![Sprite](images/icons/sprite.png){.left} A sprite is a component that extends game objects with graphics. It displays an image either from a Tile source or from an Atlas. Sprites have built-in support for flip-book and bone animation. Sprites are usually used for characters and items. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
+
+## Texture profiles
+
+![Texture profiles](images/icons/texture-profiles.png){.left} The texture profiles resource file is used in the bundling process to automatically process and compress image data (in Atlas, Tile sources, Cubemaps and stand-alone textures used for models, GUI etc). Read more in the [Texture profiles manual](/manuals/texture-profiles).
+
+## Tile map
+
+![Tile map](images/icons/tilemap.png){.left} Tile map components display images from a tile source in one or more overlaid grids. They are most commonly used to build game environments: ground, walls, buildings and obstacles. A tile map can display several layers aligned on top of each other with a specified blend mode. This is useful to, for example, put foliage on top of grass background tiles. It is also possible to dynamically change the displayed image in a tile. That allows you to, for instance, destroy a bridge and make it impassable by simply replacing the tiles with ones depicting the broken down bridge and containing the corresponding physics shape. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
+
+## Tile source
+
+![Tile source](images/icons/tilesource.png){.left} A tile source describes a texture that is composed of multiple smaller images, each with the same size. You can define flip-book animations from a sequence of images in a tile source. Tile sources can also automatically calculate collision shapes from image data. This is very useful for creating tiled levels that object can collide and interact with. Tile sources are used by Tile map components (and Sprite and ParticleFX) to share graphics resources. Note that Atlases are often a better fit than tile sources. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
+
+## Vertex shader
+
+![Vertex shader](images/icons/vertex-shader.png){.left} The vertex shader computes the screen geometry of a component's primitive polygon shapes. For any type of visual component, be it a sprite, spine model or model, the shape is represented by a set of polygon vertex positions. The vertex shader program processes each vertex (in world space) and computes the resulting coordinate that each vertex of a primitive should have. See the [Shader manual](/manuals/shader) for more information.

docs/en/manuals/gui.md

@@ -411,7 +411,7 @@ Now we can call either `fadeup()` or `fadedown()` and supply the node we want th
 
 ## Render script
 
-The default render script is a Lua script that handles all rendering of your game content (see [Rendering documentation](/manuals/rendering) for details). It is set up to render GUI nodes on top of the rest of a game in a separate pass:
+The default render script is a Lua script that handles all rendering of your game content (see [Render documentation](/manuals/render) for details). It is set up to render GUI nodes on top of the rest of a game in a separate pass:
 
 ```lua
 ...

docs/en/manuals/introduction.md

@@ -7,46 +7,31 @@ brief: A brief introduction that covers the core concepts of Defold and is inten
 
 Welcome to Defold. This introduction covers the core concepts of Defold and is intended to give an overview of the editor and the most important features. All descriptions are quite brief but there are links to more thorough documentation.
 
-## Philosophy
+:[editor versions](../shared/editor-versions.md)
 
-Defold is designed with a clear philosophy of simplicity. It is a turn-key production platform, but Defold does not try to provide all-encompassing solutions for everything. Instead, we believe the job of Defold is to empower you, the game creator, with simple, strong tools that allow you to realize your unique vision.
+## Design philosophy
 
-Sometimes that means that you have to do a bit more work yourself, but it also means that the path to the goal is clear. Ready made solutions seldom fit perfectly and when they don't it can be hard, or even impossible, to get them to work exactly the way you need them to.
+Defold was created with the following goals:
 
-If you are an experienced developer, Defold's core concepts may be pretty straightforward to understand, but please take the time to read this overview carefully---some of our concepts are, even though simple, different from what you might initially expect.
+- To be a complete professional turn-key production platform for game teams.
+- To be simple and clear, providing explicit solutions to common game development architectural and workflow problems.
+- To be a blazing fast development platform ideal for iterative game development.
+- To be high-performance in runtime.
+- To be truly multi-platform.
 
-## Scripts
+The design of the editor and engine is carefully crafted to reach those goals. Some of our design decisions differ from what you may be used to if you have experience with other platforms, for example:
 
-A script is a component that contains a program that defines game object behaviors. With scripts you can specify the rules of your game, how objects should respond to various interactions (with the player as well as other objects). All scripts are written in the Lua programming language. To be able to work with Defold, you or someone on your team needs to learn how to program in Lua. Read the [Lua in Defold documentation](/manuals/lua) for more information.
+- We require static declaration of the resource tree and all naming. This requires some initial effort from you, but helps the development process tremendously in the long run.
+- We encourage message passing between simple encapsulated entities.
+- There is no object orientation inheritance.
+- Our API:s are asynchronous.
+- The rendering pipeline is code driven and fully customizable.
+- All our resource files are in simple plain text formats, optimally structured for Git merges as well as import and processing with external tools.
+- Resources can be changed and hot reloaded into a running game allowing for extremely fast iteration and experimentation.
 
-To allow communication between objects, Defold extends Lua with [Message passing](/manuals/message-passing). Defold also provides a library of useful functions.
+Defold is not an all-encompassing solution for everything. There are no ready made complex components available. Instead, we believe the job of Defold is to empower game teams with simple strong collaborative tools. This means that you often have to do a bit more work yourself, but it also means that the path to the goal is clearer.
 
-For instance, the Lua-code required to play an explosion sound from a game object looks like this:
-
-```lua
-msg.post("#explosion", "play_sound")
-```
-
-Here, "explosion" is the name of the object's sound component where the script resides. `play_sound` is a message that sound components respond to. This is a simple example of message passing, which is how components interact. When scripting, no data is shared between scripts or objects. Components (including scripts) only exchange information by passing messages using the function `msg.post()`.
-
-## Messages
-
-Components communicate with each other and other systems through message passing. Components also respond to a set of predefined messages that alter them or trigger specific actions. You send messages to hide graphics, play sounds or nudge physics objects. The engine also uses messages to notify components of events, for instance when physics shapes collide.
-
-The message passing mechanism needs a recipient for each sent message. Therefore, everything in the game has an address, or URL. Every game object and component has a unique URL which allows any two components in your app or game to send messages to each other.
-
-See the [Message passing documentation](/manuals/message-passing) for an in depth explanation of how message passing works.
-
-## Factories
-
-In some situations you cannot manually place all needed game objects in a collection, you have to create the game objects dynamically, on the fly. For instance, a player might fire bullets and each shot should be dynamically spawned and sent off whenever the player presses the trigger. To create game objects dynamically (from a pre-allocated pool of objects), you use a factory component.
-
-![Factory](images/introduction/introduction_factory.png)
-
-Defold provides two types of factories and you can read about them in the respective manual.
-
-* [Factories](/manuals/factory)
-* [Collection factories](/manuals/collection-factory)
+If you are an experienced developer, Defold's core concepts may be pretty straightforward to understand, but please take the time to experiment and read through the documentation---some of our concepts are, although simple, different from what you might initially expect.
 
 ## Collaboration
 
@@ -57,92 +42,3 @@ Most games are created as a collaborative effort between two or more people. We
 When you create a new project, a central repository is automatically created on our servers. During development, the files you create and modify are your personal view of this repository. When you have done some work and are ready to share your changes, just synchronize your personal view with the central repository. The editor uploads your changes, downloads any new changes (from other team members) and helps resolve conflicts if you and someone else have edited the same piece of project data. All changes are recorded and logged so there is a clear history of what has happened in your project. You don't have to worry about backups and you will never need to email files back and forth with your team. Read more about project collaboration in the [Workflow documentation](/manuals/workflow/).
 
 Defold's collaboration tools are built on the popular and extremely powerful distributed version control system "Git". (If you're interested in Git, you can read more on http://git-scm.com).
-
-## Libraries
-
-In addition to collaborating through project branches, Defold allows you to share data between projects through a powerful library mechanism. You can use it to set up shared libraries that are accessible from all your projects, either for yourself or across the whole team. Read more about the library mechanism in the [Libraries documentation](/manuals/libraries).
-
-## Building blocks
-
-This is a list of all the available building blocks for creating apps and games. They are listed together with the icon used for the type of building block in the Defold editor.
-
-Game object
-: ![Game object](images/icons/brick.png){.left} See [the Building blocks manual](/manuals/building-blocks) for a description of game objects.
-
-Collection
-: ![Collection](images/icons/bricks.png){.left} See [the Building blocks manual](/manuals/building-blocks) for a description of collections.
-
-Script
-: ![Script](images/icons/cog.png){.left} [See above](#_scripts) for a description of script components.
-
-Sound
-: ![Sound](images/icons/sound.png){.left} The sound component is responsible for playing a specific sound. Currently, Defold supports sound files in the WAV and Ogg Vorbis formats.
-
-Collision object
-: ![Collision object](images/icons/weight.png){.left} Collision objects are components that extend game objects with physical properties (like spatial shape, weight, friction and restitution). These properties govern how the collision object should collide with other collision objects. The most common types of collision objects are kinematic objects, dynamic objects and triggers. A kinematic object gives detailed collision information that you have to manually respond to, a dynamic object is automatically simulated by the physics engine to obey Newtonian laws of physics. Triggers are simple shapes that detect if other shapes have entered or exited the trigger.
-
-Factory
-: ![Factory](images/icons/factory.png){.left} [See above](#_factories) for a description of factories.
-
-Sprite
-: ![Sprite](images/icons/pictures.png){.left} A sprite is a component that extends game objects with graphics. It displays an image either from a Tile source or from an Atlas. Sprites have built-in support for flip-book and bone animation. Sprites are usually used for characters and items. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
-
-Atlas
-: ![Atlas](images/icons/pictures_atlas.png){.left} An atlas is a set of separate images that are compiled into a larger sheet for performance and memory reasons. They can contain still images or flip-book animated series of images. Atlases are used by Sprite and ParticleFX components to share graphics resources. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
-
-  ![Atlas](images/introduction/introduction_atlas.png)
-
-Tile source
-: ![Tile source](images/icons/small_tiles.png){.left} A tile source describes a texture that is composed of multiple smaller images, each with the same size. You can define flip-book animations from a sequence of images in a tile source. Tile sources can also automatically calculate collision shapes from image data. This is very useful for creating tiled levels that object can collide and interact with. Tile sources are used by Tile map (and Sprite and ParticleFX although Atlases are usually preferred) components to share graphics resources. See the [2D graphics documentation](/manuals/2dgraphics) for more information.
-
-  ![Tile source](images/introduction/introduction_tilesource.png)
-
-  ![Tile source animation](images/introduction/introduction_tilesource_animation.png)
-
-  ![Tile source shape](images/introduction/introduction_tilesource_hull.png)
-
-Tile map
-: ![Tile map](images/icons/layer_grid.png){.left} Tile map components display images from a tile source in one or more overlaid grids. They are most commonly used to build game environments: ground, walls, buildings and obstacles. A tile map can display several layers aligned on top of each other with a specified blend mode. This is useful to, for example, put foliage on top of grass background tiles. It is also possible to dynamically change the displayed image in a tile. That allows you to, for instance, destroy a bridge and make it impassable by simply replacing the tiles with ones depicting the broken down bridge and containing the corresponding physics shape.
-
-  ![Tile map](images/introduction/introduction_tilemap.png)
-
-  ![Tile map palette](images/introduction/introduction_tilemap_palette.png)
-
-ParticleFX
-: ![ParticleFX](images/icons/clouds.png){.left} Particles are very useful for creating nice visual effects, particularly in games. you can use them to create fog, smoke, fire, rain or falling leaves. Defold contains a powerful particle effects editor that allows you to build and tweak effects while you run them real time in your game. The [ParticleFX documentation](/manuals/particlefx) gives you the details on how that works.
-
-  ![ParticleFX](images/introduction/introduction_particlefx.png)
-
-GUI
-: ![GUI component](images/icons/text_allcaps.png){.left} A GUI component contains elements used to construct user interfaces: text and colored and/or textured blocks. Elements can be organized into hierarchical structures, scripted and animated. GUI components are typically used to create heads-up displays, menu systems and on-screen notifications. GUI components are controlled with GUI scripts that define the behavior of the GUI and control the user interaction with it. Read more in the [GUI documentation](/manuals/gui).
-
-  ![GUI](images/introduction/introduction_gui.png)
-
-GUI script
-: ![GUI script](images/icons/cog.png){.left} GUI scripts are used to define the behaviour of GUI components. They control GUI animations and how the user interacts with the GUI.
-
-Font
-: ![Font file](images/icons/font.png){.left} A Font is built from a TrueType or OpenType font file. The Font specifies which size to render the font in and what type of decoration (outline and shadow) the rendered font should have. Fonts are used by GUI and Label components.
-
-  ![Font](images/introduction/introduction_font.png)
-
-Input binding
-: ![Input binding](images/icons/keyboard.png){.left} Input binding files define how the game should interpret hardware input (mouse, keyboard, touchscreen and gamepad). The file binds hardware input to high level input _actions_ like "jump" and "move_forward". In script components that listen to input you are able to script the actions the game or app should take given certain input. See the [Input documentation](/manuals/input) for details.
-
-  ![Input binding](images/introduction/introduction_input_binding.png)
-
-Camera
-: ![Camera](images/icons/camera.png){.left} Camera components help to decide what part of the game world should be visible and how it should be projected. A common use case is to attach a camera to the player game object, or to have a separate game object with a camera that follows the player around with some smoothing algorithm.
-
-Material
-: ![Material](images/icons/large_tiles.png){.left} Materials define how different objects should be rendered by specifying shaders and their properties.
-
-Render
-: ![Render](images/icons/paintcan.png){.left} Render files contain settings used when rendering the game to the screen. Render files define which Render script to use for rendering and which materials to use.
-
-Render script
-: ![Render script](images/icons/cog.png){.left} A Render script is a Lua script that controls how the game or app should be rendered to the screen. There is a default Render script that covers most common cases, but you can write your own if you need custom lighting models and other effects.
-
-Collection proxy
-: ![Collection proxy](images/icons/bricks_proxy.png){.left} A Collection proxy is used to load and enable collections on the fly while an app or game is running. The most common use case for Collection proxies is to load levels as they are to be played. See the [Collection proxy documentation](/manuals/collection-proxy) for details.
-

docs/en/manuals/material.md

@@ -9,7 +9,7 @@ Materials are the Defold way of expressing how a graphical component (a sprite,
 
 A material holds _Tags_, information that is used in the rendering pipeline to select objects to be rendered. It also holds references to _shader programs_ that are compiled through the available graphics driver and uploaded to the graphics hardware and run when the component is rendered each frame.
 
-* For more information on the render pipeline, see the [Rendering documentation](/manuals/rendering).
+* For more information on the render pipeline, see the [Render documentation](/manuals/render).
 * For an in depth explanation of shader programs, see the [Shader documentation](/manuals/shader).
 
 ## Creating a material
@@ -38,7 +38,7 @@ Associate the two program files with the corresponding properties in the materia
 
 ## Material tags
 
-You need to set a tag for the material so your render script can render any component using the new material. The tags are represented in the engine as a _bitmask_ that is used by [`render.predicate()`](/ref/render#render.predicate) to collect components that should be drawn together. See the [Rendering documentation](/manuals/rendering) on how to do that.
+You need to set a tag for the material so your render script can render any component using the new material. The tags are represented in the engine as a _bitmask_ that is used by [`render.predicate()`](/ref/render#render.predicate) to collect components that should be drawn together. See the [Render documentation](/manuals/render) on how to do that.
 
 ::: important
 The maximum number of tags you can use in a project is 32.

docs/en/manuals/rendering.md → docs/en/manuals/render.md

@@ -1,9 +1,9 @@
 ---
-title: Rendering in Defold
+title: The render pipeline in Defold
 brief: This manual explains how Defold's render pipeline works and how you can program it.
 ---
 
-# Rendering
+# Render
 
 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.
 

docs/en/manuals/scene-editing.md

@@ -3,4 +3,6 @@ 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.
 ---
 
-This manual has been replaced by the [overview manual](/manuals/overview).
+# Defold scene editor
+
+This manual has been replaced by the [editor manual](/manuals/editor).

docs/en/manuals/shader.md

@@ -17,8 +17,8 @@ Shaders are at the core of graphics rendering. They are programs written in a C-
 
 This manual describes vertex and fragment shaders in detail. In order to create shaders for your content, you need to also understand the concept of materials in Defold, as well as how the render pipeline works.
 
-* See the [Rendering manual](/manuals/rendering) for details on the render pipeline.
-* See the [Materials manual](/manuals/material) for details on materials.
+* See the [Render manual](/manuals/render) for details on the render pipeline.
+* See the [Material manual](/manuals/material) for details on materials.
 
 Specifications of OpenGL ES 2.0 (OpenGL for Embedded Systems) and OpenGL ES Shading Language can be found at https://www.khronos.org/registry/gles/
 

docs/en/manuals/spawning.md

@@ -3,8 +3,7 @@ title: Dynamic spawning in Defold
 brief: This manual describes how to dynamically spawn game objects.
 ---
 
-Dynamic spawning
-================
+# Resources and spawning
 
 This manual explains Defold's dynamic spawning features and how to use them.
 

docs/en/shared/editor-versions.md

@@ -0,0 +1,11 @@
+## Editor 1 and 2
+
+We are currently transitioning to Defold editor 2, which right now is in beta. Most new documentation we produce is for the new editor and we will eventually update all documentation, but that process will take time. You recognize the editor version on the color theme of screenshots.
+
+Editor 2 features a nice, dark theme:
+![editor 2](../shared/images/editor2.png)
+
+Editor 1 has a standard light theme:
+![editor 1](../shared/images/editor1.png)
+
+You are very welcome to [try the new editor](https://www.defold.com/editor-two/).

docs/en/shared/overview.md → docs/en/shared/editor-views.md

@@ -8,15 +8,16 @@ The old editor looks different but works very much the same, only with less func
 
 ![Editor 1](../shared/images/editor1_overview.png)
 
-1. The *Assets* view, or *Project Explorer* (editor 1), lists all the files that are part of your project. You click and scroll to navigate the list. All file oriented operations can be made in this view:
+The *Assets* view / *Project Explorer* (editor 1)
+: Lists all the files that are part of your project. You click and scroll to navigate the list. All file oriented operations can be made in this view:
 
    - <kbd>Double click</kbd> a file to open it in an editor for that file type.
    - <kbd>Drag and drop</kbd> to add files from elsewhere on your disk to the project or move files and folders to new locations in the project.
    - <kbd>Right click</kbd> to open a pop up menu from where you can create new files or folders, rename, delete, track file dependencies and more.
 
-2. The *Editor* view in the center shows the currently open file in an editor for that file type.
+The *Editor* view
 
-   In all visual editors you can navigate with the camera:
+: The center view shows the currently open file in an editor for that file type. In all visual editors you can navigate the camera:
 
    - Pan: <kbd>Alt + left mouse button</kbd>.
    - Pan (editor 1): <kbd>Alt + Middle button</kbd> (three button mouse) or <kbd>Option + Ctrl + Mouse button</kbd> (one button mouse)
@@ -25,16 +26,20 @@ The old editor looks different but works very much the same, only with less func
 
    The menu <kbd>Scene</kbd> contains tools to move, rotate and scale the currently selected object, options to frame the view to the current selection and to realign the camera. Editor 2 contains a toolbar in the top right where you find the move, rotate and scale tools.
 
-3. The *Outline* shows the content of the file currently being edited, but in a hierarchial tree structure. The outline reflects the editor view and allows you to perform operations on your items:
+The *Outline*
+: This view shows the content of the file currently being edited, but in a hierarchial tree structure. The outline reflects the editor view and allows you to perform operations on your items:
    - <kbd>Click</kbd> to select an item. Hold <kbd>Shift</kbd> or <kbd>Option</kbd> to expand the selection.
    - <kbd>Drag and drop</kbd> to move items. Drop a game object on another game object in a collection to child it.
    - <kbd>Right click</kbd> to open a pop up menu from where you can add items, delete selected items etc.
 
-5. The *Properties* view shows properties associated with the currently selected item, like Position, Rotation, Animation etc, etc.
+The *Properties* view
+: This view shows properties associated with the currently selected item, like Position, Rotation, Animation etc, etc.
 
-6. The *Console* shows any error output or purposeful printing that you do while your game is running. Alongside the console are tabs containing the *Curve Editor* which is used when editing curves in the particle editor, the *Build Errors* view that shows build errors, and the *Search Results* view that displays search results.
+The *Console*
+: This view shows any error output or purposeful printing that you do while your game is running. Alongside the console are tabs containing the *Curve Editor* which is used when editing curves in the particle editor, the *Build Errors* view that shows build errors, and the *Search Results* view that displays search results.
 
-7. The *Changed Files* view lists any files that has been changed, added or deleted in your project. By synchronizing the project regularly you can bring your local copy in sync with what is stored in the project Git repository, that way you can collaborate within a team, and you won’t lose your work if unfortune strikes. Some file oriented operations can be performed in this view:
+The *Changed Files* view:
+: This view lists any files that has been changed, added or deleted in your project. By synchronizing the project regularly you can bring your local copy in sync with what is stored in the project Git repository, that way you can collaborate within a team, and you won’t lose your work if unfortune strikes. Some file oriented operations can be performed in this view:
 
    - <kbd>Double click</kbd> a file to open a diff view of the file. Editor 2 opens the file in a suitable editor, just like in the assets view.
    - <kbd>Right click</kbd> a file to open a pop up menu from where you can open a diff view, revert all changes done to the file, find the file on the filesystem and more (editor 2).

docs/en/tutorials/grading.md

@@ -7,7 +7,7 @@ brief: In this tutorial you will create a full screen post effect in Defold.
 
 In this tutorial we are going to create a color grading  full screen post effect. The basic rendering method used is widely applicable for various types of post effects like blur, trails, glow, color adjustments and so on.
 
-It is assumed that you know your way around the Defold editor, and that you have basic understanding of GL shaders and the Defold rendering pipeline. If you need to read up on these subjects, check out [our Shader manual](/manuals/shader/) and the [Rendering manual](/manuals/rendering/).
+It is assumed that you know your way around the Defold editor, and that you have basic understanding of GL shaders and the Defold rendering pipeline. If you need to read up on these subjects, check out [our Shader manual](/manuals/shader/) and the [Render manual](/manuals/render/).
 
 ## Render targets
 

docs/ko/ko.json

@@ -173,8 +173,8 @@
                         "name": "Material"
                     },
                     {
-                        "path": "/manuals/rendering",
-                        "name": "Rendering"
+                        "path": "/manuals/render",
+                        "name": "Render"
                     },
                     {
                         "path": "/manuals/shader",