Update README.md
This commit is contained in:
33
README.md
33
README.md
@@ -107,7 +107,8 @@ CMake version 3.4 or later is mandatory to compile the tests, you don't have to
|
||||
|
||||
## Library
|
||||
|
||||
`EnTT` is a header-only library. This means that including the `registry.hpp` header is enough to use it. It's a matter of adding the following line at the top of a file:
|
||||
`EnTT` is a header-only library. This means that including the `registry.hpp` header is enough to use it.<br/>
|
||||
It's a matter of adding the following line at the top of a file:
|
||||
|
||||
#include <registry.hpp>
|
||||
|
||||
@@ -168,7 +169,11 @@ Note that entities are numbers and nothing more. They are not classes and they h
|
||||
|
||||
#### The View
|
||||
|
||||
There are two different kinds of view, each one with a slighlty different interface: the single component view and the multi component view.<br/>
|
||||
There are two different kinds of view, each one with a slighlty different interface:
|
||||
|
||||
* The _single component view_.
|
||||
* The _multi component view_.
|
||||
|
||||
Both of them are iterable, that is both of them have `begin` and `end` member functions that are suitable for a range-based for loop:
|
||||
|
||||
```
|
||||
@@ -180,18 +185,28 @@ for(auto entity: view) {
|
||||
```
|
||||
|
||||
Iterators are extremely poor, they are meant exclusively to be used to iterate over a set of entities.<br/>
|
||||
Exposed member functions are: `operator++()`, `operator++(int)`, `operator==()`, `operator!=()` and `operator*()`.
|
||||
Exposed member functions are:
|
||||
|
||||
The single component view has also a member function named `size` that returns the exact number of expected entities.<br/>
|
||||
The multi component view has also a member function named `reset` that reorganizes internal data to create optimized iterators.
|
||||
Use it whenever the data within the registry are known to be changed.<br/>
|
||||
Both the views can be used more than once, for they return newly created and correctly initialized iterators whenever
|
||||
* `operator++()`
|
||||
* `operator++(int)`
|
||||
* `operator==()`
|
||||
* `operator!=()`
|
||||
* `operator*()`.
|
||||
|
||||
The single component view has an additional member function:
|
||||
|
||||
* `size()`: returns the exact number of expected entities.
|
||||
|
||||
The multi component view has an additional member function:
|
||||
|
||||
* `reset()`: reorganizes internal data so as to further create optimized iterators (use it whenever the data within the registry are known to be changed).
|
||||
|
||||
Both the views can be used more than once. They return newly created and correctly initialized iterators whenever
|
||||
`begin` or `end` is invoked. Anyway views and iterators are tiny objects and the time to construct them can be safely ignored.
|
||||
I'd suggest not to store them anywhere and to invoke the `Registry::view` member function at each iteration to get a properly
|
||||
initialized view over which to iterate.
|
||||
|
||||
**Note**.<br/>
|
||||
An important feature (usually missed by other well known ECS) is that users can create and destroy entities, as
|
||||
**Note**: An important feature (usually missed by other well known ECS) is that users can create and destroy entities, as
|
||||
well as assign or remove components while iterating and neither the views nor the iterators will be invalidated.<br/>
|
||||
Therefore, unless one tries to access a destroyed entity through an iterator that hasn't been advanced (in this case, of course,
|
||||
it's an undefined behaviour), users can freely interact with the registry and keep views and iterators consistent.<br/>
|
||||
|
||||
Reference in New Issue
Block a user