ERR [0] Don't support returning type 'Vec3' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Quat' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Color' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Object' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Body' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Wheel' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Entity' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Light' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Animator' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Mat' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'Cam' by value from application in native calling convention on this platform
ERR [0] Don't support returning type 'SubEntity' by value from application in native calling convention on this platform
....
ERR [0] Invalid configuration. Verify the registered application interface.
[/quote]
What should be done to make it work?
Transform all the classes under (asREF)?
would like to ask but will there still any problems realties of scripts on iOS which ARM processor?
On Mac OSX 64bit AngelScript needs to know the content of the simple classes in order to know how to return them by value. I can only guess to the content of each of these classes, but I believe most of them can use either asOBJ_APP_CLASS_ALLINTS or asOBJ_APP_CLASS_ALLFLOATS. If you have a class that is a mixture of ints and floats, then you can try with asOBJ_APP_CLASS_ALLINTS anyway, but you'll have to test it because it depends on the actual layout of the class members whether it will work or not.
An alternative is to make sure the classes are always treated as complex, i.e. by defining an explicit destructor or copy constructor for the classes.
A third alternative is use the generic calling convention. With the new autowrappers that SiCrane provided this is just as easy as using the native calling conventions. You just use the different macros WRAP_FN, WRAP_MFN instead of asFUNCTION and asMETHOD. You can find the new autowrappers in the SVN.
There are currently no known problems with iOS / ARM processors.