Updated docs again. DEF-616

Author: RagnarSvenssonKing

com.dynamo.cr/com.dynamo.cr.web2/site/site.py

@@ -34,7 +34,8 @@
 render('plans.html', 'plans/index.html', active_page = 'plans')
 render('signup.html', 'signup/index.html')
 
-docs = ['application_lifecycle.html',
+docs = ['2dgraphics.html',
+        'application_lifecycle.html',
         'collection_proxies.html',
         'example.html',
         'game_project.html',

com.dynamo.cr/com.dynamo.cr.web2/templates/doc_index.html

@@ -13,33 +13,22 @@ <h1>Documentation</h1>
                 <h2>Guides</h2>
                 <p>Detailed explanations of different areas of the platform</p>
                 <ul class="unstyled">
-                    <li><b>New Guides</b></li>
-                    <li><a href="/doc/application_lifecycle">Application Lifecycle</a></li>
-                    <li><a href="/doc/collection_proxies">Collection Proxies</a></li>
-                    <li><a href="/doc/gui">GUI</a></li>
-                    <li><a href="/doc/message_passing">Message Passing</a></li>
-                    <li><a href="/doc/modules">Modules</a></li>
-                    <li><a href="/doc/physics">Physics</a></li>
-                    <li><a href="/doc/input">Input</a></li>
-                    <li><a href="/doc/overview">Overview</a></li>
-                    <li><a href="/doc/scripting">Scripting</a></li>
-
-                    <br>
-
-
-                    <li><a href="/doc/introduction">Introduction</a></li>
+                    <li><a href="/doc/introduction">Introduction</a> (New)</li>
                     <li><a href="/doc/scene_editing">Scene Editing</a></li>
-                    <li><a href="/doc/tiles">2D Graphics</a></li>
-                    <li><a href="/doc/scripting_debugging">Scripting &amp; Debugging</a></li>
-                    <li><a href="/doc/message_passing">Message Passing</a></li>
+                    <li><a href="/doc/2dgraphics">2D Graphics</a> (New)</li>
+                    <li><a href="/doc/scripting">Scripting</a> (New)</li>
+                    <li><a href="/doc/message_passing">Message Passing</a> (New)</li>
+                    <li><a href="/doc/input">Input</a> (New)</li>
+                    <li><a href="/doc/gui">GUI</a> (New)</li>
+                    <li><a href="/doc/physics">Physics</a> (New)</li>
+                    <li><a href="/doc/collection_proxies">Collection Proxies</a> (New)</li>
                     <li><a href="/doc/properties">Properties</a></li>
                     <li><a href="/doc/script_properties">Script Properties</a></li>
-                    <li><a href="/doc/input">Input</a></li>
-                    <li><a href="/doc/reload">Hot Reloading</a></li>
-                    <li><a href="/doc/physics">Physics</a></li>
                     <li><a href="/doc/game_project">Project Settings</a></li>
                     <li><a href="/doc/ios">iOS Development</a></li>
                     <li><a href="/doc/particlefx">ParticleFX</a></li>
+                    <li><a href="/doc/modules">Modules</a> (New)</li>
+                    <li><a href="/doc/application_lifecycle">Application Lifecycle</a> (New)</li>
                 </ul>
             </div>
         </div>

com.dynamo.cr/com.dynamo.cr.web2/war/index_map.txt

@@ -74,6 +74,7 @@
 /index.html
 /plans/index.html
 /signup/index.html
+/doc/2dgraphics.html
 /doc/application_lifecycle.html
 /doc/collection_proxies.html
 /doc/example.html

engine/docs/src/guides/2dgraphics.txt

@@ -13,8 +13,7 @@ The application then enters the update loop where the application will spend a m
 
 At some point the applications lifecycle will come to an end. Before the application quits the engine steps out of the update loop and enters a finalization stage. It prepares all loaded game objects for deletion. All object components’ +link:/ref/go#final[final()]+ functions are called, which allows for custom cleanup. Then the objects are deleted and the main collection is unloaded.
 
-Initialization
---------------
+== Initialization
 
 image::images/application_lifecycle/application_lifecycle_init.png["Lifecycle overview", align="center"]
 
@@ -59,22 +58,19 @@ function on_message(self, message_id, message, sender)
 end
 ----
 
-The update loop
----------------
+== The update loop
 
 The update loop runs through a long sequence once every frame. The update sequence in the diagram below are divided into logical sequence blocks for clarity. "Dispatch messages" is also broken out separately for the same reason:
 
 image::images/application_lifecycle/application_lifecycle_update.png["Update loop", align="center"]
 
-Input
------
+=== Input
 
 Input is is read from available devices, mapped against link:/doc/input[input bindings] and then dispatched. Any game object that has acquired input focus gets input sent to all its component +on_input()+ functions. A game object with a script component and a GUI component with a GUI script will get input to both components’ +on_input()+ functions--given that they are defined and that they have acquired input focus.
 
 Any game object that has acquired input focus and that contain collection proxy components dispatches input further to components in the proxy collection belonging to game objects that has acquired input focus. This process continues recursively down enabled collection proxies within enabled collection proxies.
 
-Update
-------
+=== Update
 
 Each game object component in the main collection is traversed. If any of these component has a script +update(),+ then it will be called. If the component is a collection proxy, each component in the proxy collection is recursively updated with all the steps in the "update" sequence in the diagram above.
 
@@ -89,29 +85,25 @@ Child transforms are then done, applying any game object movement, rotation and
 
 In the next step all posted messages are dispatched. Since any receiver component’s +on_message()+ code can post additional messages the message dispatcher will continue to dispatch posted messaged until the message queue is empty. There is, however, a limit to how many runs through the message queue the message dispatcher performs. See link:/doc/message_passing[Message passing] and the section "Advanced topics" for details.
 
-Render update
--------------
+=== Render update
 
 The render update block dispatches messages to the @render socket (camera component "set_view_projection" messages, "set_clear_color" messages etc). The render script +update()+ is then called.
 
-Post update
------------
+=== Post update
 
 After the updates, a post update sequence is run. It unloads from memory collection proxies that are marked for unloading (this happens during the "dispatch messages" sequence). Any game object that is marked for deletion will call all of its components’ +final()+ functions called—if there are any. The code in +final()+ functions often posts new messages to the queue so a "dispatch messages" pass is run afterwards.
 
 Any factory components that has been told to spawn a game object will do that next. Finally, game objects that are marked for deletion are actually deleted.
 
 The last steps in the update loop involves dispatching @system messages ("exit", "reboot" messages, toggling the profiler, starting and stopping video capture etc). Then graphics is rendered. During the graphics rendering, video capture is done, as is any rendering of the visual profiler (see the link:/doc/scripting[Scripting documentation].)
 
-Frame rate and collection time step
------------------------------------
+=== Frame rate and collection time step
 
 The number of frame updates per seconds (which equals the number of update-loop runs per second) can be set in the project settings, or programmatically by sending an "set_update_frequency" message to the +@system+ socket. In addition, it is possible to set the _time step_ for collection proxies individually by sending a "set_time_step" message to the proxy. Changing a collection's time step does not affect the frame rate. It has an effect on the physics update time step as well as the "dt" variable passed to +update().+ Also note that altering the time step does not alter the number of times +update()+ will be called each frame--it is always exactly once.
 
 (See link:/doc/collection_proxies[Collection proxies] and link:ref/collection_proxy#set_time_step[set_time_step] for details)
 
-Finalization
-------------
+== Finalization
 
 At the point when the application exits, it finishes the last update loop sequence, which will unload any collection proxies: finalizing and deleting all game objects in the proxy collection.
 

engine/docs/src/guides/application_lifecycle.txt

@@ -252,7 +252,6 @@ Now back to our platformer example where the only thing we need to do is to send
 ...
 msg.post(currentsocket .. ":" .. "/player#script", "request_player")
 
-
 -- Now it's time to ditch the world we left behind.
 -- Normally you wouldn't do this on-screen but we're doing just that
 -- to make the whole process clearer and clearly visible.

engine/docs/src/guides/collection_proxies.txt

@@ -13,7 +13,6 @@ A graphical user interface in Defold is a game object component that you build a
 [NOTE]
 ====
 The rendering behavior can be changed in the render script but it is usually desirable to have it that way since the user interface is a separate visual "layer" on top of the game view and you usually want HUD items and menus on certain spots on screen.
-
 ====
 
 Because the GUI is not part of the collection’s coordinate system but is rendered independently of the game view it is not placed in a particular location in the collection editor and it has no visual representation in the collection editor. However, the GUI component have to reside in a game object that has a location in the collection. Changing that location has no effect on the GUI.
@@ -101,6 +100,7 @@ In this example the orange box node "box2" is part of layer "front" which is dra
 Both "box1" and "box3" are set to layer "back". The drawing order within a layer is determined by the node’s index, it’s place in the node list. "box1" comes before "box3" and is thus drawn first, behind "box3".
 
 === Batch rendering
+
 In order to render your gui as efficiently as possible, there are steps that you can take that will permit the engine to organise drawing of your gui nodes in batches, reducing the overall number of drawcalls that the engine must create. If groups of nodes meet the following conditions, then they may be handled within a single batch:
 
 . If they are all box nodes, they use the same texture.
@@ -221,7 +221,7 @@ Text nodes behave in exactly the same way. The adjust mode applies to the invisi
 
 Anchors control the behavior of a node’s position when the window is resized. New nodes are created _non anchored_ meaning that they are positioned relative to the center of the screen.
 
-==== Node repositioning without anchors
+=== Node repositioning without anchors
 
 The default behavior of a created node is the following
 
@@ -236,7 +236,7 @@ Similarly, if the window is shrunk and gets relatively narrower, the added heigh
 
 image::images/gui/gui_no_anchor_sizedown.png["No anchor size down", align="center"]
 
-==== Node repositioning with anchors
+=== Node repositioning with anchors
 
 By setting the Xanchor and/or the Yanchor properties you can lock the position of nodes relative to the edges of the window.
 
@@ -249,7 +249,7 @@ In practice this means that if you set the Xanchor property to "Right" and the Y
 
 image::images/gui/gui_anchor_topright.png["Anchor top right", align="center"]
 
-==== Pivot
+=== Pivot
 
 Each node has a position, scale and rotation inside the GUI coordinate system. A node is placed on that position so that its pivot is at the set coordinate and any rotation is done around that same pivot.