if( !strstr(asGetLibraryOptions(), "AS_MAX_PORTABILITY") )
{
r = engine->RegisterGlobalFunction("void Print(string &in)", asFUNCTION(PrintString), asCALL_CDECL); assert( r >= 0 );
r = engine->RegisterGlobalFunction("uint GetSystemTime()", asFUNCTION(timeGetTime), asCALL_STDCALL); assert( r >= 0 );
}
else
{
// Notice how the registration is almost identical to the above.
r = engine->RegisterGlobalFunction("void Print(string &in)", asFUNCTION(PrintString_Generic), asCALL_GENERIC); assert( r >= 0 );
r = engine->RegisterGlobalFunction("uint GetSystemTime()", asFUNCTION(timeGetTime_Generic), asCALL_GENERIC); assert( r >= 0 );
}
Registering Global Functions with AS
Author
Okay, came up with a question or two after reading through the "tutorial" sample...
What does it mean when "AS_MAX_PORTABILITY" is set in terms of registering functions? I would guess that one option is less portable than the other, and you test to see which one you can do. Is there one option which is always portable, with which I could cut corners and always use no matter what? I'd rather not have to write two global functions (PrintString, PrintString_Generic) for every function I have.
The AS_MAX_PORTABILITY is used on the platforms where native calling conventions are not supported. If you need 100% portability, you should use AS_MAX_PORTABILITY as it will work on all platforms regardless if native calling conventions is supported or not on that platform.
Which target platforms do you intend to support? You can see on which platforms native calling conventions are supported here: features.
If you're going to write a function specifically for AngelScript, i.e. it won't be called directly by your application, then you might as well choose the generic interface. But if you're planning on using functions that your application already uses, then try to use those as much as possible. In most cases there won't be any need to write wrapper functions as AngelScript is able to call almost any function using it's native calling convention (where that is supported, of course).
asGetLibraryOptions() is a function that returns the options with which the AngelScript library was compiled with. If the returned string contains AS_MAX_PORTABILITY it means that the library was built without the assembler code needed for the native calling conventions support.
In the tutorial I support both ways, because I need the tutorial to work on all platforms where AngelScript is supported. And I didn't want to write two different tutorials, though I suspect that might actually have been less confusing.
Regards,
Andreas
Which target platforms do you intend to support? You can see on which platforms native calling conventions are supported here: features.
If you're going to write a function specifically for AngelScript, i.e. it won't be called directly by your application, then you might as well choose the generic interface. But if you're planning on using functions that your application already uses, then try to use those as much as possible. In most cases there won't be any need to write wrapper functions as AngelScript is able to call almost any function using it's native calling convention (where that is supported, of course).
asGetLibraryOptions() is a function that returns the options with which the AngelScript library was compiled with. If the returned string contains AS_MAX_PORTABILITY it means that the library was built without the assembler code needed for the native calling conventions support.
In the tutorial I support both ways, because I need the tutorial to work on all platforms where AngelScript is supported. And I didn't want to write two different tutorials, though I suspect that might actually have been less confusing.
Regards,
Andreas
In that list of the platforms that support the native calling convention, you have xbox listed. Does that mean both the old xbox and the xbox 360 or just the old xbox?
I'd imagine that because the PS2 and PS3 are listed as different items, and that because XBOX uses Pentium 3 processors while the XBOX 360 uses PowerPC-based processors, the XBOX 360 probably isn't currently supported.
However, with all the work that WitchLord's been doing lately, I wouldn't be surprised if 360 support is in the works.
However, with all the work that WitchLord's been doing lately, I wouldn't be surprised if 360 support is in the works.
Only the old X-Box has been confirmed to work.
X-Box 360 may work, if it uses the same calling conventions as PS3, which is also PPC based. However, it is highly probably that some minor adjustments must be made to as_callfunc_ppc_64.cpp for it to work. If someone would like to help me confirm that I would appreciate it.
Regards,
Andreas
X-Box 360 may work, if it uses the same calling conventions as PS3, which is also PPC based. However, it is highly probably that some minor adjustments must be made to as_callfunc_ppc_64.cpp for it to work. If someone would like to help me confirm that I would appreciate it.
Regards,
Andreas
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
