gamedevlists-general

[GD-General] scripting via COM?

[Andras B. <and...@gm...>]

My biggest annoyance with scripting has always been somehow exporting
my C++ classes and functions to the scripting languages. I know that there
are tools to help with this, but I never really liked any of them.
They are always a pain to setup and use, and the binding is too rigid.

Now, I believe that most decent scripting languages have some kind of
support to easily call into COM objects. So I was thinking: Wouldn't
it be the best to just wrap my engine into a COM object, and then the
scripting language just makes calls into it through COM? This would
also make the binding between the scripting and the engine much more
dynamic. So it would be possible to use the same engine from virtually
any scripting language that can access COM objects.

I'm not terribly experienced in scripting, so it's possible that I'm
missing out on a lot of important issues..
What are your thoughts on this?




Andras

[GD-General] Re: scripting via COM?

[Andras B. <and...@gm...>]

I forgot to mention, that I'm mainly interested in extending scripting
languages, not embedding them. So the entrypoint is in the script, and
it just uses the services of the engine to do low level stuff.


Andras

Wednesday, January 25, 2006, 9:09:45 PM, you wrote:

> My biggest annoyance with scripting has always been somehow exporting
> my C++ classes and functions to the scripting languages. I know that there
> are tools to help with this, but I never really liked any of them.
> They are always a pain to setup and use, and the binding is too rigid.

> Now, I believe that most decent scripting languages have some kind of
> support to easily call into COM objects. So I was thinking: Wouldn't
> it be the best to just wrap my engine into a COM object, and then the
> scripting language just makes calls into it through COM? This would
> also make the binding between the scripting and the engine much more
> dynamic. So it would be possible to use the same engine from virtually
> any scripting language that can access COM objects.

> I'm not terribly experienced in scripting, so it's possible that I'm
> missing out on a lot of important issues..
> What are your thoughts on this?




> Andras

Re: [GD-General] scripting via COM?

[Jon W. <hp...@mi...>]

If you want to be Microsoft specific (which COM is), then you probably 
would do better supporting the CLR (.NET). It is much richer, and 
there's a wide variety of languages that run within the CLR. The 
development and debugging tools are also top-notch.

Cheers,

			/ h+

Andras Balogh wrote:

> Now, I believe that most decent scripting languages have some kind of
> support to easily call into COM objects. So I was thinking: Wouldn't
> it be the best to just wrap my engine into a COM object, and then the

-- 
-- The early bird gets the worm, but the second mouse gets the cheese.

Re: [GD-General] scripting via COM?

[Andras B. <and...@gm...>]

I've heard that you can use COM objects from .NET using some wrapper.
My only problem with pure .NET is that not all customers are ready to 
use it. I would like to have a package that you can use from unmanaged 
C/C++ as well as from VB, Python, Lua, C#...
Also, I definitely want to keep my engine in the unmanaged world.

Thanks,

Andras

Jon Watte wrote:
> 
> If you want to be Microsoft specific (which COM is), then you probably 
> would do better supporting the CLR (.NET). It is much richer, and 
> there's a wide variety of languages that run within the CLR. The 
> development and debugging tools are also top-notch.
> 
> Cheers,
> 
>             / h+
> 
> Andras Balogh wrote:
> 
>> Now, I believe that most decent scripting languages have some kind of
>> support to easily call into COM objects. So I was thinking: Wouldn't
>> it be the best to just wrap my engine into a COM object, and then the
> 
> 

Re: [GD-General] scripting via COM?

[brian s. <bri...@gm...>]

I don't think anyone has pointed this out yet, but COM objects are  
not inherently scriptable in and of themselves.  Anything scriptable  
by .NET, VB and other such languages has to implement IDispatch.  So  
adding scriptability to your engine won't be as simple as just  
deriving everything from IUnknown.  For starters, I'm guessing that  
all your methods that you wish to expose aren't already returning  
HRESULTs.

Trying to implement game engine scriptability through COM Automation  
has to be just about the most painful way you could go.

--brian

On 26 Jan 2006, at 18:07, Andras Balogh wrote:

> I've heard that you can use COM objects from .NET using some wrapper.
> My only problem with pure .NET is that not all customers are ready  
> to use it. I would like to have a package that you can use from  
> unmanaged C/C++ as well as from VB, Python, Lua, C#...
> Also, I definitely want to keep my engine in the unmanaged world.
>
> Thanks,
>
> Andras
>
> Jon Watte wrote:
>> If you want to be Microsoft specific (which COM is), then you  
>> probably would do better supporting the CLR (.NET). It is much  
>> richer, and there's a wide variety of languages that run within  
>> the CLR. The development and debugging tools are also top-notch.
>> Cheers,
>>             / h+
>> Andras Balogh wrote:
>>> Now, I believe that most decent scripting languages have some  
>>> kind of
>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>> it be the best to just wrap my engine into a COM object, and then  
>>> the

Re: [GD-General] scripting via COM?

[Andras B. <and...@gm...>]

Well, yeah, this is not really a game engine, although it's similar. The 
big difference is that with a game engine, one could make a decision 
that it will be scripted with Lua, and be done with it. In this case 
however, customers will probably want to use our rendering services from 
all kinds of different languages, so it would be preferable not to have 
such binding limitations.

Do you have any other ideas, how I could make my objects available in a 
way so it's usable by many languages, yet is simple to implement?


Andras

brian sharon wrote:
> I don't think anyone has pointed this out yet, but COM objects are  not 
> inherently scriptable in and of themselves.  Anything scriptable  by 
> .NET, VB and other such languages has to implement IDispatch.  So  
> adding scriptability to your engine won't be as simple as just  deriving 
> everything from IUnknown.  For starters, I'm guessing that  all your 
> methods that you wish to expose aren't already returning  HRESULTs.
> 
> Trying to implement game engine scriptability through COM Automation  
> has to be just about the most painful way you could go.
> 
> --brian
> 
> On 26 Jan 2006, at 18:07, Andras Balogh wrote:
> 
>> I've heard that you can use COM objects from .NET using some wrapper.
>> My only problem with pure .NET is that not all customers are ready  to 
>> use it. I would like to have a package that you can use from  
>> unmanaged C/C++ as well as from VB, Python, Lua, C#...
>> Also, I definitely want to keep my engine in the unmanaged world.
>>
>> Thanks,
>>
>> Andras
>>
>> Jon Watte wrote:
>>
>>> If you want to be Microsoft specific (which COM is), then you  
>>> probably would do better supporting the CLR (.NET). It is much  
>>> richer, and there's a wide variety of languages that run within  the 
>>> CLR. The development and debugging tools are also top-notch.
>>> Cheers,
>>>             / h+
>>> Andras Balogh wrote:
>>>
>>>> Now, I believe that most decent scripting languages have some  kind of
>>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>>> it be the best to just wrap my engine into a COM object, and then  the

Re: [GD-General] scripting via COM?

[Kent Q. <ken...@co...>]

If you need cross-language scripting capability, definitely consider 
using SWIG. (http://www.swig.org/)

The pain you'll go through getting SWIG to read your header files is a 
tiny fraction of the agony you'll feel implementing scriptable COM 
objects and teaching your customers to use them in various ways.

SWIG can generate bindings for everything from Python and Perl and Ruby 
to Java to C# to Lua.

I haven't used it myself, but it comes pretty highly recommended if this 
is the kind of problem you have.

    Kent


Andras Balogh wrote:

> Well, yeah, this is not really a game engine, although it's similar. 
> The big difference is that with a game engine, one could make a 
> decision that it will be scripted with Lua, and be done with it. In 
> this case however, customers will probably want to use our rendering 
> services from all kinds of different languages, so it would be 
> preferable not to have such binding limitations.
>
> Do you have any other ideas, how I could make my objects available in 
> a way so it's usable by many languages, yet is simple to implement?
>
>
> Andras

Re: [GD-General] scripting via COM?

[Chad A. <ae...@ae...>]

Hi Andras,

I've gone down that road before, and it wasn't very pretty.  That said, XPCOM 
isn't a bad solution.  Integrates with JavaScript and Python and perhaps others. 
  You compile your IDL files into type libraries and C++ headers which the 
scripting language can use to understand how to talk to various interfaces (via 
some platform-dependent assembly).  The main reason I never followed through was 
that it's kind of annoying to use language-independent interfaces that can't 
take advantage of X or Y features of the language people end up using.  (Take 
the DOM as an example.)

Good luck,
Chad

Andras Balogh wrote:
> Well, yeah, this is not really a game engine, although it's similar. The 
> big difference is that with a game engine, one could make a decision 
> that it will be scripted with Lua, and be done with it. In this case 
> however, customers will probably want to use our rendering services from 
> all kinds of different languages, so it would be preferable not to have 
> such binding limitations.
> 
> Do you have any other ideas, how I could make my objects available in a 
> way so it's usable by many languages, yet is simple to implement?
> 
> 
> Andras
> 
> brian sharon wrote:
> 
>> I don't think anyone has pointed this out yet, but COM objects are  
>> not inherently scriptable in and of themselves.  Anything scriptable  
>> by .NET, VB and other such languages has to implement IDispatch.  So  
>> adding scriptability to your engine won't be as simple as just  
>> deriving everything from IUnknown.  For starters, I'm guessing that  
>> all your methods that you wish to expose aren't already returning  
>> HRESULTs.
>>
>> Trying to implement game engine scriptability through COM Automation  
>> has to be just about the most painful way you could go.
>>
>> --brian
>>
>> On 26 Jan 2006, at 18:07, Andras Balogh wrote:
>>
>>> I've heard that you can use COM objects from .NET using some wrapper.
>>> My only problem with pure .NET is that not all customers are ready  
>>> to use it. I would like to have a package that you can use from  
>>> unmanaged C/C++ as well as from VB, Python, Lua, C#...
>>> Also, I definitely want to keep my engine in the unmanaged world.
>>>
>>> Thanks,
>>>
>>> Andras
>>>
>>> Jon Watte wrote:
>>>
>>>> If you want to be Microsoft specific (which COM is), then you  
>>>> probably would do better supporting the CLR (.NET). It is much  
>>>> richer, and there's a wide variety of languages that run within  the 
>>>> CLR. The development and debugging tools are also top-notch.
>>>> Cheers,
>>>>             / h+
>>>> Andras Balogh wrote:
>>>>
>>>>> Now, I believe that most decent scripting languages have some  kind of
>>>>> support to easily call into COM objects. So I was thinking: Wouldn't
>>>>> it be the best to just wrap my engine into a COM object, and then  the
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log 
> files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>