From 600d7a7412983b950f44fa1d9d3bac144ce3157b Mon Sep 17 00:00:00 2001
From: Eugene Kozlov <nekoeuge@gmail.com>
Date: Thu, 14 Sep 2017 22:09:31 +0300
Subject: [PATCH] Update docs.
---
Docs/Reference.dox | 34 +++++++++++++++++-----------------
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/Docs/Reference.dox b/Docs/Reference.dox
index 5620fc2c5..ba4dbd92b 100644
--- a/Docs/Reference.dox
+++ b/Docs/Reference.dox
@@ -2010,7 +2010,7 @@ Both a RigidBody and at least one CollisionShape component must exist in a scene
CollisionShape provides two APIs for defining the collision geometry. Either setting individual properties such as the \ref CollisionShape::SetShapeType "shape type" or \ref CollisionShape::SetSize "size", or specifying both the shape type and all its properties at once: see for example \ref CollisionShape::SetBox "SetBox()", \ref CollisionShape::SetCapsule "SetCapsule()" or \ref CollisionShape::SetTriangleMesh "SetTriangleMesh()".
-RigidBodies can be either static or moving. A body is static if its mass is 0, and moving if the mass is greater than 0. Note that the triangle mesh collision shape is not supported for moving objects; it will not collide properly due to limitations in the Bullet library. In this case the convex hull shape can be used instead.
+RigidBodies can be either static or moving. A body is static if its mass is 0, and moving if the mass is greater than 0. Note that the triangle mesh collision shape is not supported for moving objects; it will not collide properly due to limitations in the Bullet library. In this case the convex hull or GImpact triangle mesh shape can be used instead.
The collision behaviour of a rigid body is controlled by several variables. First, the collision layer and mask define which other objects to collide with: see \ref RigidBody::SetCollisionLayer "SetCollisionLayer()" and \ref RigidBody::SetCollisionMask "SetCollisionMask()". By default a rigid body is on layer 1; the layer will be ANDed with the other body's collision mask to see if the collision should be reported. A rigid body can also be set to \ref RigidBody::SetTrigger "trigger mode" to only report collisions without actually applying collision forces. This can be used to implement trigger areas. Finally, the \ref RigidBody::SetFriction "friction", \ref RigidBody::SetRollingFriction "rolling friction" and \ref RigidBody::SetRestitution "restitution" coefficients (between 0 - 1) control how kinetic energy is transferred in the collisions. Note that rolling friction is by default zero, and if you want for example a sphere rolling on the floor to eventually stop, you need to set a non-zero rolling friction on both the sphere and floor rigid bodies.
@@ -3787,6 +3787,12 @@ byte[] Bytecode, produced by AngelScript serializer
- The macro \c NULL and 0 should not be used for null pointers, \c nullptr is used instead.
+- \c override is used wherever possible.
+
+- \c using is used instead of \c typedef in type declarations.
+
+- `enum class` is not used because of legacy reasons.
+
- Class definitions proceed in the following order:
- public constructors and the destructor
- public virtual functions
@@ -3800,30 +3806,24 @@ byte[] Bytecode, produced by AngelScript serializer
- Inline functions are defined inside the class definitions where possible, without using the inline keyword.
-Keep contributions consistent with existing code unless wide scale refactoring is performed.
-Follow this guideline to keep code style consistent among contributions and contributors:
+It's recommended to follow <a href="https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md">C++ Core Guidelines</a> (except items that contradict Urho legacy, e.g. ES.107, Enum.3, Enum.5)
-- Use \c override wherever possible.
+Use this brief checklist to keep code style consistent among contributions and contributors:
- Prefer inplace member initialization to initializer lists.
-- Prefer \c using to \c typedef type declarations.
-
- Prefer range-based \c for to old style \c for unless index or iterator is used by itself.
-- Avoid \c enum \c class to keep Urho API consistent. TODO: Perform API-breaking migration to \c enum \c class?
+- Avoid \c auto unless it increases code readability. More details <a href="https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html">here</a> and <a href="https://google.github.io/styleguide/cppguide.html#auto">here</a>.
-- Avoid \c auto unless it increases code readability.
+ - Use \c auto for verbose, unknown or redundant types. Example:
+ \code
+ auto iter = variables.Find(name); // verbose iterator type: HashMap<String, Variant>::Iterator
+ for (auto& variable : variables) { } // verbose pair type: HashMap<String, Variant>::KeyValue
+ auto model = MakeShared<Model>(context_); // type is already mentioned in the expression: SharedPtr<Model>
+ \endcode
-- Use \c auto for verbose, unknown or redundant types. Example:
- \code
- auto iter = variables.Find(name); // verbose iterator type: HashMap<String, Variant>::Iterator
- for (auto& variable : variables) { } // verbose pair type: HashMap<String, Variant>::KeyValue
- auto model = MakeShared<Model>(context_); // type is already mentioned in the expression: SharedPtr<Model>
- \endcode
- See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-auto.html and https://google.github.io/styleguide/cppguide.html#auto
-
-- Use \c auto instead of manual type deduction via \c decltype and \c typename.
+ - Use \c auto instead of manual type deduction via \c decltype and \c typename.
\page ContributionChecklist Contribution checklist