- AddScriptSection()
- Build()
- GetFunctionCount()
- GetFunctionIDByName()
- GetFunctionIDByDecl()
AngelScript 1.8.0 WIP #4 (2004/07/03)
I've just posted the latest work in progress.
WIP page
The new addition is the support for modules. Which requires a few changes to the following methods:
I've uploaded the latest WIP version, which adds support for STDCALL functions and fixes a bug.
The implementation for the STDCALL support was contributed by Adam Hoult from Game Institute, a.k.a. daedalusd. The bug was also discovered by him. Thanks very much, Adam.
Regards,
Andreas Jonsson
Author of AngelScript
The implementation for the STDCALL support was contributed by Adam Hoult from Game Institute, a.k.a. daedalusd. The bug was also discovered by him. Thanks very much, Adam.
Regards,
Andreas Jonsson
Author of AngelScript
I was thinking of a way to enable VS style autocomplete in a console window, i wanted to know how i could use GetFunctionCount() and read the function declaration and appropriately display them in the window. Any ideas or implementaions required? ex: (GetFunctionNameByID() sorts)
GetFunctionCount() returns the number of functions in the script.
The valid function IDs are between 0 and GetFunctionCount()-1. The first 2 functions may be @init() and @exit(), which shouldn't be called by the application.
GetFunctionName() returns the name of the function by ID.
GetFunctionDeclaration() returns the declaration of the function by ID.
The above is true for version 1.7.1.
For version 1.8.0 this is currently slightly broken since a function ID now holds the module ID in the upper 16 bits. I'll figure out a way before final release to make it just as easy to enumerate the functions.
The valid function IDs are between 0 and GetFunctionCount()-1. The first 2 functions may be @init() and @exit(), which shouldn't be called by the application.
GetFunctionName() returns the name of the function by ID.
GetFunctionDeclaration() returns the declaration of the function by ID.
The above is true for version 1.7.1.
For version 1.8.0 this is currently slightly broken since a function ID now holds the module ID in the upper 16 bits. I'll figure out a way before final release to make it just as easy to enumerate the functions.
What does the code generation settings for Release need to be? I am using a game lib that the creator suggested I use Single Threaded. I get a lot of errors when compiling for relese, but everything is fine for debug. I heard that this kind of thing can happen when you use libs of different code generations. My debug code generation is set on debug multithreaded dll. So, I tried Multithreaded DLL for release and I get 100 link errors.
Here are a few:
angelscript.lib(as_variablescope.obj) : error LNK2001: unresolved external symbol __ftol
ac_string.obj : error LNK2001: unresolved external symbol __imp__strstr
angelscript.lib(as_compiler.obj) : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
hgehelp.lib(hgeparticle.obj) : error LNK2001: unresolved external symbol __fltused
Here is what I link against:
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib hge.lib hgehelp.lib angelscript.lib
Is there some kind of system lib I'm not linking (I have the latest WIP of angelscript btw)?
Here are a few:
angelscript.lib(as_variablescope.obj) : error LNK2001: unresolved external symbol __ftol
ac_string.obj : error LNK2001: unresolved external symbol __imp__strstr
angelscript.lib(as_compiler.obj) : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
hgehelp.lib(hgeparticle.obj) : error LNK2001: unresolved external symbol __fltused
Here is what I link against:
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib hge.lib hgehelp.lib angelscript.lib
Is there some kind of system lib I'm not linking (I have the latest WIP of angelscript btw)?
I have some difficulties in registering overloaded methods with WIP#4 (the only WIP I tried yet :)
with v 1.7.1a I registered overloaded methods like this:
asMETHOD( (void (Vector3::*)(float , float , float) )Vector3::set) asMETHOD( (void (Vector3::*)(const Vector3&) )Vector3::set )
but with the new macro definition of WIP#4 I have some truble to get the right method.
asMETHOD(Vecotr3,set) // doesn't work in MSVC .NET 2003 (vc7.1)
Any hints what I could try?
Thanks
Tom
with v 1.7.1a I registered overloaded methods like this:
asMETHOD( (void (Vector3::*)(float , float , float) )Vector3::set) asMETHOD( (void (Vector3::*)(const Vector3&) )Vector3::set )
but with the new macro definition of WIP#4 I have some truble to get the right method.
asMETHOD(Vecotr3,set) // doesn't work in MSVC .NET 2003 (vc7.1)
Any hints what I could try?
Thanks
Tom
Oops! I'll have to back to the drawing board. It didn't occur to me that the overloaded functions wouldn't be able to use the new macro.
It should just be a matter of writing another macro that takes as a parameter the method parameters so that the pointer cast can be formed. I'm no wiz with macros so it might take me some time to get a nice looking macro. If someone can come up with a macro before me, don't hesitate to give me your suggestions.
If possible I would like the macro to look something like this:
asMETHOD(c,m,p) where c is the class name, m is the method name, and p is the parameter list. It would then be used as follows:
asMETHOD(CMyClass, MyMethod, (int, float, double))
In the meantime you could skip the macro and use the following to get to your method
asSMethodPtr<sizeof(void (c::*)())>::Convert((void (c::*)(p))(&c::m))
Exchange c for the class name, m for the method names, and p for the parameter list for the method.
It should just be a matter of writing another macro that takes as a parameter the method parameters so that the pointer cast can be formed. I'm no wiz with macros so it might take me some time to get a nice looking macro. If someone can come up with a macro before me, don't hesitate to give me your suggestions.
If possible I would like the macro to look something like this:
asMETHOD(c,m,p) where c is the class name, m is the method name, and p is the parameter list. It would then be used as follows:
asMETHOD(CMyClass, MyMethod, (int, float, double))
In the meantime you could skip the macro and use the following to get to your method
asSMethodPtr<sizeof(void (c::*)())>::Convert((void (c::*)(p))(&c::m))
Exchange c for the class name, m for the method names, and p for the parameter list for the method.
It was easier than I thought.
Put the following macro in the angelscript.h file
#define asMETHODP(c,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((void (c::*)p)(&c::m))
Now you can take the pointer of overloaded methods by writing the following:
asMETHODP(MyClass, MyMethod, (int, float))
Note you should keep asMETHOD(c,m) as it will still be used when there is no need to define the parameter list.
Regards,
Andreas
Put the following macro in the angelscript.h file
#define asMETHODP(c,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((void (c::*)p)(&c::m))
Now you can take the pointer of overloaded methods by writing the following:
asMETHODP(MyClass, MyMethod, (int, float))
Note you should keep asMETHOD(c,m) as it will still be used when there is no need to define the parameter list.
Regards,
Andreas
Almost there ;)
You will probably have to include the return value with the macro
maybe for global functions too??
#define asMETHOD4(c,r,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((r (c::*)(p))(&c::m))
the above doesn't work ofcourse, that is it works for one parameter functions .....
You will probably have to include the return value with the macro
maybe for global functions too??
#define asMETHOD4(c,r,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((r (c::*)(p))(&c::m))
the above doesn't work ofcourse, that is it works for one parameter functions .....
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
