Major Cooke wrote:Yes but did you know the engine wastes time applying the NOBLOCKMAP flag when the actor spawns if you don't apply it already when spawning it?
It just un link actor from blockmap and link it back in without inserting actor into blockmap, cleaning all render/other lists.
But it will save some processor time, if actors lives long enough. Because in actors tick non interactive, actors just move around and thats it. It dont need to check that this line was crossed, is collision was happened, etc.
Plus, you also can cache actor for later use, so that gzdoom will not allocate memory on spawn of a new actors of the same type next time.
In any case, problem with gzdoom actors performance lies in their size. Because CPU, when it process some class/object, loads into its cache whole actor definition. Because thats how computer works. Its impossible to read just half of an object. For actor case that mean scale, mass, size, position, rip level, damage type, basically every line from here
https://github.com/coelckers/gzdoom/blo ... s#L89-L268
It dosent looks like "too much of a data", but that ONLY zscript side definition. Add to it internal (c++ side) variables, serialization, tender specific things, virtual functions, something something... And boom, we have 4 mega"bites" sized single actor. Or how big they are, 1 megabyte?!
What I meant here is, CPU reads too much "garbage" data too often.
Wanna check is two actors are able to collide? Here, have their position and collision box sizes and also water level, sprite id, reaction time and alpha.
One actor damaged another? Oh my, here health of victim and also its current state, amount of tics, min missile chance and target.
And so on.