• 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
Deyja

Binding std::string operators in AngelScript

8 posts in this topic

I'm trying to bind some binary operators in AngelScript. The operators are == and +, on std::string. I'm not quite sure if I've set them up right. These binary operators shouldn't have this pointers, so I tried them that way first. I tried them with this pointers, and they still don't work. Simply registering these behaviors - wether I use them or not - makes building fail. Here is my binding code:
std::string CreateString(asUINT length, const char * str)
{
	return std::string(str);
}

void ConstructString(std::string* str)
{
	new (str) std::string();
}

void DestructString(std::string* str)
{
	str->~basic_string();
}

std::string& AssignString(const std::string& src, std::string* dest)
{
	*dest = src;
	return *dest;
}

std::string AddString(const std::string& rhs, std::string* thisp)
{
	return (*thisp)+rhs;
}

std::string& AddAssignString(const std::string& rhs, std::string* thisp)
{
	*thisp += rhs;
	return *thisp;
}

bool CompareStlString(const std::string& rhs, std::string* thisp)
{
	return rhs == (*thisp);
}

void BindStlString(asIScriptEngine* engine)
{
	engine->RegisterObjectType ("string", sizeof (std::string), asOBJ_CLASS_CDA);
    engine->RegisterStringFactory ("string", asFUNCTION(CreateString), asCALL_CDECL);
    engine->RegisterObjectBehaviour ("string", asBEHAVE_CONSTRUCT, "void f()", asFUNCTION(ConstructString), asCALL_CDECL_OBJLAST);
    engine->RegisterObjectBehaviour ("string", asBEHAVE_DESTRUCT, "void f()", asFUNCTION(DestructString), asCALL_CDECL_OBJLAST);
    engine->RegisterObjectBehaviour ("string", asBEHAVE_ASSIGNMENT, "string &f(const string&)", asFUNCTION(AssignString), asCALL_CDECL_OBJLAST);
	engine->RegisterObjectBehaviour ("string", asBEHAVE_ADD, "string f(const string&)", asFUNCTION(AddString), asCALL_CDECL_OBJLAST);
	engine->RegisterObjectBehaviour ("string", asBEHAVE_ADD_ASSIGN, "string& f(const string&)", asFUNCTION(AddAssignString), asCALL_CDECL_OBJLAST);
	engine->RegisterObjectBehaviour ("string", asBEHAVE_EQUAL, "bool f(const string&)", asFUNCTION(CompareStlString), asCALL_CDECL_OBJLAST);
}

And my test script
//String test

void Test()
{
	string one = "Hello ";
	string two = "world";
	string three = "!";
	one += two;
	if (three == "!") Print(one+three);
}

Also; I've never seen 'behavior' spelled with a u before. Is it a British spelling?
0

Share this post


Link to post
Share on other sites
The add and compare behaviours are binary operators, and shouldn't be registered as methods. A future version of AngelScript might allow them to be registered as methods, but not yet.


std::string AddString(const std::string &lft, const std::string &rgt)
{
return lft+rgt;
}

std::string CompareString(const std::string &lft, const std::string &rgt)
{
return lft==rgt;
}

r = engine->RegisterObjectBehaviour(0, asBEHAVE_ADD, "string f(const string&, const string&)", asFUNCTION(AddString), asCALL_CDECL); assert( r >= 0 );
r = engine->RegisterObjectBehaviour(0, asBEHAVE_COMPARE, "string f(const string&, const string&)", asFUNCTION(CompareString), asCALL_CDECL); assert( r >= 0 );



The rest is correct, at least as far as I can see without actually testing the code.

If you check the return code for each of the Register functions (e.g. like I show above) you would know which one caused the problem.

Yes, behaviour is british spelling. [wink]
0

Share this post


Link to post
Share on other sites
I was able to confirm that it was the binary functions causing the problem simply because commenting them out made the script build - of course, then it gave me errors, when before it had failed silently.

I can see now how RegisterObjectBehavior can get all the information it needs from the function signature - and how it even allows mixing types, but it seems a little odd at first to register an object behavior without specifying a type.

I keep spelling Behavior 'right', and I don't notice it until the compiler yells at me.
0

Share this post


Link to post
Share on other sites
Thank you, it works wonderfully now. The script prints Hello World!, just as it should! Now I can begin implementing more advanced string-handling functions.

I do have one concern. Does AngelScript follow the same overload-matching rules as C++? Does it support different return types for overloads? I'm going to be binding several functions for converting basic types to and from string, and would like to give them a common name and let the return type and the conversion function to be called be determined by the function overload system. It's not templates, but it sure kicks a bunch of ****ToString(...) functions in the pants!

I was very happy when I stumbled across AngelScript. I couldn't believe I'd missed it before! I'd been mucking about trying to get LUA to do what I wanted for a long time, and AngelScript does it all already. I'm currently working on a Mud engine that uses script for all it's content, and that means a great deal of string parsing. Hopefully, I'll be able to move all command-processing into script, and just use the command entered to generate the name of a function to call, much like I did in LUA.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by WitchLord
The add and compare behaviours are binary operators, and shouldn't be registered as methods. A future version of AngelScript might allow them to be registered as methods, but not yet.


By the way, data type ("vector") is specified in the example from your site

Quote:

engine->RegisterObjectBehaviour("vector", asBEHAVE_ADD, "vector f(vector &, vector &)", asFUNCTIONP(operator+, (CVector &, CVector &)), asCALL_CDECL);


But if you try to actually register a function like this, DetectCallingConvention() won't allow asCALL_CDECL here (which seems to be logical). Either I'm doing something wrong or the example is misguiding ;)

And IMHO it is not convenient that C++ and AngelScript function signatures differ for asCALL_CDECL_OBJLAST methods.

Cheers,
RCL
0

Share this post


Link to post
Share on other sites
Deyja:

I agree that allowing registration of both object behaviours and operator overloads with the same method can be a bit confusing. I'll probably separate the two functionalities to fix this.

I try to follow the same overloading rules as C++, which means that functions that have different parameters can use the same name, but if only the return type differs they can use the same name. If you find that AngelScript doesn't do this correctly, let me know so that I can fix it.

I'm very pleased to know that you like AngelScript. Let me know if there is anything I can do to improve it even more.

RCL:

The example must be wrong. I haven't actually tried it, I just uploaded what Lennart sent me (and he was using an older version). I'll correct it as soon as possible.

asCALL_CDECL_OBJLAST is a substitute for asCALL_THISCALL, it was included for those cases where an object method didn't exist or couldn't be written. The AngelScript function signature don't include the object pointer because it is sent hiddenly. I'm including asCALL_CDECL_OBJFIRST as well with the next version, to give one more option for developers.

0

Share this post


Link to post
Share on other sites
A preprocessor would be nice, but don't worry about it - I'm already writing one. I have includes working, and all the framework I need to implement defines. It's rather inefficient though. In order the handle defines, I have to break the script down into it's constituent tokens. Then I have to put it back together, and hand it off to AngelScript - which just does it all over again. My lexer was also written for a different purpose, but has been curelly bent to the task of lexing C code.

I think the only thing keeping AngelScript from implementing a pre-processor itself is that it does not load files itself, so it has no way of handling #include. I'll post it on here once I have #define working, though it's going to drag a bit of baggage with it.
0

Share this post


Link to post
Share on other sites
I don't have any plans of adding a preprocessor to the main library of AngelScript at this point. But an external preprocessor would be an excellent add-on. Maybe in the future once AngelScript is more mature I'll consider an internal preprocessor.

I look forward to adding your preprocessor to the AngelScript add-ons on the site.
0

Share this post


Link to post
Share on other sites
Well. Good luck with it. :D Included in this zip is the preprocessor and all the support code for running the test-script. Theres a compiled angelscript.lib included, just in case my code is not compatible with any changes you've made since your last release.

http://www.omnisu.com/preprocessor.zip

The preprocessor supports #include, and protects against multiple-inclusion.
It supports #define, but not function-defines. That is, #define PRINTHW Print("Hello World!"); is fine, but #define PRINTSOMESTUFF(a,b) Print(a); Print(b); is not supported yet.
Those kind of macros will probably come after #ifdef, #ifndef, and #endif.
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