Hi
I just wanted to inform users that currently the A* Pathfinding Project will only work with IL2CPP if you follow the Windows Phone instructions here: http://arongranberg.com/astar/docs/iphone.php
Otherwise it will throw an exception on start due to a Unity bug in IL2CPP (a bug report has been submitted).
Since IL2CPP is very young, it might take a while before all code generation bugs in it are fixed.
However I will try my best to work around those bugs.
One user has notified me that it might not work properly on 32 bit when using IL2CPP. It is not completely clear that it is caused by the A* Pathfinding Project, but I just wanted to make people aware of it.
This 32 bit issue is also caused by a Unity bug however, so I can’t do very much to fix it.
Enabling ASTAR_NO_JSON and ASTAR_NO_ZIP worked for me for iOS arm64 builds on 64bit devices, but I’ve had (unconfirmed) reports of it not always working. I do see one error in Xcode while shutting down however:
Could not terminate pathfinding thread[0] in 50ms, trying Thread.Abort
AstarPath:OnDestroy()
NotSupportedException: Tools/il2cpp/il2cpp/libil2cpp/icalls/mscorlib/System.Threading/Thread.cpp(343) :
Unsupported internal call for IL2CPP:Thread::Abort_internal -
"Thread abortion is currently not implemented on IL2CPP;
it is recommended to use safer mechanisms to terminate threads."
at AstarPath.OnDestroy ()
I wrote in another thread about my problem with il2cpp and A Star in Unity5 iOs, I repeat it here
P.S.: sorry for double
Hi,
I have problem with unity 4.6.5p2 where I get a crash if a thread has been assigned a name, this is a bug on the unity side and they will fix it in the next release.
As I was expecting to submit to apple tomorrow I tried a workaround with removing the name assignment and it seem to work.
What I did was commenting out line 1466 in AstarPath.cs
threads[i].Name = "Pathfinding Thread " + i;
and line 836 in RVOCoreSimulator.cs
thread.Name = "RVO Simulator Thread";
Didn’t see the name referenced anywhere so I was hoping there wouldn’t be any problems?
Cheers,
Stefan
Hi
That should be fine. The name is only used for debugging purposes (e.g when stepping through the code in a debugger).
Awesome, thanks! Happy times… I can finally submit my seriously long overdue game! 
hi there,
we encounter massive performance problems with a* on playstation 4 (using il2cpp on building):
while a* takes about 0.1 – 0.3ms on a pc laptop it takes more than 6ms on ps4.
so it looks as if multithreading just does not take place.
do you have any knowledge of this? or do we do something wrong?
any help is very much appriciated.
thanks,
lars
Hi
Hard to say. Can you hook up a profiler?
well, i don not do the ps4 built and all i have is this:
but i will ask for some more in depth information.
Ok. The only PS4 specific code (shared with iOS, WiiU, XBox, PSP2 and PS3) is in the LockFreeStack.cs file. I don’t think that should be the problem though.
i am not sure what the LockFreeStack script does – but we get unexpected high processing time from another asset (amplify motion) which also heavily uses multi threading.
and only these multi threaded scripts causes totally unexpected pefomance on playstation’s 8 core cpu (all other scripts run simply slower by more or less the same factor).
so maybe there are some issues with il2cpp and multithreading?
as i may not write another reply it comes here:
it is set to “automatic low load”.
Even if there were issues with threading, it wouldn’t show up like that in the profiler.
Possibly something is going wrong in the auto detection of the number of threads. What is your A* Inspector -> Settings -> Threads value set to?
Ok. It might be some issue with how PS4 reports the number of processors or the amount of RAM.
Could you check what AstarPath.CalculateThreadCount(ThreadCount.AutomaticLowLoad) returns? And also possibly SystemInfo.systemMemorySize and SystemInfo.processorCount?
i will let our ps4 man know about it.
Hi there,
Thanks for the help Aron, here’s the output you asked for on the ps4:
This was run in a empty scene (but of the actual project) to speed up build time, let me know if you think it can differ if ran in the main game.
Does this tell you anything ?
Regards,
Guillaume
Hi
That tells me it should be using 3 threads.
Are you using any graph updates in your game? Maybe it is those that are slow?
The candidates would be either graph updates or something in the OnPathComplete callbacks in the movement scripts.
Yeah we do, I believe you’ve been in touch with Mike from our team recently to change the graph to navmesh ?
