Release 10

Author: gamecode-ci

Documentation/content/cheatsheet.md

@@ -11,11 +11,13 @@ Here is a quick reference of the most useful classes, interfaces, structs, and a
 | Unity.Collections | [NativeHashMap](../../Samples/Packages/com.unity.collections/Unity.Collections/NativeHashMap.cs) | Unsafe Struct |
 | Unity.Collections | [NativeList](../../Samples/Packages/com.unity.collections/Unity.Collections/NativeList.cs) | Unsafe Struct |
 | Unity.Collections | [NativeQueue](../../Samples/Packages/com.unity.collections/Unity.Collections/NativeQueue.cs) | Unsafe Struct |
+| Unity.Entities | [Chunk](../../Samples/Packages/com.unity.entities/Unity.Entities/ArchetypeManager.cs) | Unsafe Struct |
 | Unity.Entities | [ComponentDataArray](../../Samples/Packages/com.unity.entities/Unity.Entities/Iterators/ComponentDataArray.cs) | Unsafe Struct |
 | Unity.Entities | [ComponentDataFromEntity](../../Samples/Packages/com.unity.entities/Unity.Entities/Iterators/ComponentDataFromEntity.cs) | Unsafe Struct |
 | Unity.Entities | [ComponentGroup](../../Samples/Packages/com.unity.entities/Unity.Entities/Iterators/ComponentGroup.cs) | Unsafe Class |
 | Unity.Entities | [ComponentSystem](../../Samples/Packages/com.unity.entities/Unity.Entities/ComponentSystem.cs) | Abstract Class |
 | Unity.Entities | [ComponentType](../../Samples/Packages/com.unity.entities/Unity.Entities/Types/ComponentType.cs) | Struct |
+| Unity.Entities | [DynamicBuffer](../../Samples/Packages/com.unity.entities/Unity.Entities/Iterators/DynamicBuffer.cs) | Unsafe Struct |
 | Unity.Entities | [Entity](../../Samples/Packages/com.unity.entities/Unity.Entities/EntityManager.cs) | Struct |
 | Unity.Entities | [EntityArchetype](../../Samples/Packages/com.unity.entities/Unity.Entities/EntityManager.cs) | Unsafe Struct |
 | Unity.Entities | [EntityCommandBuffer](../../Samples/Packages/com.unity.entities/Unity.Entities/EntityCommandBuffer.cs) | Unsafe Struct |

Documentation/content/chunk_iteration.md

@@ -1,20 +1,20 @@
 # Dynamic Buffers
 
-A dynamic buffer is a type of component data that allows a variable-sized, "stretchy"
-buffer to be associated with an Entity. It behaves as a component type that
+A `DynamicBuffer` is a type of component data that allows a variable-sized, "stretchy"
+buffer to be associated with an `Entity`. It behaves as a component type that
 carries an internal capacity of a certain number of elements, but can allocate
 a heap memory block if the internal capacity is exhausted.
 
 Memory management is fully automatic when using this approach. Memory associated with
-dynamic buffers is managed by the Entity Manager so that when a dynamic buffer
+`DynamicBuffers` is managed by the `EntityManager` so that when a `DynamicBuffer`
 component is removed, any associated heap memory is automatically freed as well.
 
-Dynamic buffers supersede fixed array support which has been removed.
+`DynamicBuffers` supersede fixed array support which has been removed.
 
 ## Declaring Buffer Element Types
 
-To declare a buffer, you declare it with the type of element that you will be
-putting into the buffer:
+To declare a `Buffer`, you declare it with the type of element that you will be
+putting into the `Buffer`:
 
  // This describes the number of buffer elements that should be reserved
  // in chunk data for each instance of a buffer. In this case, 8 integers
@@ -31,21 +31,21 @@ putting into the buffer:
   public int Value;
  }
 
-While it seem strange to describe the element type and not the buffer itself,
+While it seem strange to describe the element type and not the `Buffer` itself,
 this design enables two key benefits in the ECS: 
 
-1. It supports having more than one dynamic buffer of type `float3`, or any
- other common value type. You can add any number of buffers that leverage the
+1. It supports having more than one `DynamicBuffer` of type `float3`, or any
+ other common value type. You can add any number of `Buffers` that leverage the
  same value types, as long as the elements are uniquely wrapped in a top-level
  struct.
 
-2. We can include buffer element types in Entity archetypes, and it generally
+2. We can include `Buffer` element types in `EntityArchetypes`, and it generally
  will behave like having a component.
 
 ## Adding Buffer Types To Entities
 
-To add a buffer to an Entity, you can use the normal methods of adding a
-component type onto an Entity:
+To add a buffer to an `Entity`, you can use the normal methods of adding a
+component type onto an `Entity`:
 
 ### Using AddBuffer()
 
@@ -57,7 +57,7 @@ component type onto an Entity:
 
 ## Accessing Buffers
 
-There are several ways to access dynamic buffers, which parallel access methods
+There are several ways to access `DynamicBuffers`, which parallel access methods
 to regular component data.
 
 ### Direct, main-thread only access 
@@ -67,8 +67,8 @@ to regular component data.
 ### Injection based access
 
 Similar to `ComponentDataArray` you can inject a `BufferArray` which provides
-the dynamic buffers in a parallel array to the other injections. This example
-provides a system that appends a value to every buffer in an injected set:
+the `DynamicBuffers` in a parallel array to the other injections. This example
+provides a system that appends a value to every `Buffer` in an injected set:
 
  public class InjectionDemo : JobComponentSystem
  {
@@ -98,7 +98,7 @@ provides a system that appends a value to every buffer in an injected set:
 
 ## Entity based access
 
-You can also look up buffers on a per-entity basis:
+You can also look up `Buffers` on a per-`Entity` basis:
 
   var lookup = GetBufferArrayFromEntity<EcsIntElement>();
   var buffer = lookup[myEntity];
@@ -108,19 +108,19 @@ You can also look up buffers on a per-entity basis:
 ## Entity based injection access
 
 Similarly to injecting `ComponentDataFromEntity` you can inject
-`BufferDataFromEntity` and look up buffers indirectly. 
+`BufferDataFromEntity` and look up `Buffers` indirectly. 
 
 ## Reinterpreting Buffers (experimental)
 
-Buffers can be reinterpreted as a type of the same size. The intention is to
+`Buffers` can be reinterpreted as a type of the same size. The intention is to
 allow controlled type-punning and to get rid of the wrapper element types when
 they get in the way. To reinterpret, simply call `Reinterpret<T>`:
 
  var intBuffer = entityManager.GetBuffer<EcsIntElement>().Reinterpret<int>();
 
-The reinterpreted buffer carries with it the safety handle of the original
-buffer, and is safe to use. They use the same underlying buffer header, so
-modifications to one reinterpreted buffer will be immediately reflected in
+The reinterpreted `Buffer` carries with it the safety handle of the original
+`Buffer`, and is safe to use. They use the same underlying `BufferHeader`, so
+modifications to one reinterpreted `Buffer` will be immediately reflected in
 others.
 
 Note that there are no type checks involved, so it is entirely possible to

Documentation/content/dynamic_buffers.md

@@ -5,3 +5,7 @@
 ## Concurrent NativeContainer types
 
 Some `NativeContainer` types also have special rules for allowing safe and deterministic write access from ParallelFor jobs. As an example, the method `NativeHashMap.Concurrent` lets you add items in parallel from [IJobParallelFor](https://docs.unity3d.com/2018.1/Documentation/ScriptReference/Unity.Jobs.IJobParallelFor.html).
+
+## Concurrent EntityCommandBuffers
+
+When using an `EntityCommandBuffer` to issue `EntityManager` commands from ParallelFor jobs, the `EntityCommandBuffer.Concurrent` interface must be used in order to guarantee thread safety and deterministic playback. The public methods in this interface take an extra `jobIndex` parameter, which is used to play back the recorded commands in a deterministic order. `jobIndex` must be a unique ID for each job. For performance reasons, `jobIndex` should be related to the (increasing) `index` values passed to `IJobParallelFor.Execute()`. Unless you *really* know what you're doing, using `index` as `jobIndex` is the safest choice. Using other `jobIndex` values will produce correct output, but can have severe performance implications in some cases.

Documentation/content/job_system.md

@@ -8,11 +8,11 @@
 
 ## Concept
 
-The general use of a SystemStateComponent is expected to mirror a user component, providing the internal state.
+The general use of a [SystemStateComponent](system_state_components.md) is expected to mirror a user component, providing the internal state.
 
 For instance, given:
-- FooComponent (ComponentData, user assigned)
-- FooStateComponent (SystemComponentData, system assigned)
+- FooComponent (`ComponentData`, user assigned)
+- FooStateComponent (`SystemComponentData`, system assigned)
 
 ### Detecting Component Add
 
@@ -24,12 +24,12 @@ When user removes FooComponent, FooStateComponent still exists. The FooSystem up
 
 ### Detecting Destroy Entity
 
-DestroyEntity is actually a shorthand utility for:
+`DestroyEntity` is actually a shorthand utility for:
 - Find Components which reference given Entity ID.
 - Delete Components found
 - Recycle Entity ID
 
-However, SystemStateComponents are not removed on DestroyEntity and the Entity ID is not recycled until the last component is deleted. This gives the System the opportunity to clean up the internal state in the exact same way as with component removal.
+However, `SystemStateComponents` are not removed on `DestroyEntity` and the Entity ID is not recycled until the last component is deleted. This gives the System the opportunity to clean up the internal state in the exact same way as with component removal.
 
 ## SystemStateComponent
 
@@ -41,7 +41,7 @@ struct FooStateComponent : ISystemStateComponentData
 }
 ```
 
-Visibility of a SystemStateComponent is also controlled in the same way as a Component (using `private`, `public`, `internal`) However, it's expected, as a general rule, that a SystemStateComponent will be ReadOnly outside the system that creates it.
+Visibility of a `SystemStateComponent` is also controlled in the same way as a `Component` (using `private`, `public`, `internal`) However, it's expected, as a general rule, that a `SystemStateComponent` will be `ReadOnly` outside the system that creates it.
 
 ## SystemStateSharedComponent
 

Documentation/content/system_state_components.md

@@ -1,14 +1,14 @@
 # TransformSystem
 
-TransformSystem is responsible for updating the `LocalToWorld` transformation matrices used by other systems (including rendering).
+[TransformSystem](transform_system.md) is responsible for updating the `LocalToWorld` transformation matrices used by other systems (including rendering).
 
 ## Updating a TransformSystem
 
-By default, Unity updates a single TransformSystem instance each frame. `EndFrameTransformSystem` is updated before `EndFrameBarrier` and requires no additional work.
+By default, Unity updates a single `TransformSystem` instance each frame. `EndFrameTransformSystem` is updated before `EndFrameBarrier` and requires no additional work.
 
 In cases where transform data is required to be updated at additional points in the frame, the suggested methods are:
 
-- Create additional instance(s) of TransformSystem and use UpdateBefore/UpdateAfter attributes to control where they are updated.
+- Create additional instance(s) of `TransformSystem` and use `UpdateBefore`/`UpdateAfter` attributes to control where they are updated.
 
 For example:
 
@@ -18,7 +18,7 @@ For example:
  {
  }
 ```
-- Create additional instance of TransformSystem and update after *every* ComponentSystem (includes Barriers, excludes JobComponentSystem) by using \[ComponentSystemPatch\] attribute. Be aware that the overhead for updating the TransformSystem after every ComponentSystem can be very high when the number of ComponentSystems is large.
+- Create additional instance of `TransformSystem` and update after *every* `ComponentSystem` (includes `Barriers`, excludes `JobComponentSystem`) by using \[ComponentSystemPatch\] attribute. Be aware that the overhead for updating the `TransformSystem` after every `ComponentSystem` can be very high when the number of `ComponentSystems` is large.
 
 For example:
 
@@ -33,7 +33,7 @@ For example:
 
 ## Updating Position, Rotation, Scale
 
-The only requirement for TransfromSystem is that *one of* the following components is associated with an Entity:
+The only requirement for `TransfromSystem` is that *one of* the following components is associated with an `Entity`:
 
 ```
  public struct Position : IComponentData
@@ -52,7 +52,7 @@ The only requirement for TransfromSystem is that *one of* the following componen
  }
 ```
 
-TransformSystem will add the `LocalToWorld` component and update the matrix based on the values in your selected associated components (Position, Rotation, and Scale). LocalToWorld does not need to be added by the user or other systems.
+`TransformSystem` will add the `LocalToWorld` component and update the matrix based on the values in your selected associated components (`Position`, `Rotation`, and `Scale`). `LocalToWorld` does not need to be added by the user or other systems.
 
 ```
  public struct LocalToWorld : ISystemStateComponentData
@@ -61,32 +61,32 @@ TransformSystem will add the `LocalToWorld` component and update the matrix base
  }
 ```
 
-LocalToWorld is expected to be ReadOnly by other systems. Be aware that anything written to this component will be overwritten and its behavior during update is undefined if written to.
+`LocalToWorld` is expected to be `ReadOnly` by other systems. Be aware that anything written to this component will be overwritten and its behavior during update is undefined if written to.
 
 ## Freezing transforms
 
-In many cases, individual transforms are *never* expected to change at runtime. For these types of objects, if a Static component is added:
+In many cases, individual transforms are *never* expected to change at runtime. For these types of objects, if a `Static` component is added:
 
 ```
  public struct Static : IComponentData
  {
  }
 ```
 
-They will cease to be updated after the LocalToWorld matrix has been created and updated for the first time. Any changes to associated Position, Rotation, or Scale components will be ignored. Marking `Static` transforms can substantially reduce the amount of work a TransformSystem needs to do which will improve performance.
+They will cease to be updated after the `LocalToWorld` matrix has been created and updated for the first time. Any changes to associated `Position`, `Rotation`, or `Scale` components will be ignored. Marking `Static` transforms can substantially reduce the amount of work a `TransformSystem` needs to do which will improve performance.
 
 The process of freezing is:
-1. TransformSystem update queries for Static components.
-2. TransformSystem adds FrozenPending component.
-3. TransformSystem updates the LocalToWorld component normally.
-4. On the next TransformSystem update, queries for FrozenPending components and adds Frozen component.
-5. TransformSystem ignores Position, Rotation, or Scale components if there is an associated Frozen component.
+1. `TransformSystem` update queries for `Static` components.
+2. `TransformSystem` adds `FrozenPending` component.
+3. `TransformSystem` updates the `LocalToWorld` component normally.
+4. On the next `TransformSystem` update, queries for `FrozenPending` components and adds Frozen component.
+5. `TransformSystem` ignores `Position`, `Rotation`, or `Scale` components if there is an associated Frozen component.
 
 If necessary, users can detect if LocalToWorld matrix is frozen by existence of a `Frozen` component. Generally however, identifying static objects by the existence of the `Static` component is sufficient.
 
 ## Custom transforms
 
-In cases where user systems require custom transformation matrices and updates, the TransformSystem will ignore components associated with a `CustomLocalToWorld` component.
+In cases where user systems require custom transformation matrices and updates, the `TransformSystem` will ignore components associated with a `CustomLocalToWorld` component.
 
 ```
  public struct CustomLocalToWorld : IComponentData
@@ -109,7 +109,7 @@ Attaching transformations (transformation hierarchies) is controlled by separate
  }
 ```
 
-To attach a Child Entity to a Parent Entity, create a new Entity with an associated Attach component, assigning the respective values.
+To attach a Child `Entity` to a Parent `Entity`, create a new `Entity` with an associated `Attach` component, assigning the respective values.
 
 For example:
 
@@ -124,9 +124,9 @@ For example:
  m_Manager.SetComponentData(attach, new Attach {Parent = parent, Child = child});
 ```
 
-1. The Attach component, and associated Entity, will be destroyed by the TransformSystem on update.
-2. Values in Position, Rotation, and Scale components will be interpreted as relative to parent space.
-3. Attached, Parent, and LocalToParent components will be associated with the Child Entity.
+1. The `Attach` component, and associated `Entity`, will be destroyed by the `TransformSystem` on update.
+2. Values in `Position`, `Rotation`, and `Scale` components will be interpreted as relative to parent space.
+3. `Attached`, `Parent`, and `LocalToParent` components will be associated with the Child `Entity`.
 
 ```
  public struct Attached : IComponentData
@@ -146,11 +146,11 @@ For example:
 
 ## Detaching transformations
 
-To detach a child from a parent, remove the `Attached` component from the child. When the TransformSystem is updated, the Parent component will be removed. Values in Position, Rotation, and Scale components will be interpreted as relative to world space.
+To detach a child from a parent, remove the `Attached` component from the child. When the `TransformSystem` is updated, the Parent component will be removed. Values in `Position`, `Rotation`, and `Scale` components will be interpreted as relative to world space.
 
 ## Reading World values
 
-The LocalToWorld matrix can be used to retrieve world positions.
+The `LocalToWorld` matrix can be used to retrieve world positions.
 For example:
 
 ```

Documentation/content/transform_system.md

@@ -1,3 +1,20 @@
+# 0.0.12
+## New Features
+
+## Upgrade guide
+* OnCreateManager(int capacity) -> OnCreateManager(). All your own systems have to be changed to follow the new signature.
+
+## Changes
+* Removed capacity parameter from from ScriptBehaviourManager.OnCreateManager.
+* EntityDebugger now displays the declaring type for nested types
+* IncrementalCompiler is no longer a dependency on the entities package. If you want to continue to use it you need to manually include it from the package manager UI for your project.
+* `EntityCommandBuffer.Concurrent` playback is now deterministic. Playback order is determined by the new `jobIndex` parameter accepted by all public API methods, which must be a unique ID per job (such as the index passed to `Execute()` in an IJobParallelFor).
+
+## Fixes
+* Fixed bug where ComponentDataWrapper fields spilled out of their area in the Inspector.
+* ComponentDataWrapper for empty data types (i.e. tags) no longer displays error in Inspector if wrapped type is not serializable.
+* Fixed an issue where EntityDebugger was slow if you scrolled down past 3 million entities
+
 # 0.0.11
 ## New Features
 * Global `Disabled` component. Any component data associated with same entity referenced by `Disabled` component will be ignored by all system updates.

ReleaseNotes.md

@@ -286,7 +286,7 @@ protected override void OnUpdate()
  boardEntities.Dispose();
  }
 
- protected override void OnCreateManager(int capacity)
+ protected override void OnCreateManager()
  {
  OuterWallTileGroup = GetComponentGroup(
  ComponentType.ReadOnly(typeof(BoardReference)),

Samples/Assets/Dungeon/Scripts/BoardSystem.cs

@@ -1,7 +1,9 @@
-using Unity.Entities;
+using System;
+using Unity.Entities;
 
 namespace Samples.Dungeon.First
 {
+ [Serializable]
  public struct FloorTile : IComponentData
  {
  }

Samples/Assets/Dungeon/Scripts/FloorTileComponent.cs

@@ -1,7 +1,9 @@
-using Unity.Entities;
+using System;
+using Unity.Entities;
 
 namespace Samples.Dungeon.First
 {
+ [Serializable]
  public struct OuterWallTile : IComponentData
  {
  }