gamedevlists-general — List for discussing general game development issues

RE: [GD-General] Sockets question

[Nicolas R. <nic...@fr...>]

Hi,

I think UDP always need a port, whether you bind it (define the port) or
not (port is choosen by the socket stack at runtime).
It means that since you are listening on a given port, if you use
another socket to respond, it will be on another port. Which is likely
to break NAT/PAT networks anyway.
Apart from that port-translation thing (and of course
filtering/firewalls), I don't see why it wouldn't work.

Note that if you are using the personal firewall (XP, 2000 ?) you may
have a rule which forbids UDP reception from a source you never sent
anything to before (which is the case if you change sockets).

Merry Xmas anyway !


Nicolas.

[GD-General] Sockets question

[brian h. <bri...@py...>]

I'll probably figure this out 5 minutes after posting this, but hey, if 
I don't post the question, I won't figure it out.  Sacrifices to the 
coding gods and all that.

Anyway, I've traditionally written UDP servers such that when I need to 
respond to a client, I just do a sendto() using the address I grabbed 
via recvfrom().  This has always worked when I used the same socket for 
both the send and receive, i.e.

recvfrom( mySocket, ... );
sendto( mySocket, ... );

I've tried to generalize some things, and in the process I wanted to 
remove the constraint that I send data out on the same socket I 
received that data from, but it's not working.  i.e.

recvfrom( mySocket, &sa, ... );
sendto( defaultSocket, &sa, ... );

This isn't working.  sendto() doesn't fail, but the client never sees 
that return packet.  

The defaultSocket is just a kind of dummy socket I would like to keep 
around in case I want to just send random crap out on the wire without 
being forced to connect and/or bind first.

I'm assuming I'm making a major assumption here that isn't valid, but 
after rereading Stevens again, I can't figure out what I might be doing 
wrong.  I tried bind()ing the defaultSocket before use to an ephemeral 
port, and that didn't make any difference.  If I go back to using the 
same socket for send/receive, it works fine, but if I substitute a 
different socket, it stops working.

I can't see this being an illegal use of the sockets, since otherwise 
it would mean you could never sendto() a destination that you hadn't 
previously, say, connect()ed to or recvfrom()ed, which doesn't seem 
right at all.

Anyway, just to clarify:

//this works (pseudo code obviously)
mySocket = socket( ... );
bind( mySocket, myPort );
recvfrom( mySocket, &sa, ... );
sendto( mySocket, &sa .. );

//this doesn't (in that the client never sees a response)
mySocket = socket( ... );
bind( mySocket, myPort );
defaultSocket = socket( ... );
//doesn't matter if I bind defaultSocket() or not
recvfrom( mySocket, &sa, ... );
sendto( defaultSocket, &sa ... );

-Hook

RE: [GD-General] Overhead of RTTI

[brian h. <bri...@py...>]

> I really think that one day in the future, we'll look back on C++, 
> templates and the STL and say, "What in the hell were we thinking?!?".

Some of us have been saying that for quite a while now =)

-Hook

RE: [GD-General] Overhead of RTTI

[Nicolas R. <nic...@fr...>]

> > Objects should inherit at most ONE object, and implement as many 
> > interfaces as needed. Interfaces should expend at most ONE 
> interface.
> 
> Can you explain more carefully? I didn't really understand 
> the second rule.
> 

That second rule is just to say that you never need MI at interface
level.
Just define separate interfaces.
I'm even wondering if one would need inheritance for interfaces at all
(apart from a "root" interface like the COM's IUnknown).

Objects on the opposite do need MI for interface implementation.

Here, we are trying to use different words for inheritance:
Object To Object inheritance = Override (the "IS A" relationship).
Object To Interface inheritance = Implementation.
Interface To Interface inheritance = Expansion.
(of course there is never any Interface To Object inheritance).



Nicolas

Re: [GD-General] Overhead of RTTI

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

Nicolas Romantzoff wrote:

>>> And, as a general rule, multiple inheritance is evil and should be
>>> avoided.
>>
>> Whoa! Talk about an overblown general statement!

I'd like to add that I concur with the original post. One could say (grabs
the number-filled hat) that 70% of MI uses are plainly bad and 20% are ok
but can be done better in other ways (aggregation, etc). Note that I see
inheriting multiple interfaces as something different from "general" MI.

> Objects should inherit at most ONE object, and implement as many
> interfaces as needed.
> Interfaces should expend at most ONE interface.

Can you explain more carefully? I didn't really understand the second rule.

Re: [GD-General] Overhead of RTTI

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

On Tue, 24 Dec 2002 06:43:11 -0800
"Grills, Jeff" <jg...@so...> wrote:

> My experience with game programmers is that MI is
> most often misused.  Sure, it has appropriate applications, but I'd bet at
> least 90% of the MI use in our game is ill-founded.

That's very true. I would also extend that statement to apply to single
inheritance, but that's just me ;-)


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

RE: [GD-General] Overhead of RTTI

[Grills, J. <jg...@so...>]

I think it's a good general rule.  I never said it was an absolute, mind
you, just a general rule.  My experience with game programmers is that MI is
most often misused.  Sure, it has appropriate applications, but I'd bet at
least 90% of the MI use in our game is ill-founded.

Actually, it's funny that you mention templates.  We are seriously debating
a rule about templated classes in headers requiring lead permissions as
well.  They substantially increase build times, dependencies, and a host of
other evil problems.  In fact, we just ran into a problem where MSVC 6's PDB
format is limited to 64mb, and one of our largest applications will no
longer link with full debugging information because of it.  I've done some
analysis of the PDB contents, and about 27mb of that are text strings
containing symbol names with "_STL" in them.  Unless compiler/linker support
for templates improves significantly, I really think that one day in the
future, we'll look back on C++, templates and the STL and say, "What in the
hell were we thinking?!?".

And yes, we have a large team of 13 programmers.

j

-----Original Message-----
From: Noel Llopis [mailto:ll...@co...]
Sent: Tuesday, December 24, 2002 8:04 AM
To: gam...@li...
Subject: Re: [GD-General] Overhead of RTTI



On Tue, 24 Dec 2002 05:54:49 -0800
"Grills, Jeff" <jg...@so...> wrote:

> And, as a general rule, multiple inheritance is evil and should be
avoided.

Whoa! Talk about an overblown general statement!

I would say that multiple inheritance definitely has its place, in
particular inheritance of abstract interfaces.

> In fact, we've recently put a rule in place where any use of multiple
> inheritance requires a lead programmer's permission before submitting to
> source control.

Do you have similar rules about using templates? What about classes
that exceed 1000 lines of code? Both of those situations seem more
potentially dangerous to me than using multiple inheritance. Just
curious.

Of course, on the other hand, in a large team it might be a good idea if
before checking in any new classes or adding any new dependencies
between classes a lead programmer approves it first, but that's a
separate discussion.


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



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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] Overhead of RTTI

[Nicolas R. <nic...@fr...>]

Hi,

> > And, as a general rule, multiple inheritance is evil and should be 
> > avoided.
> 
> Whoa! Talk about an overblown general statement!
> 
> I would say that multiple inheritance definitely has its 
> place, in particular inheritance of abstract interfaces.
> 

Do not mix object inheritance, and interface expension / implementation.
Though those are completely mixed (for evil sake) in C++, one must pay
attention to be absolutely clear on how they are used.

Objects should inherit at most ONE object, and implement as many
interfaces as needed.
Interfaces should expend at most ONE interface.

A lot of inheritance problems we got in the past were due to a
misunderstanding of those statements.

On the RTTI subject, I really like to have all objects (and I say
objects) implementing a RTTI scheme of our own, and providing interface
access methods.
Interfaces do need some kind of static identification, but usually RTTI
is not needed at that point.

Nicolas Romantzoff.

RE: [GD-General] Overhead of RTTI

[Tom F. <to...@mu...>]

I would modify that to: "inheritance of multiple virtual classes is evil".
Multiple inheritance is just fine and dandy, as long as only one (or none)
of the parent classes is a virtual class.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]
> Sent: 24 December 2002 13:55
> To: 'gam...@li...'
> Subject: RE: [GD-General] Overhead of RTTI
> 
> 
> 
> I didn't quite understand your email, so this comment may not 
> apply to your
> case.  You can't dynamic_cast<> from a void*.  You have to 
> have an object
> that has a virtual function in it, and you should be casting 
> from a base
> class of the desired target.
> 
> And, as a general rule, multiple inheritance is evil and 
> should be avoided.
> In fact, we've recently put a rule in place where any use of multiple
> inheritance requires a lead programmer's permission before 
> submitting to
> source control.
> 
> j
> 
> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: Tuesday, December 24, 2002 7:26 AM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> 
> Hey,
> 
> It might be a bad design, but now that I've hit this problem, I'd also
> like to know why it happens and how much RTTI would *really* hurt. The
> class hierarchy in discussion has a base Obect class that has a name
> field and is virtually inherited by all the other classes in the
> hierarchy. Now I have a Texture class and a RenderTarget class (buth
> abstract), and in the implementation I have a (say) D3DTexture class
> that inherits both Texture and RenderTarget. The problem is that the
> RenderSystem class (the one that does the actual rendering) is pretty
> abstracted itself so it works with Textures and renderTargets. At some
> point I have to cast from Object to D3DTexture and there's where all
> hell brakes loose. I can't even cast from void * to 
> D3DTexture for that
> matter (well, the void * was initially a RenderTarget cast of
> D3DTexture, so yes, it is a whole madness). My bet is on 
> dynamic_cast or
> modifying the design (I'll probably choose the latter 
> eventually). Seems
> like hard abstraction would be way easier (and safer) with 
> RTTI enabled.
> 
> Thanks again,
> Adrian
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Tom Forsyth
> Sent: Tuesday, December 24, 2002 3:02 PM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> It's usually far quicker and easier to code it yourself with a few
> helper
> functions, unless you actually need the full madness of RTTI.
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Adrian Cearnau [mailto:ce...@ce...]
> > Sent: 24 December 2002 12:50
> > To: gam...@li...
> > Subject: [GD-General] Overhead of RTTI
> > 
> > 
> > Hey everyone and merry X-Mas,
> > 
> > I'd like to know what the realistic overhead of enabling 
> RTTI in a C++
> > project is. Any opinions are welcome.
> > 
> > Thank you,
> > Adrian 'cearny' Cearnau
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Overhead of RTTI

[Tom F. <to...@mu...>]

I'm talking rubbish of course - you don't need a whole load of GetD3DTexture
functions, just one in the base class and one in D3DTexture itself. Doh.
Brain not in gear...

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: 24 December 2002 13:58
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> 
> The easy, if rather messy and special-cased way, is to have a 
> whole load of
> functions like this all the way down the hierarchy:
> 
> virtual D3DTexture *MyCoolClass::GetD3DTexture ( void )
> {
> 	// I'm not a D3DTexture you fool.
> 	return NULL;
> }
> 
> 
> ...but then for the D3DTexture class it's
> 
> virtual D3DTexture *D3DTexture::GetD3DTexture ( void )
> {
> 	return this;
> }
> 
> 
> Now sure, this pollutes your namespace with lots of 
> GetMyFunkyClassName()
> calls, but if that's all you need to do, it's robust and 
> pretty easy to
> understand, and doesn't require any RTTI support.
> 
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Adrian Cearnau [mailto:ce...@ce...]
> > Sent: 24 December 2002 13:26
> > To: gam...@li...
> > Subject: RE: [GD-General] Overhead of RTTI
> > 
> > 
> > Hey,
> > 
> > It might be a bad design, but now that I've hit this 
> problem, I'd also
> > like to know why it happens and how much RTTI would 
> *really* hurt. The
> > class hierarchy in discussion has a base Obect class that has a name
> > field and is virtually inherited by all the other classes in the
> > hierarchy. Now I have a Texture class and a RenderTarget class (buth
> > abstract), and in the implementation I have a (say) D3DTexture class
> > that inherits both Texture and RenderTarget. The problem is that the
> > RenderSystem class (the one that does the actual rendering) 
> is pretty
> > abstracted itself so it works with Textures and 
> renderTargets. At some
> > point I have to cast from Object to D3DTexture and there's where all
> > hell brakes loose. I can't even cast from void * to 
> > D3DTexture for that
> > matter (well, the void * was initially a RenderTarget cast of
> > D3DTexture, so yes, it is a whole madness). My bet is on 
> > dynamic_cast or
> > modifying the design (I'll probably choose the latter 
> > eventually). Seems
> > like hard abstraction would be way easier (and safer) with 
> > RTTI enabled.
> > 
> > Thanks again,
> > Adrian
> > 
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...] 
> On Behalf Of
> > Tom Forsyth
> > Sent: Tuesday, December 24, 2002 3:02 PM
> > To: gam...@li...
> > Subject: RE: [GD-General] Overhead of RTTI
> > 
> > It's usually far quicker and easier to code it yourself with a few
> > helper
> > functions, unless you actually need the full madness of RTTI.
> > 
> > Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> > 
> > This email is the product of your deranged imagination,
> > and does not in any way imply existence of the author.
> > 
> > > -----Original Message-----
> > > From: Adrian Cearnau [mailto:ce...@ce...]
> > > Sent: 24 December 2002 12:50
> > > To: gam...@li...
> > > Subject: [GD-General] Overhead of RTTI
> > > 
> > > 
> > > Hey everyone and merry X-Mas,
> > > 
> > > I'd like to know what the realistic overhead of enabling 
> > RTTI in a C++
> > > project is. Any opinions are welcome.
> > > 
> > > Thank you,
> > > Adrian 'cearny' Cearnau
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > 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:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Overhead of RTTI

[Cruise <cr...@ca...>]

>The easy, if rather messy and special-cased way, is to have a=
 whole load of
>functions like this all the way down the hierarchy:
>
>virtual D3DTexture *MyCoolClass::GetD3DTexture ( void )
>{
>=A0=A0=A0=A0// I'm not a D3DTexture you fool.
>=A0=A0=A0=A0return NULL;
>}
>
>
>....but then for the D3DTexture class it's
>
>virtual D3DTexture *D3DTexture::GetD3DTexture ( void )
>{
>=A0=A0=A0=A0return this;
>}
>
>
>Now sure, this pollutes your namespace with lots of=
 GetMyFunkyClassName()
>calls, but if that's all you need to do, it's robust and pretty=
 easy to
>understand, and doesn't require any RTTI support.
>
>
>Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
>
>This email is the product of your deranged imagination,
>and does not in any way imply existence of the author.
>

This obviously can be restricted to only the classes that you=
 need to get the specific class pointer for.

Half-Life used this method within it's game entity hierarchy, but=
 restricted it to only two classes/functions:

MyMonsterPointer() and MySquadMonsterPointer()

which did exactly as Tom described above for CBaseMonster and=
 CBaseSquadMonster respectively.


If you have a reasonably flat hierarchy, and this functionality=
 is only required for a few classes, then it's not too ugly, and=
 is probably about as fast/efficient/safe as you could get this=
 sort of thing.


[ cruise / casual-tempest.net / transference.org ]

Re: [GD-General] Blender

[mike w. <mi...@ub...>]

i use milkshape on a daily basis. it is excellent, gets the job done,
stable, fast...

and directly supports the game formats i need it to, so i might be a bit
biased though ;}

The first Truespace (1.0) is also freely available on the net, but can't say
how useful it might be for game dev...

cheers

mike w
www.uber-geek.ca

----- Original Message -----
From: "Gareth Lewin" <GL...@cl...>
To: <gam...@li...>
Sent: Tuesday, December 24, 2002 2:23 AM
Subject: RE: [GD-General] Blender


> Disclaimers: I am not a modeler ( I have problems with cubes ) nor have I
> ever used Milkshape3D. All I know about it is that people that have used
it
> think it is fairly good.
>
> > Does anyone here know of other free modellers that are useable?
>
> Try MilkShape3D
> http://www.swissquake.ch/chumbalum-soft/
>
> Also, unlike what you said about Blender (Although, again I've never tried
> blender) Milkshape3D is targeted at games, not CG. It has a lot of support
> for differant exported formats.
>
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Overhead of RTTI

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

On Tue, 24 Dec 2002 05:54:49 -0800
"Grills, Jeff" <jg...@so...> wrote:

> And, as a general rule, multiple inheritance is evil and should be avoided.

Whoa! Talk about an overblown general statement!

I would say that multiple inheritance definitely has its place, in
particular inheritance of abstract interfaces.

> In fact, we've recently put a rule in place where any use of multiple
> inheritance requires a lead programmer's permission before submitting to
> source control.

Do you have similar rules about using templates? What about classes
that exceed 1000 lines of code? Both of those situations seem more
potentially dangerous to me than using multiple inheritance. Just
curious.

Of course, on the other hand, in a large team it might be a good idea if
before checking in any new classes or adding any new dependencies
between classes a lead programmer approves it first, but that's a
separate discussion.


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

RE: [GD-General] Overhead of RTTI

[Tom F. <to...@mu...>]

The easy, if rather messy and special-cased way, is to have a whole load of
functions like this all the way down the hierarchy:

virtual D3DTexture *MyCoolClass::GetD3DTexture ( void )
{
	// I'm not a D3DTexture you fool.
	return NULL;
}


...but then for the D3DTexture class it's

virtual D3DTexture *D3DTexture::GetD3DTexture ( void )
{
	return this;
}


Now sure, this pollutes your namespace with lots of GetMyFunkyClassName()
calls, but if that's all you need to do, it's robust and pretty easy to
understand, and doesn't require any RTTI support.


Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: 24 December 2002 13:26
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> 
> Hey,
> 
> It might be a bad design, but now that I've hit this problem, I'd also
> like to know why it happens and how much RTTI would *really* hurt. The
> class hierarchy in discussion has a base Obect class that has a name
> field and is virtually inherited by all the other classes in the
> hierarchy. Now I have a Texture class and a RenderTarget class (buth
> abstract), and in the implementation I have a (say) D3DTexture class
> that inherits both Texture and RenderTarget. The problem is that the
> RenderSystem class (the one that does the actual rendering) is pretty
> abstracted itself so it works with Textures and renderTargets. At some
> point I have to cast from Object to D3DTexture and there's where all
> hell brakes loose. I can't even cast from void * to 
> D3DTexture for that
> matter (well, the void * was initially a RenderTarget cast of
> D3DTexture, so yes, it is a whole madness). My bet is on 
> dynamic_cast or
> modifying the design (I'll probably choose the latter 
> eventually). Seems
> like hard abstraction would be way easier (and safer) with 
> RTTI enabled.
> 
> Thanks again,
> Adrian
> 
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Tom Forsyth
> Sent: Tuesday, December 24, 2002 3:02 PM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> It's usually far quicker and easier to code it yourself with a few
> helper
> functions, unless you actually need the full madness of RTTI.
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Adrian Cearnau [mailto:ce...@ce...]
> > Sent: 24 December 2002 12:50
> > To: gam...@li...
> > Subject: [GD-General] Overhead of RTTI
> > 
> > 
> > Hey everyone and merry X-Mas,
> > 
> > I'd like to know what the realistic overhead of enabling 
> RTTI in a C++
> > project is. Any opinions are welcome.
> > 
> > Thank you,
> > Adrian 'cearny' Cearnau
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> 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] Overhead of RTTI

[Nicolas R. <nic...@fr...>]

Hi,

Built-in RTTI is well suited for complex inheritance diagrams, but its
overhead is not neglectable (just like C++ exception handling).

I'm using exactly the same "kind" of hierarchy, banning multiple
inheritance, and just adding a few things:

The "Object" class is declared as:
{
public:
	static ObjectClass itsClass;
	virtual ObjectClass* GetClass(void) const
{ return &thisObjectClass; }
	inline const char*   GetClassName(void) const
{ return GetClass()->Name(); }
	inline bool		   IsOfClass(const ObjectClass& oc)
const { return (GetClass() == &oc); }
};

Inherited classes (that do need RTTI) do also have:
{
public:
	Static ObjectClass itsClass;
	virtual ObjectClass* GetClass(void) const { return
&thisObjectClass; }
};

Whenever you want to check for an object being of a given class
(something like your rendering device checking that the vertex buffer
pointer is a D3D vertex buffer), you just have to call the GetClass and
check returned value with the D3D::thisClass. (Or in the exemple above,
using the IsOfClass method).
Note that the above implementation is nice since it is still safe to use
the RTTI methods in constructors/destructors.

It turned out (for me) to be faster than built-in RTTI system, and a lot
smaller (in terms of code/memory usage).

Of course, my implementation is a bit more complicated, with ObjectClass
constructors building the class hierarchy, making possible to check for
inheritance, or more complex behaviors, maintaining a constructor list
(for dynamic construction), and things like that... 

The "thisClass" object is also a nice place to put static tweakable
values. The nice thing is that you can "forget" your own RTTI
declaration where it is not needed (for example abstract class you don't
need to know about), saving some memory/code-size (and eventually speed
when checking for inheritance).


Using macros like RTTI_DECLARE usually makes life easier in that case :)

#define	RTTI_DECLARE_EX(cloname)	public: \
								static
cloname		_class; \
								virutal
ObjectClass*	GetClass(void) const { return &_class; }
#define	RTTI_DECLARE			RTTI_DECLARE_EX(ObjectClass)




Nicolas Romantzoff

RE: [GD-General] Overhead of RTTI

[Grills, J. <jg...@so...>]

I didn't quite understand your email, so this comment may not apply to your
case.  You can't dynamic_cast<> from a void*.  You have to have an object
that has a virtual function in it, and you should be casting from a base
class of the desired target.

And, as a general rule, multiple inheritance is evil and should be avoided.
In fact, we've recently put a rule in place where any use of multiple
inheritance requires a lead programmer's permission before submitting to
source control.

j

-----Original Message-----
From: Adrian Cearnau [mailto:ce...@ce...]
Sent: Tuesday, December 24, 2002 7:26 AM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI


Hey,

It might be a bad design, but now that I've hit this problem, I'd also
like to know why it happens and how much RTTI would *really* hurt. The
class hierarchy in discussion has a base Obect class that has a name
field and is virtually inherited by all the other classes in the
hierarchy. Now I have a Texture class and a RenderTarget class (buth
abstract), and in the implementation I have a (say) D3DTexture class
that inherits both Texture and RenderTarget. The problem is that the
RenderSystem class (the one that does the actual rendering) is pretty
abstracted itself so it works with Textures and renderTargets. At some
point I have to cast from Object to D3DTexture and there's where all
hell brakes loose. I can't even cast from void * to D3DTexture for that
matter (well, the void * was initially a RenderTarget cast of
D3DTexture, so yes, it is a whole madness). My bet is on dynamic_cast or
modifying the design (I'll probably choose the latter eventually). Seems
like hard abstraction would be way easier (and safer) with RTTI enabled.

Thanks again,
Adrian

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Tom Forsyth
Sent: Tuesday, December 24, 2002 3:02 PM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI

It's usually far quicker and easier to code it yourself with a few
helper
functions, unless you actually need the full madness of RTTI.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: 24 December 2002 12:50
> To: gam...@li...
> Subject: [GD-General] Overhead of RTTI
> 
> 
> Hey everyone and merry X-Mas,
> 
> I'd like to know what the realistic overhead of enabling RTTI in a C++
> project is. Any opinions are welcome.
> 
> Thank you,
> Adrian 'cearny' Cearnau



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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] Overhead of RTTI

[Grills, J. <jg...@so...>]

I think it somewhat depends on your compiler.

Two of the larger profile spikes in a Win32 compile (using MSVC 6) of one of
our applications right now are caused by excessive use of dynamic_cast.  I
spent some time looking at the code dynamic_cast created, and it's ugly.  It
even does string compares internally, which is completely gross.  For places
where performance matters, we are adding a "virtual Derived *
asDerivedClass()" function which returns NULL in the base class and "this"
in the Derived class.  Tracking down inappropriate frequent callers of
dynamic_cast can be pretty tedious as well.

GCC's code gen for this stuff is apparently a fair bit better.

j


-----Original Message-----
From: Tom Forsyth [mailto:to...@mu...]
Sent: Tuesday, December 24, 2002 7:02 AM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI


It's usually far quicker and easier to code it yourself with a few helper
functions, unless you actually need the full madness of RTTI.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: 24 December 2002 12:50
> To: gam...@li...
> Subject: [GD-General] Overhead of RTTI
> 
> 
> Hey everyone and merry X-Mas,
> 
> I'd like to know what the realistic overhead of enabling RTTI in a C++
> project is. Any opinions are welcome.
> 
> Thank you,
> Adrian 'cearny' Cearnau

RE: [GD-General] Overhead of RTTI

[<ce...@ce...>]

Hey,

It might be a bad design, but now that I've hit this problem, I'd also
like to know why it happens and how much RTTI would *really* hurt. The
class hierarchy in discussion has a base Obect class that has a name
field and is virtually inherited by all the other classes in the
hierarchy. Now I have a Texture class and a RenderTarget class (buth
abstract), and in the implementation I have a (say) D3DTexture class
that inherits both Texture and RenderTarget. The problem is that the
RenderSystem class (the one that does the actual rendering) is pretty
abstracted itself so it works with Textures and renderTargets. At some
point I have to cast from Object to D3DTexture and there's where all
hell brakes loose. I can't even cast from void * to D3DTexture for that
matter (well, the void * was initially a RenderTarget cast of
D3DTexture, so yes, it is a whole madness). My bet is on dynamic_cast or
modifying the design (I'll probably choose the latter eventually). Seems
like hard abstraction would be way easier (and safer) with RTTI enabled.

Thanks again,
Adrian

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Tom Forsyth
Sent: Tuesday, December 24, 2002 3:02 PM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI

It's usually far quicker and easier to code it yourself with a few
helper
functions, unless you actually need the full madness of RTTI.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: 24 December 2002 12:50
> To: gam...@li...
> Subject: [GD-General] Overhead of RTTI
> 
> 
> Hey everyone and merry X-Mas,
> 
> I'd like to know what the realistic overhead of enabling RTTI in a C++
> project is. Any opinions are welcome.
> 
> Thank you,
> Adrian 'cearny' Cearnau



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
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] Overhead of RTTI

[Tom F. <to...@mu...>]

It's usually far quicker and easier to code it yourself with a few helper
functions, unless you actually need the full madness of RTTI.

Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Adrian Cearnau [mailto:ce...@ce...]
> Sent: 24 December 2002 12:50
> To: gam...@li...
> Subject: [GD-General] Overhead of RTTI
> 
> 
> Hey everyone and merry X-Mas,
> 
> I'd like to know what the realistic overhead of enabling RTTI in a C++
> project is. Any opinions are welcome.
> 
> Thank you,
> Adrian 'cearny' Cearnau

[GD-General] Overhead of RTTI

[<ce...@ce...>]

Hey everyone and merry X-Mas,

I'd like to know what the realistic overhead of enabling RTTI in a C++
project is. Any opinions are welcome.

Thank you,
Adrian 'cearny' Cearnau

[GD-General] hemisphere lighting

[Chris H. <c.h...@ke...>]

Hi,

I've read the sheets from the Meltdown presentations and stumbled again on
Hemisphere lighting. I think I know that it is used to represent the sky
colour using cubemaps that are modulated with an objects' material/textures.
Is there any more information on hemisphere lighting besides those meltdown
presentations?

I've found specific papers using google or NEC's CiteSeer....

Chris
---
Keep IT Simple Software
Van Alphenstraat 12
7514 DD Enschede

W: http://www.keepitsimple.nl
E: mailto:in...@ke...
T: +31 53 4356687

RE: [GD-General] Blender

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

Disclaimers: I am not a modeler ( I have problems with cubes ) nor have I
ever used Milkshape3D. All I know about it is that people that have used it
think it is fairly good.

> Does anyone here know of other free modellers that are useable?

Try MilkShape3D
http://www.swissquake.ch/chumbalum-soft/

Also, unlike what you said about Blender (Although, again I've never tried
blender) Milkshape3D is targeted at games, not CG. It has a lot of support
for differant exported formats.

Re: [GD-General] Blender

[Josiah M. <jm...@ma...>]

> > On Sun, Dec 22, 2002 at 06:59:18PM -0600, brian hook wrote:
> > > Anyone use Blender as a modeling tool and have any comments on it,
e.g.
> > > comparing it to LW, Max, Maya, etc.?

I myself am looking for a modelling tool, but it would really be best if it
were free (it's a personal project). It doesn't need to be fancy, but
support for animations would be good. Blender looks promising, but looks
like it is designed for making CG for movies and stuff. How easy is it to
make models for games with it instead?

Does anyone here know of other free modellers that are useable?

> > I use it (with a host of custom back-end scripts) as the geometry and
> > level editor for our upcoming coin-op production. Blender is not without
>
> One might want to take a look at OpenArchitect 3d
> (http://www.openarchitect3d.org) ... Paul Nettle's latest work, which
> plans to be a central environment for content creation, and has a strong
> plugin scheme

That looks pretty nice, but the site doesn't make it too clear what all the
program can do without having to write a plugin yourself to do it. It seems
that OpenArchitect had a plugin that did all sorts of cool stuff, but nobody
is allowed to use it.

Re: [GD-General] Blender

[Jeremy N. <jj...@kr...>]

On Mon, 23 Dec 2002 ga...@nl... wrote:

> On Sun, Dec 22, 2002 at 06:59:18PM -0600, brian hook wrote:
> > Anyone use Blender as a modeling tool and have any comments on it, e.g.
> > comparing it to LW, Max, Maya, etc.?
>
> I use it (with a host of custom back-end scripts) as the geometry and
> level editor for our upcoming coin-op production. Blender is not without

One might want to take a look at OpenArchitect 3d
(http://www.openarchitect3d.org) ... Paul Nettle's latest work, which
plans to be a central environment for content creation, and has a strong
plugin scheme.

I believe the first (GPL) release will be next month.

J

Re: [GD-General] Blender

[<ga...@nl...>]

On Sun, Dec 22, 2002 at 06:59:18PM -0600, brian hook wrote:
> Anyone use Blender as a modeling tool and have any comments on it, e.g. 
> comparing it to LW, Max, Maya, etc.?

It is definitely the most powerful GPL modeler currently available,
as it used to be a commercial product.  It's UI is cryptic, but fast
once you learn it (like vi). Probably fine for most of us professionals
who focus on a fast day-in day-out workflow and are willing to invest
time up-front in learning the tool, instead of needing an extensive
self-guiding point-and-click menu system.

Good animation features, though animation data is not (yet) directly
exportable (bones, weights, etc), but since it is GPL you could hack
this in yourself. Workable, but not perfect or exhaustive, palette of
modeling tools, including lattice deformation, extrusion, beveling,
booleans. Also contains other useful editing features - hierarchical
parenting, temporarily hiding geometry, layers, linking meshes or
materials between objects, default uv mappings (cube, sphere, from window,
etc), flexible and saveable window layout, etc.

It has somewhat limited export formats, though VRML and DXF are supported.
Limited Python scripting for extensibility, which is somewhat unstable
right now since the product just became GPL.

There is no undo feature.

It has a built-in real-time game engine, not a workhorse, but good for
rapidly prototyping ideas or making small productions.

My executive summary is that for games, it has enough to get the job done.
I use it (with a host of custom back-end scripts) as the geometry and
level editor for our upcoming coin-op production. Blender is not without
its quirks, but for making games, it has enough features that you can
always get the job done. And it's GPL with source code, so you can hack
on it all you want.  But expect to spend some time learning the GUI, and
writing external scripts to get the data from Blender into your engine.

Norman Lin
nl...@nl...