Pointers to archetype chunks and IComponentData?

[narrow nymph]

I am wondering, what is the way to get a real read/write pointer to the actual chunk data and obtain the information necessary to do arithmetic and step over it quickly and efficiently? Is the any kind of diagram of how a "chunk" is composed and what kind of alignment/padding they use and so forth, and what APIs are there to obtain that sort of information to know what sizeof(...) and count math to check ... ? And are there sets of rules or "golden assumptions" that can be made about alignment/offset within a chunk due to the nature of the DOTS architecture?

It seems like a lot of calling different methods to get at something I could much more easily do with pointer arithmetic and old school C-style programming sometimes (at least with less "noise" in the code, much less keystrokes/text) ...

I know, I know ... and to be honest with you, I'm already using "unsafe" code for speed/simplicity in other ways, have "unsafe" plugins I built that would make the C# police gasp and other scary things happening, haha! It's "academic", we're not hurting anything! 😄

I just need to know this in my quest to become one with the Great Archetype and receive the chunks of its wisdom

[tropic oriole]

The lowest-level method available in the public API is

public readonly T* ArchetypeChunk.GetComponentDataPtrRO<T>(ref ComponentTypeHandle<T> typeHandle)

(and the read-write equivalent, GetComponentDataPtrRW()
It gives you a pointer directly into the chunk's component data for type T, in a thread-safe way (i.e. if another thread has exclusive write access to this component, this method will throw). It is most similar to the .GetNativeArray<T>() method, but avoids the overhead of creating a NativeArray to wrap the data. If you're just going to be iterating over the data and don't plan on passing the array to a job or indexing it out-of-bounds, the NativeArray wrapper isn't buying you anything.

You can read the chunk's entity count from ArchetypeChunk.Count. Other safe assumptions I can think of, let's see...

• There will never* be more than 128 entities in a chunk. (* "never" is a long time; let me qualify that as "...within the scope of Entities 1.x")
• Each component's data is aligned to JobsUtility.CacheLineSize (which seems to be hard-coded to 64 bytes, afaict)
• Components in the array are tightly packed according to their natural alignment requirements. So, the T* you get back can be safely indexed like an array; no need for fancy byte-level extraction.

Anything else that would be helpful?