so I've been trying to wrap my head around this page in the documentation
https://docs.unity3d.com/Packages/com.unity.entities@1.3/manual/components-nativecontainers.html
at the end it says you're able to to chain jobs across multiple systems without having to complete job dependencies "avoid completing unnecessary dependencies"
but how? should I store the jobhandles in that singleton as well? and then call jobhandle complete on the next system? am I missing something here?
#chaining jobs across multiple systems with native containers in icomponentdata
1 messages · Page 1 of 1 (latest)
When you get the singleton, the handle returned from that procedure will be combined with state.Dependency. And then you pass state.Dependency into the Schedule method to achieve this chaining.
should I store the jobhandles
AFAIK, you shouldn't store JobHandle anywhere. It must be eventually combined withstate.Dependencyat some point.
when I get the singleton it just returns the component (or the wrapper of the component if I wanted a RW), or should I do it inside the job constructor?
You use SystemAPI to get the singleton, right?
yes
Then you should know that SystemAPI on its own does nothing. The methods of SystemAPI are just stub (empty) methods. They just act as markers for something else: source generators.
Inside a system, the method contains a call to SystemAPI will be rewritten into the actual method.
Your code will never run. Only the actual method generated by SystemAPI source generator will run.
Under the hood the generated code contains a lot of boilerplate code (those you have to write manually if you don't use SystemAPI), some of the code will handle dependency or assist the system on handling dependency on singletons.
public struct SingletonComponent : IComponentData
{
public int data;
}
public partial struct SampleSystem : ISystem
{
private readonly void SampleMethod(ref SystemState state, int newData)
{
if (SystemAPI.HasSingleton<SingletonComponent>())
{
var singletonRW = SystemAPI.GetSingletonRW<SingletonComponent>();
singletonRW.ValueRW.data = newData;
}
}
}
Such simple code will generate a lot of boilerplate code to assist it.
Put the cursor on the system name and use "Go to definition" on VS or Rider, you will see the generated parts.
There will be a method looks similar to __SampleMethod_17B16FA2 which is the actual method that will run in place of SampleMethod
This code will generate 2 EntityQuery and 1 TypeHandle to assist the dependency mechanism for this system.
From the user's POV, you don't have to do anything complicate. Just follow the tutorials, read the document (as you're doing).
I only explain the underhood because you want to understand it more. But it shouldn't affect how you use SystemAPI in general.
ah now I see, I already knew about the source generation but didn't know this could be done
thank you so much