To be honest, I didn't check the lastest angelscript version, but it looks that nothing has changed related to this issue.
We have some problems with compilation on arm64, mips/mips64/mipsel, ppc64el, s390x architectures. This bug prevents us from migrating to Debian Testing repositories.
Here is a bit more info:
https://github.com/supertuxkart/stk-code/issues/2569
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830748
Could you have a look?
Regards,
Deve
Hi Deve,
thanks for bringing this to me. It looks like the cause of the problem has already been identified. I'll be sure to have the fix included in my branch.
Unfortunately I do not have access to all these different environments so I cannot test the code on all of them. I hope you'll be able to help confirm for me that the code works OK once I have it checked in to the SVN.
I've checked in the changes in revision 2353 for the next 2.31.2 release.
This problem has actually been in as_config.h since the very beginning, and was not broken in any recent release. Most likely someone had fixed it locally in STK but never told me about it.
Regards,
Andreas
The issue is a bit old, but I'm currently working on the STK Android port and I finally have a possibility to test it.
The arm64 compilation indeed works fine, but I get some errors on a console and the angelscript is practically not working on this platform.
I get something like:
W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getCompletedChallengesCount()' (Code: -7)
W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getChallengeCount()' (Code: -7)
W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'bool isChallengeUnlocked(string &in)' (Code: -7)
W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'int getChallengeRequiredPoints(string &in)' (Code: -7)
W/SuperTuxKart(27724): (0, 0) : ERR : Failed in call to function 'RegisterGlobalFunction' with 'void squash(int id, float time)' (Code: -7)
and then
W/SuperTuxKart(27724): (0, 0) : ERR : Invalid configuration. Verify the registered application interface.
E/SuperTuxKart(27724): Build() failed
And then it says that scripting function is not found and it can't execute it.
Note that it works fine on armv7 build (on both armv7 and aarch64 devices). Only aarch64 build doesn't really work.
Do you have some ideas what may be wrong?
I can provide more info, test some patches etc. if you need.
The error code -7 means asNOT_SUPPORTED.
Native calling conventions are not supported on arm64 platforms yet. I'm guessing these functions that fail to register are not using the asCALL_GENERIC calling convention.
You can use the auto wrapper functions from the addon to create the asCALL_GENERIC version of the functions without much effort.
Thanks!
I just thought that the arm64 is fully supported and there is a bug somewhere.
It's not critical for us, because the armv7 build works on both armv7 and aarch64 platforms. I also didn't notice any performance improvements. I will make some tests with the auto wrapper functions, but I will finish other things first.
Regards,
Deve
If you feel up to it, perhaps you can help add the support for native calling conventions on arm64. It would involve a bit of assembler coding, but nothing too complicated. Most of the assembler code can be put together from disassembly of C++ functions, so it's not that you need to be an expert in assembler.
64bit processing usually doesn't bring any performance improvements compared to 32bit. 64bit processing just raises some limits imposed by 32bits, e.g. max 4GB file size and max 4GB memory. Though it is important to note that even 32bit application can work around these limitations through various tricks (e.g. pagination, large file support, etc). Most applications and games doesn't come anywhere near the limitations imposed by 32bit processing.
64bit processing usually doesn't bring any performance improvements compared to 32bit. 64bit processing just raises some limits imposed by 32bits, e.g. max 4GB file size and max 4GB memory. Though it is important to note that even 32bit application can work around these limitations through various tricks (e.g. pagination, large file support, etc). Most applications and games doesn't come anywhere near the limitations imposed by 32bit processing.
That's why I said that it's not that important. I suppose that there are some performance improvements due to newer arm generation, but I don't see any real difference in frames per second.
I probably won't implement it until other things will be finished. We'll see later.
