gamedevlists-general

RE: [GD-General] Multiple Inheritance and RTTI

[Donavon K. <kei...@ea...>]

Instantiating a class by some means other than CoCreateInstance[Ex] is
not re-implementing COM.  Many, many standard COM objects are not
co-creatable (if I remember the jargon correctly).  Like... D3D, for
instance.

COM only has a few mandatory rules, like implementing IUnknown and
adhering to certain QueryInterface semantics.  It's not much of an
imposition and it leaves you open to interoperating with the rest of the
COM world.  Implement a typelib and adhere to some basic type rules and
your objects will be callable from Visual Basic and .NET.  Implement
IDispatch and you open your objects up to the scripting world.

Just don't do what one company I know did, and that's redefine IUnknown.
They called it "IUnknown", it had QI, AddRef, and Release, but IIDs were
strings, not GUIDs.  So their "custom" COM system looked just like COM,
but it was totally incompatible.  There was no possibility of interop
and where they could have taken advantage of ATL's rich set of classes,
they instead had to redefine their own macros and template classes.  

It was an utterly pointless exercise in NIH.  

Donavon

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Gareth Lewin
> Sent: Thursday, February 06, 2003 4:31 AM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> COM basics are extremly simple to implement.
> 
> You really need a standard way to implement a "Give me this interface"
> function. (QueryIterface)
> A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> And a base interface that concreate class implements.  (IUnknown)
> 
> A lot of COM also uses Factories, Ref counting and sometimes smart
> pointers.
> They are not needed, but tend to fit well ( For example ref counting
works
> nice with QueryInterface because you might have a few interfaces to
the
> same
> object ).
> 
> Again, Inside COM is a must read if you plan on having a COM like
system.
> 
> > -----Original Message-----
> > From: gekido [mailto:mi...@ub...]
> > Sent: 05 February 2003 21:30
> > To: gam...@li...
> > Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >
> >
> > with this said, anyone know of any opensource projects
> > implementing a base
> > COM-style cross-platform & cross-compiler library out there?
> >
> > surely there must be someone that's done the hard part for us ;}
> >
> > just curious
> >
> > mike w
> > www.uber-geek.ca
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

RE: [GD-General] Multiple Inheritance and RTTI

[Donavon K. <kei...@ea...>]

This is one of those times where I wish I'd looked more carefully at
what I wrote before sending it.  My comments sound pretty uncharitable
but this company has a lot of talented people who have done some really
great stuff.  I'm sure some people here know which company this is and
may even be working there, so if I stepped on any toes, I regret it.

--Charm School Dropout

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Donavon Keithley
> Sent: Saturday, February 08, 2003 12:28 AM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> Instantiating a class by some means other than CoCreateInstance[Ex] is
> not re-implementing COM.  Many, many standard COM objects are not
> co-creatable (if I remember the jargon correctly).  Like... D3D, for
> instance.
> 
> COM only has a few mandatory rules, like implementing IUnknown and
> adhering to certain QueryInterface semantics.  It's not much of an
> imposition and it leaves you open to interoperating with the rest of
the
> COM world.  Implement a typelib and adhere to some basic type rules
and
> your objects will be callable from Visual Basic and .NET.  Implement
> IDispatch and you open your objects up to the scripting world.
> 
> Just don't do what one company I know did, and that's redefine
IUnknown.
> They called it "IUnknown", it had QI, AddRef, and Release, but IIDs
were
> strings, not GUIDs.  So their "custom" COM system looked just like
COM,
> but it was totally incompatible.  There was no possibility of interop
> and where they could have taken advantage of ATL's rich set of
classes,
> they instead had to redefine their own macros and template classes.
> 
> It was an utterly pointless exercise in NIH.
> 
> Donavon

RE: [GD-General] Multiple Inheritance and RTTI

[Kyle W. <ky...@ga...>]

> This is one of those times where I wish I'd looked more carefully at
> what I wrote before sending it.  My comments sound pretty uncharitable
> but this company has a lot of talented people who have done some really
> great stuff.

Software development is, unfortunately, full of really, really dumb ideas
whose stupidity only becomes obvious after they've become an integral part
of your architecture.  I think most of us have done things that in various
ways have worked out as badly as re-implementing IUnknown.

Regards,
Kyle

Re: [GD-General] Multiple Inheritance and RTTI

[brian s. <pud...@po...>]

There's a bit more to full COM interop than that, and in my opinion it 
mostly adds baggage that you don't want or need.  For instance, all your 
methods need to return HRESULTs and the real results in out parameters 
(after all, you never know when that pesky DCOM marshaler is going to 
fail to connect to the IRenderer object running on some other machine 
:).  Imagine having to change all function calls like 
"interface->GetCountOfSomething()" to

    int count;
    HRESULT hr;
    hr = interface->GetCountOfSomething(&count);
    if (SUCCEEDED(hr) {
        ...

Blech.  

You would also want to define your interfaces in MS IDL to generate 
typelibs for IDispatch (which Visual Basic would need).  By contrast the 
approaches discussed here wouldn't even require a windows box to compile 
IDL files on, just straight C++.  

So it might have been pointless, but not <i>utterly</i> pointless  :).  

--brian

Donavon Keithley wrote:

>Instantiating a class by some means other than CoCreateInstance[Ex] is
>not re-implementing COM.  Many, many standard COM objects are not
>co-creatable (if I remember the jargon correctly).  Like... D3D, for
>instance.
>
>COM only has a few mandatory rules, like implementing IUnknown and
>adhering to certain QueryInterface semantics.  It's not much of an
>imposition and it leaves you open to interoperating with the rest of the
>COM world.  Implement a typelib and adhere to some basic type rules and
>your objects will be callable from Visual Basic and .NET.  Implement
>IDispatch and you open your objects up to the scripting world.
>
>Just don't do what one company I know did, and that's redefine IUnknown.
>They called it "IUnknown", it had QI, AddRef, and Release, but IIDs were
>strings, not GUIDs.  So their "custom" COM system looked just like COM,
>but it was totally incompatible.  There was no possibility of interop
>and where they could have taken advantage of ATL's rich set of classes,
>they instead had to redefine their own macros and template classes.  
>
>It was an utterly pointless exercise in NIH.  
>
>Donavon
>
>  
>
>>-----Original Message-----
>>From: gam...@li...
>>[mailto:gam...@li...] On Behalf Of
>>Gareth Lewin
>>Sent: Thursday, February 06, 2003 4:31 AM
>>To: gam...@li...
>>Subject: RE: [GD-General] Multiple Inheritance and RTTI
>>
>>COM basics are extremly simple to implement.
>>
>>You really need a standard way to implement a "Give me this interface"
>>function. (QueryIterface)
>>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
>>And a base interface that concreate class implements.  (IUnknown)
>>
>>A lot of COM also uses Factories, Ref counting and sometimes smart
>>pointers.
>>They are not needed, but tend to fit well ( For example ref counting
>>    
>>
>works
>  
>
>>nice with QueryInterface because you might have a few interfaces to
>>    
>>
>the
>  
>
>>same
>>object ).
>>
>>Again, Inside COM is a must read if you plan on having a COM like
>>    
>>
>system.
>  
>
>>>-----Original Message-----
>>>From: gekido [mailto:mi...@ub...]
>>>Sent: 05 February 2003 21:30
>>>To: gam...@li...
>>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
>>>
>>>
>>>with this said, anyone know of any opensource projects
>>>implementing a base
>>>COM-style cross-platform & cross-compiler library out there?
>>>
>>>surely there must be someone that's done the hard part for us ;}
>>>
>>>just curious
>>>
>>>mike w
>>>www.uber-geek.ca
>>>      
>>>

RE: [GD-General] Multiple Inheritance and RTTI

[Gareth L. <GL...@cl...>]

> But I asked for a real example (read taken from a real 
> project) of using
> (not implementing) the QI pattern, an example that demonstrates the
> superiority of QI over the alternatives.

Sorry, missunderstood. What are the alternatives that you want to compare it
with ? Internet explorer is an example I guess.

> FWIW, for the QI implementation, I prefer a 
> dynamic_cast-style interface:
> 
> if(IRenderable * p = queryInterface<IRenderable>(q))
> {
> // do stuff
> }

There are pros and cons to that. I prefer returning an error code like
HRESULT because the reason for the failure could be important. But it's a
matter of taste

> (when I feel like reinventing dynamic_cast at all, that is.)

COM isn't just a RTTI replacement. I personally use dynamic_cast in some of
my projects, but not as a way to build a concrete class out of interfaces.

YMMV I guess.

RE: [GD-General] Multiple Inheritance and RTTI

[Paul B. <pa...@mi...>]

It becomes slight less pointless when your platform changes and
your new platform doesn't support COM (or the ATL headers don't
compile on it properly).

Not that that would happens often.

Paul


> -----Original Message-----
> From: brian sharon [mailto:pud...@po...]=20
> Sent: Monday, February 10, 2003 1:15 PM
> To: gam...@li...
> Subject: Re: [GD-General] Multiple Inheritance and RTTI
>=20
>=20
> There's a bit more to full COM interop than that, and in my=20
> opinion it=20
> mostly adds baggage that you don't want or need.  For=20
> instance, all your=20
> methods need to return HRESULTs and the real results in out=20
> parameters=20
> (after all, you never know when that pesky DCOM marshaler is going to=20
> fail to connect to the IRenderer object running on some other machine=20
> :).  Imagine having to change all function calls like=20
> "interface->GetCountOfSomething()" to
>=20
>     int count;
>     HRESULT hr;
>     hr =3D interface->GetCountOfSomething(&count);
>     if (SUCCEEDED(hr) {
>         ...
>=20
> Blech. =20
>=20
> You would also want to define your interfaces in MS IDL to generate=20
> typelibs for IDispatch (which Visual Basic would need).  By=20
> contrast the=20
> approaches discussed here wouldn't even require a windows box=20
> to compile=20
> IDL files on, just straight C++. =20
>=20
> So it might have been pointless, but not <i>utterly</i>=20
> pointless  :). =20
>=20
> --brian
>=20
> Donavon Keithley wrote:
>=20
> >Instantiating a class by some means other than=20
> CoCreateInstance[Ex] is
> >not re-implementing COM.  Many, many standard COM objects are not
> >co-creatable (if I remember the jargon correctly).  Like... D3D, for
> >instance.
> >
> >COM only has a few mandatory rules, like implementing IUnknown and
> >adhering to certain QueryInterface semantics.  It's not much of an
> >imposition and it leaves you open to interoperating with the=20
> rest of the
> >COM world.  Implement a typelib and adhere to some basic=20
> type rules and
> >your objects will be callable from Visual Basic and .NET.  Implement
> >IDispatch and you open your objects up to the scripting world.
> >
> >Just don't do what one company I know did, and that's=20
> redefine IUnknown.
> >They called it "IUnknown", it had QI, AddRef, and Release,=20
> but IIDs were
> >strings, not GUIDs.  So their "custom" COM system looked=20
> just like COM,
> >but it was totally incompatible.  There was no possibility of interop
> >and where they could have taken advantage of ATL's rich set=20
> of classes,
> >they instead had to redefine their own macros and template classes. =20
> >
> >It was an utterly pointless exercise in NIH. =20
> >
> >Donavon
> >
> > =20
> >
> >>-----Original Message-----
> >>From: gam...@li...
> >>[mailto:gam...@li...]=20
> On Behalf Of
> >>Gareth Lewin
> >>Sent: Thursday, February 06, 2003 4:31 AM
> >>To: gam...@li...
> >>Subject: RE: [GD-General] Multiple Inheritance and RTTI
> >>
> >>COM basics are extremly simple to implement.
> >>
> >>You really need a standard way to implement a "Give me this=20
> interface"
> >>function. (QueryIterface)
> >>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> >>And a base interface that concreate class implements.  (IUnknown)
> >>
> >>A lot of COM also uses Factories, Ref counting and sometimes smart
> >>pointers.
> >>They are not needed, but tend to fit well ( For example ref counting
> >>   =20
> >>
> >works
> > =20
> >
> >>nice with QueryInterface because you might have a few interfaces to
> >>   =20
> >>
> >the
> > =20
> >
> >>same
> >>object ).
> >>
> >>Again, Inside COM is a must read if you plan on having a COM like
> >>   =20
> >>
> >system.
> > =20
> >
> >>>-----Original Message-----
> >>>From: gekido [mailto:mi...@ub...]
> >>>Sent: 05 February 2003 21:30
> >>>To: gam...@li...
> >>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >>>
> >>>
> >>>with this said, anyone know of any opensource projects
> >>>implementing a base
> >>>COM-style cross-platform & cross-compiler library out there?
> >>>
> >>>surely there must be someone that's done the hard part for us ;}
> >>>
> >>>just curious
> >>>
> >>>mike w
> >>>www.uber-geek.ca
> >>>     =20
> >>>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

RE: [GD-General] Multiple Inheritance and RTTI

[Donavon K. <kei...@ea...>]

<sigh>  Saying that it's "utterly pointless" was just really uncalled
for on my part.  I've been reading too much Usenet lately.
 
Now, with my hyperbole filter properly reseated...

I don't say that ATL must be used, but I wouldn't want to preclude it
either.  And it just seems to me that COM compliance leaves open a lot
of interesting interop and remoting scenarios.  

These days I'd be leaning towards .NET interop.  Like maybe writing unit
tests in C#.  The results could be logged to a database, it could fire
off an e-mail, the tests could be remotely managed, etc.  It's not that
you couldn't do these things by other means, but in .NET, interop with
COM is pretty painless and these sorts of things are so easy it's almost
fun.  When features are easy to implement, you tend to have them.
 
One client-server game I was on used COM interfaces with a custom
remoting layer for communication.  This enabled us to run the client and
server across the Net or in the same process, talking directly over
their vtables, and for the most part it just worked.  The proxy and stub
classes were custom but still auto-generated from type info, which
streamlined things a lot -- just change the IDL and update the
implementers and everything else is automatic.  We also used this for
remote management of the server.  But -- we used COM only for things we
needed to expose or thought we might expose in the future, like for
testing.

I'd love to do something similar with a single-player game/client.  Say
you're playing the game and you see something anomalous, so with the
game running you pop up some IM-like thing and ping your teammate who
may be on VPN, and for them the IM-like thing shows what's basically a
management console.  In one pane they see a screenshot updated every
second or so, and in the same UI they can poke around in the game state,
maybe remotely control the game, and so on.  The applications for QA are
obvious.

Donavon

P.S. IIRC, you don't need IDispatch as of VB6, but you would need a
typelib, and VB has some pretty severe type restrictions.


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Paul Bleisch
> Sent: Monday, February 10, 2003 1:27 PM
> To: gam...@li...
> Subject: RE: [GD-General] Multiple Inheritance and RTTI
> 
> 
> It becomes slight less pointless when your platform changes and
> your new platform doesn't support COM (or the ATL headers don't
> compile on it properly).
> 
> Not that that would happens often.
> 
> Paul
> 
> 
> > -----Original Message-----
> > From: brian sharon [mailto:pud...@po...]
> > Sent: Monday, February 10, 2003 1:15 PM
> > To: gam...@li...
> > Subject: Re: [GD-General] Multiple Inheritance and RTTI
> >
> >
> > There's a bit more to full COM interop than that, and in my
> > opinion it
> > mostly adds baggage that you don't want or need.  For
> > instance, all your
> > methods need to return HRESULTs and the real results in out
> > parameters
> > (after all, you never know when that pesky DCOM marshaler is going
to
> > fail to connect to the IRenderer object running on some other
machine
> > :).  Imagine having to change all function calls like
> > "interface->GetCountOfSomething()" to
> >
> >     int count;
> >     HRESULT hr;
> >     hr = interface->GetCountOfSomething(&count);
> >     if (SUCCEEDED(hr) {
> >         ...
> >
> > Blech.
> >
> > You would also want to define your interfaces in MS IDL to generate
> > typelibs for IDispatch (which Visual Basic would need).  By
> > contrast the
> > approaches discussed here wouldn't even require a windows box
> > to compile
> > IDL files on, just straight C++.
> >
> > So it might have been pointless, but not <i>utterly</i>
> > pointless  :).
> >
> > --brian
> >
> > Donavon Keithley wrote:
> >
> > >Instantiating a class by some means other than
> > CoCreateInstance[Ex] is
> > >not re-implementing COM.  Many, many standard COM objects are not
> > >co-creatable (if I remember the jargon correctly).  Like... D3D,
for
> > >instance.
> > >
> > >COM only has a few mandatory rules, like implementing IUnknown and
> > >adhering to certain QueryInterface semantics.  It's not much of an
> > >imposition and it leaves you open to interoperating with the
> > rest of the
> > >COM world.  Implement a typelib and adhere to some basic
> > type rules and
> > >your objects will be callable from Visual Basic and .NET.
Implement
> > >IDispatch and you open your objects up to the scripting world.
> > >
> > >Just don't do what one company I know did, and that's
> > redefine IUnknown.
> > >They called it "IUnknown", it had QI, AddRef, and Release,
> > but IIDs were
> > >strings, not GUIDs.  So their "custom" COM system looked
> > just like COM,
> > >but it was totally incompatible.  There was no possibility of
interop
> > >and where they could have taken advantage of ATL's rich set
> > of classes,
> > >they instead had to redefine their own macros and template classes.
> > >
> > >It was an utterly pointless exercise in NIH.
> > >
> > >Donavon
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: gam...@li...
> > >>[mailto:gam...@li...]
> > On Behalf Of
> > >>Gareth Lewin
> > >>Sent: Thursday, February 06, 2003 4:31 AM
> > >>To: gam...@li...
> > >>Subject: RE: [GD-General] Multiple Inheritance and RTTI
> > >>
> > >>COM basics are extremly simple to implement.
> > >>
> > >>You really need a standard way to implement a "Give me this
> > interface"
> > >>function. (QueryIterface)
> > >>A standard way of iding interfaces (GUIDs or FourCCs or whatever)
> > >>And a base interface that concreate class implements.  (IUnknown)
> > >>
> > >>A lot of COM also uses Factories, Ref counting and sometimes smart
> > >>pointers.
> > >>They are not needed, but tend to fit well ( For example ref
counting
> > >>
> > >>
> > >works
> > >
> > >
> > >>nice with QueryInterface because you might have a few interfaces
to
> > >>
> > >>
> > >the
> > >
> > >
> > >>same
> > >>object ).
> > >>
> > >>Again, Inside COM is a must read if you plan on having a COM like
> > >>
> > >>
> > >system.
> > >
> > >
> > >>>-----Original Message-----
> > >>>From: gekido [mailto:mi...@ub...]
> > >>>Sent: 05 February 2003 21:30
> > >>>To: gam...@li...
> > >>>Subject: Re: [GD-General] Multiple Inheritance and RTTI
> > >>>
> > >>>
> > >>>with this said, anyone know of any opensource projects
> > >>>implementing a base
> > >>>COM-style cross-platform & cross-compiler library out there?
> > >>>
> > >>>surely there must be someone that's done the hard part for us ;}
> > >>>
> > >>>just curious
> > >>>
> > >>>mike w
> > >>>www.uber-geek.ca
> > >>>
> > >>>
> >
> >
> >
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> > http://www.vasoftware.com
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

[GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

I strongly believe that C# is a worthy successor to C++,
and my experience of programming in C# has been positive.
The DirectX 9 demonstration programs in C# are impressive,
mostly because they show Microsoft's comittment to making
it easy to use DirectX API's in C# applications.  I may
continue using OpenGL for rendering (via my own wrapper)
because I find many aspects of Direct3D annoying and 
backwards (like the left-handed coordinate system, lost
surfaces, bugs in API that can crash your application,
and general pointless complexity).

I am wondering if anyone has been seriously burned or
frustrated with their own attempt to code a game engine
or complex real-time application in C#.

One of my own concerns is that I wasn't able to immediately
execute a release build version of a C# application
under Windows 98.  (MSCOREE.DLL is the first required DLL
to not be found.  There are potentially dozens of DLL's
required to get a release version C# application to run
under Windows 98.  I haven't explored this yet.)
Yes, Windows 98 may have an "End Of Life" status.
Nonetheless, I am interested in supporting a platform
that still has a significant percentage of the gamer
market.

  (On a side note, I will AVOID upgrading from Windows 2000
  to Windows XP as long as it is practical, because I do not
  like the information gathering, "calling home", and some other
  "innovations".  I am not anti-Microsoft, but I don't like
  the lack of respect for user privacy or security embodied
  in certain products.  Okay, maybe I'll get Windows XP
  for "platform testing" since XP is perhaps the top OS
  for today's gamers.)

I am also concerned about performance.  I have done some
Google searching for performance test results.  The few
test results I have encountered seem to indicate that the
raw processing speed of C# is comperable to C/C++.  However,
the "non-deterministic" (as far as the programmer is concerned)
garbage collection seems to lead to a quadratic increase in
execution time, and large spikes in memory usage, for 
applications that do large amounts of memory-related
operations.

I guess the only way to really know the facts is to
write applications in C# that capture the essence of
what I intend to do in a more elaborate application
and see how well it turns out after trying my best
to code in the C# idiom and optimize.  And then there's
the issue of supporting Windows 98...  Maybe that's
as absurd as a rendering engine that is capable of
falling back on software rendering to cover the case
of a person who doesn't have a $49 GeForce3 card.

But I'd still like to learn about any success / horror
experiences with C# "real-time" game coding anyone
might have.

--- Colin

cp...@ea...

Re: [GD-General] C# versus C++ for game engines

[Javier A. <ja...@py...>]

Colin Fahey <cp...@ea...> wrote:

> continue using OpenGL for rendering (via my own wrapper)
> because I find many aspects of Direct3D annoying and
[Fairly unnecessary rant removed]

> One of my own concerns is that I wasn't able to immediately
> execute a release build version of a C# application
> under Windows 98.

Nor would you be able to under a fresh Windows 2000, not sure about XP. You
need to install the .NET runtime redistributable in order to run .NET
programs. I have never checked, but I'm prety sure that .NET supports Win98
and WinMe.

>   (On a side note, I will AVOID upgrading from Windows 2000
[Fairly unnecessary rant removed]

> I am also concerned about performance.  I have done some
> Google searching for performance test results.  The few
> test results I have encountered seem to indicate that the
> raw processing speed of C# is comperable to C/C++.  However,
> the "non-deterministic" (as far as the programmer is concerned)
> garbage collection seems to lead to a quadratic increase in
> execution time, and large spikes in memory usage, for
> applications that do large amounts of memory-related
> operations.

I recall some people have been figuring out ways to make the gc run in a
more consistent manner, and I assume that the .NET runtime will be adding
support for that kind of operations. You should be able to find about this
possibly in the csharp mailing lists or newsgroups.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] C# versus C++ for game engines

[Noel L. <ll...@co...>]

On Thu, 20 Feb 2003 04:41:39 -0800
Colin Fahey <cp...@ea...> wrote:

> I strongly believe that C# is a worthy successor to C++,

[big snip]

What exactly do you find so outstanding in C# that you're willing to:
- Learn a new language
- Give up on lots of platforms
- Give up on lots of existing libraries
- Give up on lots of development tools
- Give up on years of expertise from your team
- Give up on a mature language with its own idioms and documentation.
- Give up on a standardized language and adopt a proprietary one

This is a serious question, not an attempt at trolling. I have read some
about C# and I really don't see what the big deal is for most game
programming. The way I see it, changing languages is something that will
be painful and cause a medium-term productivity loss, so there must be
some *extremely* compelling reasons to change.

Automatic garbage collection... shrug. It really doesn't seem that much
of a big deal. Do people spend all that much time with memory problems
in their apps?

Easier interoperatibility with .NET? Maybe OK for tools, but probably
not necessary for most games (especially not console games).

What other reasons are there?


--Noel
ll...@co...

Re: [GD-General] C# versus C++ for game engines

[Javier A. <ja...@py...>]

Noel Llopis <ll...@co...> wrote:

>> I strongly believe that C# is a worthy successor to C++,
>
> This is a serious question, not an attempt at trolling. I have read
> some about C# and I really don't see what the big deal is for most
> game programming. The way I see it, changing languages is something
> that will be painful and cause a medium-term productivity loss, so
> there must be some *extremely* compelling reasons to change.

Overall I like C# a lot, and I think that given a few years to reach
maturity (anyone remember C++ without multiple inheritance or templates?) it
will be a fantastic language. The fact that module interfaces are compiled
into the binary instead of relying on the archaic "include" method is
definitely a huge step forward from C++. Attributes and reflection should
make interfacing with other languages / tools much easier, too. I like the
fact that some patterns (Interfaces for example) are burned into the
language.

The problems you point out, however, make its adoption unadvisable for most
game projects. There is not a lot of productivity to gain compared to the
costs involved. I wonder if this situation will remain the same in, say, 5
years.

> Automatic garbage collection... shrug. It really doesn't seem that
> much of a big deal. Do people spend all that much time with memory
> problems in their apps?

Certainly not. If a game developer has trouble with memory management /
leaks, I'm sure that is only the tip of a huge iceberg of problems waiting
to show up.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

[NOTE: I'm sorry about the irrelevant comments regarding
certain Microsoft products.]

One thing I really like about C# is the crash tracing
for release builds.  Creating a similar feature in
C++ is VERY platform dependent, and I think you need
to generate a *.PDB file with all of your symbols,
along with the DbgHlp.dll.  It's a fact that sometimes
a crash bug only appears in the release version of
the application.  Sometimes the crash occurs on a
test machine that doesn't have Visual Studio, and
sometimes it is difficult to do remote debugging.
Yes, applications should handle all exceptions,
but even so, you can log the exception in plain
text form for study, or users in the field can 
transmit the stack trace to you.  This stack trace
may still be relevant even if you are still making
changes to the code.

Reflection is also very cool.  With an in-game editor
you can get information about game objects, or manipulate
objects.  Doing something like this in C++ requires 
a lot of discipline and extra code, or *.PDB or *.MAP
files in conjunction with a symbol parsing mechanism
like the one used by the FuBi library.

I regard garbage collection as a nice safety net just
in case someone forgets to free a memory allocation.
In C++ you would have to write your own memory
manager, or create memory buffer objects that get
destroyed when out of scope, or use smart pointers,
etc, to get some assurance that an allocation won't
slip through the cracks.

Maybe it doesn't rank high on the list of good reasons
to switch to C#, but it is nice that there is no such 
thing as a "header" file (*.H) in C#.  It's a bit of
a pain to keep the *.CPP and *.H files synchronized;
it's just a chore.

C# offers a huge set of very convenient API's.
You can add FTP, ZIP, HTTP, XML, etc, to your
game quite easily.  The contanier classes and
string class have many interesting methods.
Gone are the days of having to typedef your
own primitive data types (INT16, UINT32, 
FLOAT32, etc) to prevent platform dependencies!

The strictness of the C# compiler means that there
will be fewer silly errors that wasted ENORMOUS
amounts of time on C/C++ projects.  I think that
this aspect alone makes switching to C# worthwhile
for new PC projects.  I was on a 9-month project
for a major publisher, and during the last three
months, when the entire team was living at the
office, I think I spent half the time fixing
SILLY bugs caused by uninitialized variables,
etc.  All such errors would have been impossible
with C#, since the compiler is strict about
initializing variables, type safety, use of
boolean in conditional expressions, no more
"fall through" in switch cases, and the option
of explicitly designating parameters as input
or output.

My post was written to solicit responses from people
who had written game engine code in C# to learn about
their experiences.  For some people, the transition
to C# doesn't make sense;  I won't argue that.
I'm interested in hearing about actual C# game engine
experiences.

--- Colin

cp...@ea...

P.S.:  For the record, I am a happy Windows
programmer, and I use many Microsoft products
(Visual Studio .NET, MS-Office), and I really
like Windows 2000.  I bought all Microsoft
software from stores at retail prices, going
back to Visual Studio 4.0 and Windows 95 on
my first PC.  I have fifty books on various
aspects of Windows programming and software.
I really like Win32, DirectSound, WinSock,
VfW / DirectShow, MFC, etc.

It so happens that I have also done a lot of
Linux programming, too, including kernel mode
software, video capture drivers, etc.  I am
a big fan of Linux, and I hope the Mono
project is a big success so that my C# code
will work under Linux, too.

Everyone has their gripes about software products,
and I'm sorry that I shared a couple of my
gripes about certain Microsoft products.
But "Microsoft-bashing"?  I don't think any
intelligent person could accept broad generalizations
about a corporation or its products, but at the
same time I'm not ashamed to share my feelings
about specific aspects of products that I think
are mistakes, even if features can theoretically
be "turned off" (burden on consumer), etc.

Anyhow, I know all of this is not appropriate
for this forum.  I just want to point out that
my previous remarks weren't meant to fuel any
silly generalized dislike (or like) of Microsoft.

Re: [GD-General] C# versus C++ for game engines

[Thatcher U. <tu...@tu...>]

On Feb 20, 2003 at 10:37 -0800, Colin Fahey wrote:
> 
> One thing I really like about C# is the crash tracing for release
> builds.  Creating a similar feature in C++ is VERY platform
> dependent, and I think you need to generate a *.PDB file with all of
> your symbols, along with the DbgHlp.dll.

You need to keep some symbols around to pull up the crash report in
the debugger, but you don't have to distribute them.  Bruce Dawson
wrote a little article in Game Developer a few years ago, about crash
tracing for release builds of C++ apps.  I borrowed the code, and here
it is in Soul Ride's CVS:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/soulride/soulride/src/exceptionhandler.hpp?rev=HEAD&content-type=text/vnd.viewcvs-markup

It's Windows-specific (but then so is .NET -- not sure why you say
platform-dependence is a disadvantage of stack-unwinding).  Basically
when you get a crash report from a user, you load up the old symbols
in MSVC, punch the EIP value into the registers window, and you're
looking at the crash site.

For the record, I'm a satisfied user of Texaco gasoline and petroleum
products.

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

> > One thing I really like about C# is the crash tracing for release
> > builds.  Creating a similar feature in C++ is VERY platform
> > dependent, and I think you need to generate a *.PDB file with all of
[...]
> You need to keep some symbols around to pull up the crash report in
> the debugger, but you don't have to distribute them.  Bruce Dawson
[...]

> It's Windows-specific (but then so is .NET -- not sure why you say
> platform-dependence is a disadvantage of stack-unwinding). [...]

If you have the Mono version of the .NET API under Linux, then
you can enjoy the same stack unwinding.

Also, if you can get your .NET application to run under Windows 98
(something I haven't determined yet), then you enjoy the same
stack unwinding there, too.  Whereas the DbgHlp.dll is a little bit 
messed up under Windows 98.

--- Colin

cp...@ea...

Re: [GD-General] C# versus C++ for game engines

[Mike W. <mi...@ub...>]

>
>
>If you have the Mono version of the .NET API under Linux, then
>you can enjoy the same stack unwinding.
>  
>
except that microsoft has declared that they will be suing and attacking 
any attempts at reverse engineering their .net technology...

the mono project seems doomed to failure as a result.

mike w
www.uber-geek.ca

Re: [GD-General] C# versus C++ for game engines

[Parveen K. <pk...@al...>]

On Thu, 2003-02-20 at 20:03, Mike Wuetherick wrote:
> >
> >
> >If you have the Mono version of the .NET API under Linux, then
> >you can enjoy the same stack unwinding.
> > =20
> >
> except that microsoft has declared that they will be suing and attacking=20
> any attempts at reverse engineering their .net technology...
>=20
> the mono project seems doomed to failure as a result.

There are two seperate issues here.  C# is an ISO standard.
http://msdn.microsoft.com/net/ecma/

I don't know what the point or the benefit of .NET will be to me.  I
don't think MS knows either.  A lot of buzzwords and spin is flying all
over the place.

Writing code in one language, calling it from another language, with a
GUI written in another language.  That's pretty cool.

Garbage collection...big deal.  Been done before, not really beneficial
for most projects that I would be involved in.  I can search google for
"C++ garbage collector" and get tons of hits and choose a GC if I
really, really needed one.  Sure that's kind of a hack...but whatever.=20
But I can also choose to use handles or smart pointers.

There's a lot of cruft in C++ but that's because it's a pretty mature
lanuage.  Java is acquiring cruft.  And C# will acquire cruft as well.

=46rom the projects that I have worked on.  The success of a project
doesn't really depend on the "sexiness" of a language.  It usually
depends on the level of experience the developers have with the chosen
language.  How many C# developers can you find with 10 years of
experience?

Having said all that, I'd consider C# if there were compilers for more
platforms.  That would guarantee it will be around for 10 years or so.=20
But right now, I see it as developers using it as a more powerful
replacement for VB.

A bunch of my friends in business-software land are using C# as a
replacement for Java for apps that aren't expected to be ported.

The big benefit of C# and Java are the big class libraries.  Hopefully
the next C++ standard standardizes a lot of stuff from Boost and other
libraries.  There are benefits to having access to a widely understood,
used, and debugged library.  And you can choose to ignore the library if
you wish.

PK
www.sfu.ca/~pkaler

Re: [GD-General] C# versus C++ for game engines

[Colin F. <cp...@ea...>]

2003 February 20th
Thursday

>>> except that microsoft has declared that they will be suing
>>> and attacking any attempts at reverse engineering their
>>> .net technology...
>>> 
>>> the mono project seems doomed to failure as a result.

Here's a quote from the March 2002 book "C# in a Nutshell:
A Desktop Quick Reference" (published by O'Reilly):

  [On page 11, in a section entitled "ECMA Standardization"]

  "However, this openness was taken to a new level in 
  November 2000 when Microsoft, along with co-sponsors
  Intel and HP, officially submitted the specifications
  for the C# language, a subset of the FCL, and the
                       -------------------
  runtime environment to ECMA for standardization."

  [NOTE: I added the underline to draw your attention
  to a phrase.]

FCL stands for Framework Class Library, which includes
the reflection, stack trace, thread, socket, and
collection API's, among thousands of other classes.
Was the "subset of the FCL" that Microsoft submitted 
to the ECMA so small that it did not include reflection
or stack tracing ability?

Is the Mono project "reverse engineering" anything, or 
are participants simply implementing a public-domain
specification?

I don't know if anyone on this list would know, but...
Is it considered "reverse engineering" or some other kind
of intellectual property violation to re-implement an
API from scratch?  In other words, can it be illegal to
deploy an API with the same class names and method 
names as some other existing API?  (I assume this 
doesn't apply when the API has been submitted for
standardization.  Right?)

This is veering off-topic, I know, but this relates to
the concern that C# cannot be used for cross-platform
game engines (e.g., Windows and Linux).  I know that
most people mean "consoles" when they say "cross-platform"
in the video game industry.  It might be a while before
we see the Common Language Runtime (CLR) and portions
of the Framework Class Library (FCL) implemented for
PlayStation 2\3 and GameCube, but I suppose X-Box
developers might already be using C#.

--- Colin

cp...@ea...

[Secret irrelevant sub-thread continues:]
<useless_wacky_factoids>
P.S.: I like Chevron with Techron, but it's probably 
due to the fact that the station is about 200 yards
from my apartment, and has a pretty glow at
night...and it's one of the few places in Irvine
where one can buy a Coke at 3 A.M. (other than 
Ralph's and Denny's).
</useless_wacky_factoids>

Re: [GD-General] C# versus C++ for game engines

[Mike W. <mi...@ub...>]

>
>
>Is the Mono project "reverse engineering" anything, or 
>are participants simply implementing a public-domain
>specification?
>
yeah i'm not sure what microsoft's concerns are, besides the fact that 
MS hasn't been able to milk the mono guys out of some kind of 'license' 
fee or something to get the rights to implement ms tech on linux (like 
they are currently doing for windowsmedia licensees)

>I don't know if anyone on this list would know, but...
>Is it considered "reverse engineering" or some other kind
>of intellectual property violation to re-implement an
>API from scratch?  In other words, can it be illegal to
>deploy an API with the same class names and method 
>names as some other existing API?  (I assume this 
>doesn't apply when the API has been submitted for
>standardization.  Right?)
>  
>
the api is not patentable, only the implementation i believe...for 
example the wine project isn't a reverse engineering of anything, simply 
a reimplementation of the windows api on linux...it's the technical 
details that make the world of difference...the wine guys haven't tried 
to make a binary-exact copy of the source, just reinterpreting the API 
'their way'...

>This is veering off-topic, I know, but this relates to
>the concern that C# cannot be used for cross-platform
>game engines (e.g., Windows and Linux).  I know that
>most people mean "consoles" when they say "cross-platform"
>in the video game industry.  
>
i'm not sure about that....there's a reason the majority of servers are 
running linux versions these days - EVEN with the new console online 
ventures...of course xbox developers probably don't get this option 
(surprise, surprise)

mike w
www.uber-geek.ca

Re: [GD-General] C# versus C++ for game engines

[Mark W. <ma...@aw...>]

> >If you have the Mono version of the .NET API under Linux, then
> >you can enjoy the same stack unwinding.
> >
> >
> except that microsoft has declared that they will be suing and attacking
> any attempts at reverse engineering their .net technology...
>
> the mono project seems doomed to failure as a result.

http://mail.gnome.org/archives/gnome-hackers/2002-February/msg00031.html

See heading "What is Mono?"

Miguel de Icaza & co are doing this in full knowledge of Microsoft.  In
fact,  I seem to remember talk of it being almost a partnership of sorts,
but I can't seem to dredge up the link I read to validate this.

Can't really think of how to steer this back towards having much to do with
game development!

[OT ends here. sorry!]

Mark Webster

Re: [GD-General] C# versus C++ for game engines

[Mike W. <mi...@ub...>]

couple of differing viewpoints i've found

http://www.zdnet.com.au/newstech/ebusiness/story/0,2000024981,20270819,00.htm

http://slashdot.org/articles/02/04/05/1456252.shtml?tid=109

mike w
www.uber-geek.ca



Mark Webster wrote:

>Miguel de Icaza & co are doing this in full knowledge of Microsoft.  In
>fact,  I seem to remember talk of it being almost a partnership of sorts,
>but I can't seem to dredge up the link I read to validate this.
>

Re: [GD-General] C# versus C++ for game engines

[Thatcher U. <tu...@tu...>]

On Feb 20, 2003 at 06:45 -0800, Colin Fahey wrote:
> 
> > > One thing I really like about C# is the crash tracing for release
> > > builds.  Creating a similar feature in C++ is VERY platform
> > > dependent, and I think you need to generate a *.PDB file with all of
> [...]
> > You need to keep some symbols around to pull up the crash report in
> > the debugger, but you don't have to distribute them.  Bruce Dawson
> [...]
> 
> > It's Windows-specific (but then so is .NET -- not sure why you say
> > platform-dependence is a disadvantage of stack-unwinding). [...]
> 
> If you have the Mono version of the .NET API under Linux, then
> you can enjoy the same stack unwinding.
> 
> Also, if you can get your .NET application to run under Windows 98
> (something I haven't determined yet), then you enjoy the same
> stack unwinding there, too.  Whereas the DbgHlp.dll is a little bit 
> messed up under Windows 98.

Could be, although I was using Win98 back when I stole that
exceptionhandler code, and it seemed to work OK.  I don't remember any
details though...

-- 
Thatcher Ulrich
http://tulrich.com

RE: [GD-General] C# versus C++ for game engines

[Kyle W. <ky...@ga...>]

Noel wrote:
> Automatic garbage collection... shrug. It really doesn't seem that much
> of a big deal. Do people spend all that much time with memory problems
> in their apps?

Amen.  Memory is a resource like any other.  If you're unable to keep from
leaking memory, then God only knows what else you're leaking in the way of
handles, locks, etc.

Kyle