• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
WitchLord

AngelScript 1.8.0 WIP #4 (2004/07/03)

20 posts in this topic

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:
  • AddScriptSection()
  • Build()
  • GetFunctionCount()
  • GetFunctionIDByName()
  • GetFunctionIDByDecl()
The easiest way to get things working again is to add 0 (or "") as the first parameter to these functions. That makes your application use a module with no name. There is no interaction between modules so far. The only thing they share is the engine configuration. A future version will allow connection between modules so that they can interact. Oh, and if you are enumerating script functions, you'll notice that @init() and @exit() are no longer enumerated. There is still a lot to do on version 1.8.0 so I had better get back to work. ;) Regards, Andreas The link on the page is wrong. The correct file is http://www.angelcode.com/angelscript/files/angelscript_sdk_180WIP4.zip [Edited by - WitchLord on July 7, 2004 7:39:14 AM]
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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)
0

Share this post


Link to post
Share on other sites
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.
0

Share this post


Link to post
Share on other sites
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)?
0

Share this post


Link to post
Share on other sites
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
0

Share this post


Link to post
Share on other sites
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.

0

Share this post


Link to post
Share on other sites
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

0

Share this post


Link to post
Share on other sites
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 .....

0

Share this post


Link to post
Share on other sites
Sorry
You're too fast for me. Your method is actually working very well!
But the return value should be there anyway :)

Cheers
Tom
0

Share this post


Link to post
Share on other sites
Actually, I don't think it is necessary to specify the return value as it is not used to identify overloaded functions. You can't overload a function just by changing the return value.

I'll probably make a similar macro for overloaded global functions as well, just for consistency. :)

0

Share this post


Link to post
Share on other sites
Quote:
Original post by WitchLord
Actually, I don't think it is necessary to specify the return value as it is not used to identify overloaded functions. You can't overload a function just by changing the return value.


You're right overloading is defined in C++ only through the difference in parameters. But still I do get a compiler error when I specify the return value as void.

Using the macro

#define asMETHOD4(c,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((void (c::*)p)(&c::m))

yields

d:\projects\AS\testframe\testtempvar.cpp(64) : error C2440: 'type cast' : cannot convert from 'overloaded-function' to 'void (__thiscall Object1::* )(void)'
None of the functions with this name in scope match the target type


This might be a particularity of the VC7.1 compiler though.
I am using the macro
#define asMETHOD4(c,r,m,p) asSMethodPtr<sizeof(void (c::*)())>::Convert((r(c::*)p)(&c::m))
which works fine with vc7.1.

However, I really look forward to the new version.

Cheers
Tom

[edit]
WitchLord: I just saw that the link on the WIP page is still referencing WIP3 [/edit]
0

Share this post


Link to post
Share on other sites
You're right, the link is wrong. And I can't update it from work. Well, in case you haven't guessed it the correct link is:

http://www.angelcode.com/angelscript/files/angelscript_sdk_180WIP4.zip

Thanks for letting me know.

It's strange, because the error message that you get is reporting the cast to a function with no parameters. Maybe that is the problem. Anyway, I'll include both of the macros, just in case.
0

Share this post


Link to post
Share on other sites
EddHead:

The changes should be mostly in registering in the methods. Maybe you could do a replace on '::' to ',' in those places? Doesn't work when registering overloaded functions, but the rest should work.

Other changes are the new parameter to set the module name, but you could just send NULL, or "", to get things working again.

If you need help you know how to contact me.
0

Share this post


Link to post
Share on other sites
Still with WIP4 I have some truble registering a String class.

I tried bstr.h/bstr.cpp with the testframework and it worked like a charm. Now, when I register my own String class the charm is gone ;(

I have tracked down the error to the factory method i'm using
but what I found there makes no sense for me:

length=199504708 ? it's a rather huge string, isn't it?

my factory looks like this:


String StringBinding::StringFactory(unsigned int length, const char *s)
{

if(length>0 && s!=NULL)
{
char* buf=new char[length];
memcpy(buf,s,length);
String str(buf);
delete [] buf;
return str;
}
return String("");
}


any idea why length is so big?

edit:
forgot to give the error message:
//Unhandled exception at 0x7c342eee (msvcr71.dll) in TechTest.exe: 0xC0000005: Access violation reading location 0x00000200.
0

Share this post


Link to post
Share on other sites
I believe it to be a problem with AngelScript not understanding the way the your function is returning the string object.

If I'm right, angelscript is sending a hidden pointer as the first parameter, making your s to hold the length of the string. Try registering the string factory with asCALL_RETURNBYREF or asCALL_RETURNBYVAL.

This could be a bug in AngelScript. Could you give me the class declaration of the String object? I don't need the implementation. I would be able to make some tests that way.


0

Share this post


Link to post
Share on other sites
It seems to work now, with these registrations:

r=engine->RegisterObjectType("String",sizeof(String), asCALL_RETURNBYREF);
r = engine->RegisterStringFactory("String", asFUNCTION4(StringBinding,String,StringFactory,(unsigned int length, const char *s)), asCALL_CDECL| asCALL_RETURNBYREF);


This is very strange though, because the factory doesn't return a reference to a String.

I must admit that I'm somewhat confuseld with the usage of the asCALL_RETURNBYREF / asCALL_RETURNBYVAL flags :)

You can download the String header file from here
[url]http://thomas.webtracker.ch/jahia/album/thomas/as/ZolaString.h[/url]

Cheers
Tom
0

Share this post


Link to post
Share on other sites
Ok, so I was right, and also wrong. The value you were getting in the length argument, was actually the pointer to the string.

What was happening was that your string factory is taking a hidden pointer as the first parameter. Since AngelScript didn't know about this hidden pointer it didn't send one, making your function dislocate the parameters.

I admit that the asCALL_RETURN_BYREF and asCALL_RETURN_BYVAL flags are a bit confusing. I've already implemented another pair of flags for WIP5 that are easier to understand: asOBJ_IS_COMPLEX and asOBJ_IS_NOT_COMPLEX. Complex objects are those that have a defined constructor/destructor, or an overloaded assignment operator.

I know for sure that MSVC returns these kind of objects by reference even though you declare the method to return by value. What it does is make the caller allocate the memory for the object and passing a pointer to this memory in a hidden first parameter. The callee then calls the constructor using this memory pointer, and then returns the pointer.

I'm pretty sure that this behaviour is not the same for every compiler and platform so I decided to change these flags. With asOBJ_IS_COMPLEX and asOBJ_IS_NOT_COMPLEX it is easier for the programmer to identify the correct flag, and I will be able to put compiler/platform differences inside the library, making the code more portable.

WIP5 will probably be released on friday.
0

Share this post


Link to post
Share on other sites
Wow, thanks for the explanation.
I really learn a lot while using AngelScript and the forum.

Cheers
Tom
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0