WIP: docs

README.md

@@ -44,8 +44,7 @@ int main() {
 
     for(auto entity: ecs.view<Position>()) {
         auto &position = ecs.get<Position>(entity);
-        // do whatever is needed with position
-        (void)position;
+        // ...
     }
 
     // multi component view
@@ -53,24 +52,23 @@ int main() {
     for(auto entity: ecs.view<Position, Velocity>()) {
         auto &position = ecs.get<Position>(entity);
         auto &velocity = ecs.get<Velocity>(entity);
-        // do whatever is needed with position and velocity
-        (void)position;
-        (void)velocity;
+        // ...
     }
 }
 ```
 
 ## Motivation
 
-I started working on `EnTT` because of the wrong reason: my goal was to beat another well known open source _ECS_ in terms of performance. I did it, of course, but it wasn't much satisfying. Actually it wasn't satisfying at all. The fastest and nothing more, fairly little indeed.<br/>
+I started working on `EnTT` because of the wrong reason: my goal was to beat another well known open source _ECS_ in terms of performance.
+I did it, of course, but it wasn't much satisfying. Actually it wasn't satisfying at all. The fastest and nothing more, fairly little indeed.
 When I realized it, I tried hard to keep intact the great performance and to add all the features I want to see in my _ECS_ at the same time.
 
 Today `EnTT` is finally what I was looking for: still faster than its rivals, a really good API and an amazing set of features.
 
 ### Performance
 
-As it stands right now, `EnTT` is just fast enough for my requirements if compared to my first choice (a well known open source _ECS_ that was already amazingly fast).<br/>
-Here is a comparision (both of them compiled with GCC 7.2.0 on a Dell XPS 13 coming from the late 2014):
+As it stands right now, `EnTT` is just fast enough for my requirements if compared to my first choice (that was already amazingly fast indeed).<br/>
+Here is a comparision between the two (both of them compiled with GCC 7.2.0 on a Dell XPS 13 out of the mid 2014):
 
 | Benchmark | EntityX (experimental/compile_time) | EnTT |
 |-----------|-------------|-------------|
@@ -87,10 +85,10 @@ Here is a comparision (both of them compiled with GCC 7.2.0 on a Dell XPS 13 com
 | Iterating over 50M entities, unpacking one component | 0.0530271s | **7.7e-08s** |
 | Iterating over 50M entities, unpacking two components | 0.056233s | **0.0161715s** |
 
-See [benchmark.cpp](https://github.com/skypjack/entt/blob/master/test/benchmark.cpp) for further details.<br/>
-Even though `EnTT` includes its own tests and benchmarks, on Github there exists also a [benchmark suite](https://github.com/abeimler/ecs_benchmark) that compares a bunch of different projects, one of which is `EnTT`.
+`EnTT` includes its own tests and benchmarks. See [benchmark.cpp](https://github.com/skypjack/entt/blob/master/test/benchmark.cpp) for further details.<br/>
+On Github users can find also a [benchmark suite](https://github.com/abeimler/ecs_benchmark) that compares a bunch of different projects, one of which is `EnTT`.
 
-Of course, I'll try to get out of `EnTT` more features and better performance anyway in the future, mainly for fun.<br/>
+Of course, I'll try to get out of `EnTT` more features and better performance in the future, mainly for fun.<br/>
 If you want to contribute and/or have any suggestion, feel free to make a PR or open an issue to discuss your idea.
 
 # Build Instructions
@@ -115,8 +113,8 @@ Then pass the proper `-I` argument to the compiler to add the `src` directory to
 
 ### API Reference
 
-Unfortunately `EnTT` isn't documented yet and thus users cannot rely on in-code documentation.<br/>
-Source code and names are self-documenting and I'm pretty sure that a glimpse to the API is enough for most of the users.<br/>
+Unfortunately `EnTT` isn't documented yet and thus users cannot rely on in-code documentation.
+Source code and names are self-documenting and I'm pretty sure that a glimpse to the API is enough for most of the users.
 For all the others, below is a crash course that guides them through the project and tries to fill the gap.
 
 ### Crash Course
@@ -377,9 +375,9 @@ There are two types of views:
 
   This is the fastest approach to iterate over the components: they are packed together by construction and visit them in order will reduce to a minimum the number of cache misses.
 
-* **Multi components view**.
+* **Multi component view**.
 
-  A multi components view gives access only to the entities to which the components are assigned.<br/>
+  A multi component view gives access only to the entities to which the components are assigned.<br/>
   This kind of views are created from the `Registry` class by means of the `view` member function template as it follows:
 
     ```cpp
@@ -388,7 +386,7 @@ There are two types of views:
     auto view = registry.view<Position, Velocity>();
     ```
 
-  Multi components views can be iterated by means of the `begin` and `end` member functions in a typical range-for loop:
+  Multi component views can be iterated by means of the `begin` and `end` member functions in a typical range-for loop:
 
     ```cpp
     auto view = registry.view<Position, Velocity>();
@@ -400,7 +398,7 @@ There are two types of views:
     }
     ```
 
-  Note that there exists a packed array of entities to which the component is assigned for each component. Iterators of a multi components view pick the shortest array up and use it to visit the smallest set of potential entities.<br/>
+  Note that there exists a packed array of entities to which the component is assigned for each component. Iterators of a multi component view pick the shortest array up and use it to visit the smallest set of potential entities.<br/>
   The choice is performed when the view is constructed. It's good enough as long as views are discarded once they have been used. For all the other cases, the `reset` member function can be used whenever the data within the registry are known to be changed and forcing the choice again could speed up the execution.
 
   **Note**: one could argue that an iterator should return the set of references to components for each entity instead of the entity itself. Well, who wants to spend CPU cycles to get a reference to an useless tag component? This drove the design choice indeed.