Burst cannot compile, when a bool is inside a ref IComponentData

[compact blade]

Is this a bug or intended?
I have noticed the same a few months ago, but have ignored it and just used an enum instead

[quaint iron]

are you sure your NativeArray with tuple is valid?

[compact blade]

yes everything compiled
after adding IsBuilding today and doing some other tests the bool has to be at fault

when I change bool to BoolAB (a byte enum with True and False) it works too

[quaint iron]

oh

bool is not blittable

errors says it

just use byte

or int

instead

[compact blade]

yep I know but Unity should have done some stuff for that

[quaint iron]

I mean, they could write their own C# ig 😅

[compact blade]

I could swear I read threads about that Unity has done somthing for the bool internally

[quaint iron]

but I'd rather them stick to .net and migrate to modern version

[quaint iron]

nah

it's not blittable in C#

so forced to deal with it

[compact blade]

wait but why does this compile then?

[quaint iron]

because it's inside of bursted method

not at root

when you burst compile static method, this exact method declaration will be entry point into native world

so all parameters must be blittable

and passed by reference

[compact blade]

even though the struct has a non blittable bool?

[quaint iron]

it's not an entry point into native code

it is part of native code

consider entry point is like extern method

[compact blade]

I see, I will take a look at all that then

[quaint iron]

it has all same limitations basically

[pearl dirge]

A proper bytebool struct would be more helpful.

[compact blade]

Do you mean something like that?

ups

you said byte

byte instead of bool for the value

[pearl dirge]

more like this 😂

[compact blade]

holy that's way more than I thought of 😅 😂

that's really good, don't mind me reusing the code 👀

[pearl dirge]

it surely makes my boolean code looks "normal"

[compact blade]

yeah I get the chills, whenever I have to do an if like that

BoolAB val...;

if (val == BoolAB.True)

thanks for sharing! :)

[raw pumice]

Wait, isn't this doc https://docs.unity3d.com/Packages/com.unity.entities@1.1/manual/components-unmanaged.html explicitly saying that unmanaged components can store both blittable types and bools?

[slim falcon]

Yes totally fine to store them and use them

You just can't use them on function pointers

If you've ever tried to write a native function with a bool field and then marshal can it from c# you'll know the issue

[raw pumice]

Ok, I've never marshalled bools tbh

So the issue here is that this component is used in a bursted method

Which is like almost use case number one for unmanaged components, but the docs say nothing about it

[slim falcon]

Yeah I'm not sure why OP is even using one instead of just a bursted job but that was the issue

[compact blade]

I knew I have read it somewhere 😅

[compact blade]

I had to move my function up to the ISystem, since it's now being used by 2 Jobs, instead of 1 and the function wouldn't Burstcompile without the ref/in

[slim falcon]

why would it not be burst compiled?

i assume your OnUpdate is burst compiled since it's ISystem

so any method it calls is burst compiled - it doesn't need the attribute that's just creating a second separate compiled method

[compact blade]

I can check tomorrow again, but I had problems with that a few months back

[compact blade]

Oohh I didn't know, that's good to know. I have been putting the burst compile Attribute over every valid function (except jobs)

[slim falcon]

yeah that's not great

[compact blade]

But I am still far away from being an expert, since I just started with dots a few months back 😅

[slim falcon]

basically once you're in burst, it's very hard to leave burst

you have to do some real magic to call code that isn't bursted from burst

so if you're in a bursted OnUpdate anything called from there is bursted

(same as a bursted job execute method)

when using actual entities you only need [BurstCompile] OnUpdate (create/destroy etc) and the top of jobs

[compact blade]

What about a Utils class which has manged functions as well?

And bursted functions

[slim falcon]

if it's called from burst

it's bursted

[BurstCompile]
public struct Job : IJob 
{
    public void Execute()
    {
        MyUtility.DoMagic();
    }
}```

DoMagic is always bursted

[compact blade]

Should I keep a seperate burst compiled class for bursted code? Since the ide is telling me to do that constantly

[slim falcon]

if DoMagic is not burstable, burst will error at you

it won't run it in mono

it will make the entire job run in mono until you fix it

[compact blade]

But I put the attribute once over a struct (for my quad tree) and the CPU got tanked

[slim falcon]

unless you're calling a method from a MonoBehaviour or something, you should never have the attribute on it

[compact blade]

Ohh yeah I know that, comes up now and then

[compact blade]

So you recommend that I should put the attribute away from the functions which are in the Utils class?

[slim falcon]

yes

if you're calling this utility class from ISystem OnUpdate or a job then it doesn't make sense to have the attribute on the utility class

[compact blade]

Alright thanks!

But what if the function is being accessed from ISystem and Mono. Is it still burst compiled for both calls for only the ISystem one?

[slim falcon]

it'd only be compiled for the ISystem

[compact blade]

Ohh I see

[slim falcon]

but the question is, is the function heavy enough to actually benefit from burst

because calling a function pointer is not free

small functions that you burst compile will run slower

than just running them from mono

[compact blade]

I understand, that makes sense

Cool, tomorrow I will look through my whole code and adjust it 😂

Thanks again for clearing things up ✌️

[slim falcon]

if you do this, then passing bool is totally fine