#Burstable way to create entity?
1 messages · Page 1 of 1 (latest)
The only overload I see is with EntityArchetype and to create one I also need ComponentType[]
I guess this works:
state.EntityManager.AddComponent<GameplayInput>(state.EntityManager.CreateEntity()); But not ideal.
Since it is somewhat less efficient and a bit more verbose. Especially for multiple components.
EntityManager..... That's the one place I haven't looked, thanks, I'll try.
I can't find a way to make an archetype without managed code..
ComponentTypeSet is unmanaged
it can be created in burst
here
you can provide type ptr or native array
That's the part I struggle with. I don't know exactly what that means.
Yes, that was one of the first things I tried but couldn't create a ComponentType,
okay, now it worked
ComponentType.ReadOnly<T>()
Okay did it wrong then.
var ctt = new ComponentType(typeof(GameplayInput));
var types = new NativeArray<ComponentType>(1, Allocator.Temp); types[0] = ComponentType.ReadOnly<GameplayInput>(); types[1] = ComponentType.ReadOnly<RawInput>(); state.EntityManager.CreateEntity(state.EntityManager.CreateArchetype(types));
It works but I refuse to believe that this is the best API they've got 🙂
Seems like it can be fixed with extension methods, so I might give that a shot.
that's not very efficient way, obviously, I'd rather cache array of types somehwere
Yeah, that particular entity is only created once and for other cases I think I'm likely to use ecb.
But at least I got it down to a simple burstable extension method:
state.CreateEntity<GameplayInput, RawInput>();
@muted brook Thank you very much for the help!
ECB is not solving a problem of creation though
Yeah, I suspected as much. But hoped it has better api that can take multiple components or sth.
Kinda curious now which is better:
And I'll probably make one that returns archetype, and will be caching it when performance is that important.
forgot to dispose array?
Can throw this into chatGPT to generate more type variants. Should work alright I think.
ECB has one goal and only - delay command execution
you are free not to dispose Temp allocator
but if you do that way too often in 1 frame
Oh, interesting, thanks.
you might run out of memory
for thread
just store prefab instead
and instantiate it
Yes, good point, that will make more sense. I will just use these methods for a nice API for one-off or rarely instantiated things, just to write less code (no caching or prefabs).
Btw, state.WorldUpdateAllocator can be quite nice for this sort of small alloc instead of Allocator.Temp :3