Now BinaryWriter\Reader interface (StreamBinaryReader\Writer implements this) has extensions for read\write bytes from\to NativeArray (also NativeList for BinaryWriter), that mean now we can serialaze\deserialize NativeArrays more simply.
GetFixedArrayFromEntity now replaced to GetBufferArrayFromEntity and returns BufferDataFromEntity instead FixedArrayFromEntity (In ECB and EM), Also GetFixedArray replaced to GetBuffer, dont forget review your code
EntityCommandBuffer now implements IDisposable and have public Dispose method, also added new methods AddBuffer\SetBuffer (EntityManager also have this new methods) for manupulating new DynamicBuffer.
Small renaming GetAllUniqueSharedComponentDatas → GetAllUniqueSharedComponentData
AddMatchingArchetypes now use EntityArchetypeQuery instead separate ComponentType[ ] for any, none, all.
Added new Interface IBufferElementData for Buffers, in line with IComponentData and ISharedComponentData!
Fixed arrays now replaced in many places (include injection) to Buffers.
Very great rewrites in Transform system, include hierarchy logic!
Depend on previous, now exists new components for Parent\Child logic! Also added Scale for transform system! Now TransformMatix component not needed and not exists
Not sure when they added it but now math lib has Random struct which can do random inside itself. Also why the decision to use big Q for math.quaternion? It is going to clash with the normal ones… I have to fully qualify them everywhere now.
I think that for code readibility is better to fully qualify them. Difference in first letter’s case could be much more confusing. And for people who learned C# outside Unity are lowercase names for classes and public members irritating anyway
It is possible to add using quaternion = math.Quaternion; as a simple fix for now. I’m also not sure as it feels this goes against some of the naming conventions, but this should make fixing up a current project simpler.
I’ve long since given up bothering to argue about this. Could use using to sort the difference (its highly unlikely ECS code is mixed with regular Unity code anyway). So there could be consistency if Unity wants it. But Unity wants lower case in line with shader programming for ECS.
In any case, namespaces are the solution. You never name things differently because you fear the rest of the API has the same name.
Yep, I was assuming that IF they chose to make all the math lib cased like the Unity API, then using would sort it out. So it’s not a problem if they do that.
What is a problem though is if this is just the only upper case dude. That would just become totally random.
I get use to capitalized Quaternion and Vector. And I really prefer that way. But on other hand, now in ECS they are supposedly constructed differently (?), so makes sense to keep them small cased. Or otherwise, along with Quaternion there should be Float3, Int2, Bool4 etc. (capitalized).
Well, I prefer standard C# naming conventions, but honestly, with possibilities of today’s IDEs I can be using anything. It’s just that one would expect from such a mature engine that they will choose one or another and will stick to it.
I just wanted to pop up to point enthusiastically at this answer.
Also wanted to point out assemblies can also resolve this. So many ways to get around this. If you have an intelligent IDE like Rider or plugin like Resharper, you can make these changes in a click btw.
No warnings or automatic updated for preview packages which makes sense. They would need to include all types as deprecated for the time being. I think this is okay. A changelog would be great thought.
TransformMatrix is currently a little bit complicated. There is LocalToWorld which is automatically filled by TransformSystem from Position and stuff, and CustomLocalToWorld which is under your control. Problem is all systems reading the transform currently need to handle both. I would prefer CustomLocalToWorld just being a tag component which prevents TransformSystem from touching LocalToWorld. Wouldn’t take any additional space and make reading alot simpler.
When you want to set the local to world matrix directly you currently have to set CustomLocalToWorld.
Our use of TransformMatrix is not that sophisticated. We just use it to transform vertices. I’m just bummed that I could no longer use my ECS pet project to our current game. I have to fix it first. Marking as deprecated would have been fine.
Anyhow, it seems TransformMatrix is now known as RigidTransform.
No, it’s not. RigidTransform is not a component. It’s is just math to represent and work with rigid transforms. TransformMatrix is replaced by LocalToWorld/CustomLocalToWorld as I explained above.
