Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mysterycoder]

Personally, I don't think abstracting out scripting will make it any less powerful. The way WGE works, it doesn't depend at all on scripting. Whether using C++, python, or squirrel, it all depends on user preference. Abstracting out scripting will simply give users more options.

[pjcast]

Yeah, I agree. And, it's not really abstracting out so much as it is just a couple methods that would need to be virtual: loadScript, runScript, etc.

The script bindings in the dll would chose what parts and how much of WGE to wrap - hopefully all will be wrapped for each langauge that we bind

I think that the real question wil be, who wants to do the work  :| I know I'm pretty busy trying to get a rock solid editor framework going But, if you don't have the time either mysterycoder, I suppose I could squeze it in.I still havn't managed to squeze in any time today to try out the latest changes, and look for that error. But, I am rather annoyed from squirrel since the Linux port I attempted (even though I love the syntax). But, that doesn't mean I want to use Lua (which would have rather the same limitations), and I'm not too sure about python.. But, if you really like python, and are profecient in it. Perhaps we could focus on creating some python binding dll.

One thing, we would have to remove all the SQChar * and just use const char* for methods, to allow binding easier then binding strings possibly. Also, the Input manager would need a bit of refactoring in the event calling code, probably use some like fast delegates instead of being script calling. That way, the users of WGE could implement their input in c++ methods, or have the scripting dll's register some methods so they could call into scripts however they need to.

[mysterycoder]

Actually I saw an option in SqPlus which allows you to use std::strings.  :wink:
Sure, I'll do it, I'm sure I have more time than you.  
I actually setup boost::python with c::b awhile ago in WGE.

[OvermindDL1]

If you want to try Python then I could help quite a bit.  Boost::Python prefers you to use std::strings so that you can reference strings that are inside python directly while still handling reference counting properly, whereas you cannot ensure reference counting with const char's, so they could disappear at any moment.

Also, fast delegates are nothing but function pointers, they don't support functors, binding etc...  If you wanted to bind callbacks into or from a script, then you will need to use a proper function pointer, like boost::Function.  Boost::Function compiles to identical ASM code as fast delegate if all it holds is just a function pointer (although, by default, but can be changed, it adds in a check to make sure it is valid before calling, which you should do anyway).  There really is no reason at all to use fastdelegate, especailly since Boost::Function compiles to the same assembly for basic function pointers, and it supports vastly more powerful construct, including constructs that make binding callbacks with scripting languages an absolute breeze.

This of it this way, for a script callback to C++ without using script bindings directly, you have to wrap the callback up in a function and pass that to the callback.  Problem is, you cannot dynamically create functions in normal C++.  Well with Boost::Function you can.

Because of the heavy templating in Boost::Function, if used as a normal function pointer, it is as lightweight as possible, or it can become heavyweight with complicated bindings to auto fill in parameters and all.  And since Boost::Function is already accepted into the next C++ standard library, you may as well get used to it.

You probably could even make direct callbacks like that using LuaBind as well since LuaBind is a modified version of Boost::Python, but for Lua.  The current direction of Boost::Python is tryng to become more scripting language independent, so it was not hard to do.

[mysterycoder]

I have the dll loading stuff done(stolen mostly from AvManager   ).
I've created the python scripting project, and I have that setup, and now I'm halfway through binding the engine. I would have finished it tonight, but its 2AM.  :?
So expect it totally done in about 2-3 days, I'll commit it then so I don't totally break the repository.

[pjcast]

Wow, totally awesome work  

[OvermindDL1]

Very nice.  If you need help with any binding or pythonizing or what-not, just ask.

[mysterycoder]

Heh, thanks.  

@OvermindDl1: I do have one question about binding, I am binding the getSingletonPtr functions from the Managers, and I don't  want python to take full control of the object. I'm using

Code: [Select]

.def("getSingletonPtr", &OgreManager::getSingletonPtr,
            return_value_policy<reference_existing_object>())
to tell it not to, is that correct? The boost documentation says its a naive approach.

[OvermindDL1]

It says it is a naive/dangerous approach because Python will not be controlling when it is deleted.  Considering it is a singleton and it should be around the entire script life, there should be no trouble at all.  They only say that because if something like this occurs:

Code: [Select]

theManager = someManager.getSingletonPtr()
# theManager is stored for later use
#  but for some reason, the C++ side deletes it, and the script tries to do this:
theManager.doSomething() # invalid memory error, unhandlable, interpretor crashes, crashing the process...
Essentially it is just to warn you that Python likes to control references, that is why it *loves* smart pointers since smart pointers from python include the reference counting semantics from python.

But yea, that is correct.  I would recommend not exposing getSingletonPtr, and only expose getSingleton though.

And make sure that in the class definition for OgreManager, you have boost::noncopyable specified.  boost::noncopyable should be specified on any singleton class...

EDIT:  I already have things like Vector3 and the Quaternion wrapped if you want their definitions.

[mysterycoder]

Sorry I'm taking so long, stuff came up.  
I've got a simple example working for now.
This is the entire python script:

Code: [Select]


while WGE.manager.update():
    a = 1


@OvermindDL1: I'm not sure what to do with boost::noncopyable, how do I apply it?

[pjcast]

Hmm, I don't really want to put boost inside WGE itself.. But, maybe, just maybe, if it is absolutely neccessary.. It might be useful to allow boost, for more flexible function binding, but I really don't want to see boost all over the place.

In anycase, no problem that it is taking some time.. Anything worth doing is worth taking time for Plus, i have been busy with some other things myself this weekend.

[mysterycoder]

I've gotten most things working well right now. But, things got interesting when I was trying to wrap OIS. It called squirrel functions explicitally in the functions. I was trying to create a callFunction method for PythonScriptingEngine, but I'm having trouble with templates(I'm a complete noob at them).

Right now this is how the function is setup:
(In the header)

Code: [Select]


template<typename R, typename A1, typename A2>
        void callFunction(R returnType, A1 arg1, A2 arg2);


(In the CPP)

Code: [Select]


//-----------------------------------------------------------------------//
template<typename R, typename A1, typename A2>
void PythonScriptingEngine::callFunction(R returnType, A1 arg1, A2 arg2)
{
    PyObject* func;
    call<returnType>(func, arg1, arg2);
}

Is that right?

I need to be able to have an infinate amount of template arguments, I saw boost, and sqplus do this for the number of arguments, and I don't know how to. I looked around for a bit and I haven't found anything. Any links, examples, etc?

Or perhaps this is the wrong approach to take? any suggestinos for alternate methods?

Thanks  

[OvermindDL1]

Boost includes some extremely powerful macro'ing things, one of which is a generater to create a function of multiple times such as how you are wanting (it uses it for the boost::python function calling, boost::function calling, boost::bind, etc...).  Borrow it, you can see how to use it by looking at the proper headers, such as the boost::function headers, the macro's themselves are generic and can be used anywhere just by calling them without needing to copy them into your own app.

As for the function you show, I'm not sure what it is supposed to do.  First of all, all your python function handles that you have you should be using as boost::python::object's, which then allows you to call them directly, as you are wanting, which negats the need for the function you wrote.  Not to mention that your function, in its current state, would attempt to call a function in an invalid/not_initialized python handle

Explain better what you are trying to pull off, or is the preceeding paragraph what you are trying to do?

Also, boost::noncopyable you add to python class definitions for classes that must *always* be passed as references (singletons for example) and not copied.  You add it to a class definition as such:

Code: [Select]

boost::python::class_<myClass, boost::noncopyable>("myClass", no_init);
You of course would not put the no_init if the class or a subclass can be instanced in python, but for singleton classes that should *always* be created in C++, no_init is good to put too to make sure the user doesn't do something stupid like instance another copy of a singleton.

[mysterycoder]

What I'm trying to do is basically create a wrapper around the boost::python::call function. We need a generic way to call functions from the scripting languages in the scripting interface.  
My idea was to  create the function be like this:

Code: [Select]

template<typename R, #BOOST_INFINITE_AMOUNT_OF_TEMPLATE_ARGUMENTS_THING>
callFunction(Ogre::String functionName, R returnType, #BOOST_INFINITE_AMOUNT_OF_ARGUMENTS_IN_THE_FUNCTION)
{
       call<returnType>(scope().attr(functionName), #BOOST_INFINITE_AMOUNT_OF_ARGUMENTS_IN_THE_FUNCTION));
}

[mysterycoder]

I give up  
I got templates working, but I can't make template functions virtual. That's a problem for the PythonScriptingEngine which inherits from ScriptingEngine. I also tried making callFunction a standalone method in the PythonScriptingEngine Dll, and then calling it directly from the dll using Ogre's getSymbol interface. This didn't work either. So, I'm out of ideas, anyone got some?