gamedevlists-general Mailing List for gamedev (Page 62)
Brought to you by:
vexxed72
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(28) |
Nov
(13) |
Dec
(168) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(51) |
Feb
(16) |
Mar
(29) |
Apr
(3) |
May
(24) |
Jun
(25) |
Jul
(43) |
Aug
(18) |
Sep
(41) |
Oct
(16) |
Nov
(37) |
Dec
(208) |
2003 |
Jan
(82) |
Feb
(89) |
Mar
(54) |
Apr
(75) |
May
(78) |
Jun
(141) |
Jul
(47) |
Aug
(7) |
Sep
(3) |
Oct
(16) |
Nov
(50) |
Dec
(213) |
2004 |
Jan
(76) |
Feb
(76) |
Mar
(23) |
Apr
(30) |
May
(14) |
Jun
(37) |
Jul
(64) |
Aug
(29) |
Sep
(25) |
Oct
(26) |
Nov
(1) |
Dec
(10) |
2005 |
Jan
(9) |
Feb
(3) |
Mar
|
Apr
|
May
(11) |
Jun
|
Jul
(39) |
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
2006 |
Jan
(24) |
Feb
(18) |
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(14) |
Aug
(29) |
Sep
(2) |
Oct
(5) |
Nov
(4) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(9) |
Oct
(5) |
Nov
(4) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(34) |
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Nicolas R. <nic...@fr...> - 2002-12-25 19:47:15
|
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. |
From: brian h. <bri...@py...> - 2002-12-24 22:03:05
|
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 |
From: brian h. <bri...@py...> - 2002-12-24 17:22:45
|
> 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 |
From: Nicolas R. <nic...@fr...> - 2002-12-24 16:47:14
|
> > 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 |
From: Javier A. <ja...@py...> - 2002-12-24 16:21:54
|
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. |
From: Noel L. <ll...@co...> - 2002-12-24 15:40:09
|
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... |
From: Grills, J. <jg...@so...> - 2002-12-24 14:43:14
|
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 |
From: Nicolas R. <nic...@fr...> - 2002-12-24 14:30:52
|
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. |
From: Tom F. <to...@mu...> - 2002-12-24 14:12:34
|
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 > |
From: Tom F. <to...@mu...> - 2002-12-24 14:12:12
|
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 > |
From: Cruise <cr...@ca...> - 2002-12-24 14:08:13
|
>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 ] |
From: mike w. <mi...@ub...> - 2002-12-24 14:05:31
|
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 > |
From: Noel L. <ll...@co...> - 2002-12-24 14:04:15
|
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... |
From: Tom F. <to...@mu...> - 2002-12-24 13:59:50
|
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 > |
From: Nicolas R. <nic...@fr...> - 2002-12-24 13:55:16
|
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 |
From: Grills, J. <jg...@so...> - 2002-12-24 13:54:52
|
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 |
From: Grills, J. <jg...@so...> - 2002-12-24 13:49:48
|
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 |
From: <ce...@ce...> - 2002-12-24 13:26:21
|
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 |
From: Tom F. <to...@mu...> - 2002-12-24 13:02:59
|
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 |
From: <ce...@ce...> - 2002-12-24 12:50:17
|
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 |
From: Chris H. <c.h...@ke...> - 2002-12-24 12:08:56
|
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 |
From: Gareth L. <GL...@cl...> - 2002-12-24 10:23:47
|
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. |
From: Josiah M. <jm...@ma...> - 2002-12-24 03:56:25
|
> > 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. |
From: Jeremy N. <jj...@kr...> - 2002-12-23 21:50:50
|
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 |
From: <ga...@nl...> - 2002-12-23 20:56:08
|
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... |