gamedevlists-general — List for discussing general game development issues

[GD-General] RE: Hardware Survey

[Daniel V. <vo...@ep...>]

This is off-topic though I assume a couple of developers might be interested
in it anyways. Below are our numbers with regard to OS distribution. The
percentages are unique CD keys used to connect to our master server over
time seen per OS for the client and active dedicated servers at the time of
the database query (roughly a week ago).

UT 2003           Client      Server

Linux              0.69 %     40.66 %
Windows 98/ME     19.63 %      2.74 %
Windows NT         0.00 %      6.03 %
Windows 2000      11.87 %     34.96 %
Windows XP        67.78 %     15.62 %

This discussion should be moved to a more appropriate list so I CC'ed the
GD-General list at gam...@li.... Please only
reply there.

Thanks,

-- Daniel, Epic Games Inc.

> -----Original Message-----
> From: Developer-only Forum for DirectX programming issues
> [mailto:DIR...@DI...]On Behalf Of Andrew Grant
> Sent: Saturday, January 04, 2003 3:47 PM
> To: DIR...@DI...
> Subject: Hardware Survey
>
>
> I came across this which I found rather interesting and thought
> I'd pass it
> along. Not sure how old this is (or if it's updated, I think originally it
> was generated when users installed a new patch).
>
> http://hlsdk.valve-erc.com/
>
> Some very unexpected stats in there, especially the choice of OS!
>
>
> Andy @
> Climax Brighton
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>  FAQ: http://msdn.microsoft.com/library/techart/DirectX8faq.htm
>  Web Interface: http://DISCUSS.MICROSOFT.COM/archives/DIRECTXDEV.html
>  Problems/Suggestions: DIR...@di...
>  Use the Web Interface (above) to unsubscribe from the list.
>  Use plain-text only. HTML is not accepted. Attachments are removed
>  MSDN DirectX Developer Centre:  http://msdn.microsoft.com/DirectX
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>

Re: [GD-General] FLT_MIN

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

> Ok, I found this in the MSDN :
> _control87( _EM_INVALID, _MCW_EM ); // DENORMAL is unmasked by this call

Hey, that's neat!

> As long as it works well, I think I'm going to
> allow denormalized numbers. Any known problems
> with this ?

Loss of precision. 1.4E-45 has one bit
of precision!  So, in this extreme case you can
have up to 50% error in precision, but at least the
order of magnitude is still sane.  You can have
exact powers of two all the way down to (2^(-149))
without loss of precision of course.


> That's a very subtle (and interesting IMHO) bug that happens only because
of
> a combination of bad things :

Yes, this is very interesting.  I didn't even know
about denormalized floats until you mentioned this
mystery and I did some research, but now I can see
that it is something to be aware of.

--- Colin

Re: [GD-General] FLT_MIN

[Pierre T. <p.t...@wa...>]

> Thus, if you allow for denormalized
> numbers,

Ok, I found this in the MSDN :

_control87( _EM_INVALID, _MCW_EM ); // DENORMAL is unmasked by this call

If I use this, an FPU exception is generated on underflow, and resulting
values are different indeed. Ok, it makes sense now - I just never really
bothered thinking about denormalized values before.

However I'm surprised the default state is not to trigger the exception. As
long as it works well, I think I'm going to allow denormalized numbers. Any
known problems with this ?

------------------

For the records, the whole thing started when a function similar to that one
failed in Debug :

void MyVector::ClampLength(float limit_length)
{
 float CurrentSquareLength;

 if((CurrentSquareLength = SquareLength()) > limit_length * limit_length)
 {
  float Coeff = limit_length / sqrtf(CurrentSquareLength);
  x *= Coeff;
  y *= Coeff;
  z *= Coeff;
 }
}

( With of course:
 float MyVector::SquareLength() const { return x*x + y*y + z*z;   }
)

Fed with this, it bypasses the test and divides by zero anyway :

 const float MaxLength = 4.91523e-24f;
 MyVector Dummy(-1.11408e-23f, -4.0593e-24f, 5.51083e-25f);
 Dummy.ClampLength2(MaxLength);

That's a very subtle (and interesting IMHO) bug that happens only because of
a combination of bad things :

- limit_length squared underflows to zero
- SquaredLength is ~10e-46 so it should underflow as well, and the test
should become "if( 0 > 0 )" => false => no divide. Yet it doesn't underflow
since internally the computation is performed with double-precision,
regardless of the code using "float" or "double". So it really does "if
(10e-46 > 0)" => true => blam.
- the way the function is written, doing the assignment in the "if" (it
wouldn't break if it was done when declaring the float, because the 10e-46
would have been assigned to the float, becoming zero)

For some reasons it works correctly in Release. Probably just an
accident....

Pierre

Re: [GD-General] FLT_MIN

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

2003 January 2nd
Thursday

Pierre,

IEEE 32-bit floats are in the following format:

SEEEEEEEEMMMMMMMMMMMMMMMMMMMMMMM
33222222222211111111110000000000
10987654321098765432109876543210

The 8 exponent bits EEEEEEEE form
a number from 0 to 255.

The interpretation of this exponent
is as follows:

0      : Denormalized number; No implicit
  leading "1" bit in mantissa;  First bit
  in explicit mantissa bits (MMMMM...) is
  now the actual leading bit with an effective
  value of 1.0;  Exponentiated value is
  (2^(-127)).
1..254 : Exponent is (EEEEEEEE - 127)
255    : Mantissa contains special number
           codes (NaN, undefined, infinity)

Here's a quote from my <float.h> file:

#define FLT_MIN   1.175494351e-38F   /* min positive value */

This value is roughly equal to 2^(-126), which
really *IS* the minimum positive FLOATING POINT
value.  In bit form:

0:0000001:00000000000000000000000

S = 0; E = 1; M = 1.0

Hence:  1.0 * 2^(1 - 127) = 2^(-126)

Your expression:

     (0.5f*sqrtf(FLT_MIN)) *
     (0.5f*sqrtf(FLT_MIN))

is not zero, because the product has some
room in the "denormalized" range.

If the exponent number is "0",
then we're in "denormalized" territory.
The exponent part is thus (2^(-127)),
and the denormalized value can be a single
"1" bit in the least-significant bit
of the mantissa, with an effective
denormalized (no implicit "1" bit)
mantissa value of (2^(-22)).  Thus,
a denormalized number can be as
small as: ((2^(-127)) * (2^(-22)) =
(2^(-149)) = 1.401298464E-45 roughly.

Thus, if you allow for denormalized
numbers,  1.401298464E-45  is the
minimum positive value, as you have
observed.  (Or, 0x00000001 in memory viewed
as hex, as you pointed out.)

--- Colin

cp...@ea...
http://www.colinfahey.com


----- Original Message -----
From: "Pierre Terdiman" <p.t...@wa...>
To: <gam...@li...>
Sent: Thursday, January 02, 2003 2:55 PM
Subject: [GD-General] FLT_MIN


> Here's something I don't get....
>
> I was looking for the smallest floating-point value F such as F^2 doesn't
> underflow. So, I wrote something like :
>
> F^2 = FLT_MIN ;
> => F = sqrtf ( FLT_MIN ) ;
>
> Then, as a test, I wrote :
>
>  const float HalfSqrtFMin = sqrtf(FLT_MIN) * 0.5f;
>  const float f = HalfSqrtFMin*HalfSqrtFMin;
>
> I was expecting f to be zero due to underflow. Yet it wasn't. That was my
> first clue something weird was going on.
>
> So I investigated a bit more and found that the floating-point value I was
> looking for was 1.40130e-045, which gives zero once squared. This is the
> floating-point value whose binary representation is 0x00000001.
>
> I've always thought FLT_MIN was the "min positive value" (as stated in
> Float.h). What the hell is that number then ? I'm sure I'm missing
something
> obvious....
>
> Pierre
>
> PS:  http://www.codercorner.com/FPU.jpg
>
>
>
> -------------------------------------------------------
> 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

[GD-General] FLT_MIN

[Pierre T. <p.t...@wa...>]

Here's something I don't get....

I was looking for the smallest floating-point value F such as F^2 doesn't
underflow. So, I wrote something like :

F^2 = FLT_MIN ;
=> F = sqrtf ( FLT_MIN ) ;

Then, as a test, I wrote :

 const float HalfSqrtFMin = sqrtf(FLT_MIN) * 0.5f;
 const float f = HalfSqrtFMin*HalfSqrtFMin;

I was expecting f to be zero due to underflow. Yet it wasn't. That was my
first clue something weird was going on.

So I investigated a bit more and found that the floating-point value I was
looking for was 1.40130e-045, which gives zero once squared. This is the
floating-point value whose binary representation is 0x00000001.

I've always thought FLT_MIN was the "min positive value" (as stated in
Float.h). What the hell is that number then ? I'm sure I'm missing something
obvious....

Pierre

PS:  http://www.codercorner.com/FPU.jpg

Re: [GD-General] Protecting our game

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

> So, if you just want to turn down the casual users who have
> no idea what the registry is, it's good "regiquette" to 
> place your already-installed flag in
> HKLM\Software\YourCompany\YourProduct.

Make that HKCU.  HKLM access is protected unless you have Admin 
Rights.  The only problem with using HKCU is that the game 
becomes "unregistered" for each user.

Brian

Re: [GD-General] Protecting our game

[Ivan-Assen I. <as...@ha...>]

my $0.02:

15 minutes spent with FileMon and RegMon from
http://www.sysinternals.com should convince anyone that
spewing random garbage in the registry or in MS-bla-blah-32.DLL files
in the System folder is useless.

So, if you just want to turn down the casual users who have
no idea what the registry is, it's good "regiquette" to 
place your already-installed flag in
HKLM\Software\YourCompany\YourProduct.

Re: [GD-General] Overhead of RTTI

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

On Dec 24, 2002 at 02:11 -0000, Tom Forsyth wrote:
> 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.

Ooh, this is one of my hot buttons!

The "correct" (according to me :) statement is:

  Inheritance of multiple virtual classes is virtuous.

  Multiple inheritance is just fine and dandy, as long as ALL of the
  ancestor classes are virtual parents.

MI of NON-virtual classes is where things get intolerably fubared.  (I
can expand on this or provide pointers if necessary.)

Unfortunately, this situation makes it pretty damn confusing to
maintain optimal use of "virtual public" and plain "public" throughout
a hierarchy, in a team environment.  My private thoughts these days
are tending towards "MI is evil".

-- 
Thatcher Ulrich
http://tulrich.com

Re: [GD-General] Protecting our game

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

i know of more than a few programs that use the 'random' registry key for
their lock/unlock code, and it is very successful (i've tried to defeat a
few - albeit unsuccessfully ;)...

Personally, i find this very annoying - leaving garbage all over my
registry - the registry is a bloated nightmare at the best of times without
every stupid little shareware program i install leaving their own custom
garbage along with the 'normal' stuff...but again, only the technically
savvy will even realize what you are doing - in particular with the
registry - and you won't trigger antivirus programs by writing a registry
key...and it WILL work as an option.

probably the best way 'technically' to do it - that or having a global 'key'
like the wonid system most big games use these days, but i guess that
depends on how much money/effort you feel like putting into securing your
game - and how many customers you feel like aggravating & turning off of
your game before they even start...but this is really only an option for
games that are online-specific - you can find wonid's galore for games that
will work for the singleplayer - you just can't play online, that type of
thing...

i'm fairly interested in the new garagegames setup - sounds like an
interesting option - and one that seems targetted towards gamers, as opposed
to some big publisher that doesn't care about annoying half of their game
community (ie tribes 2) - the gg guys have 'been there, done that' as far as
horror releases goes - i'm hoping they have the savvy to avoid duplicating
that ;}

cheers

mike w
www.uber-geek.ca


>Subject: Re: [GD-General] Protecting our game
>

> > > I imagine some easy ways of
> > > handling that, for example, creating a 'secret' file in the system
> > > folder...
> >
> > Do not do that.  You'll only aggravate people that hate programs that
> > litter crap all over their system directories, and there's a good
> > chance that on tightly locked systems you'll trigger a warning/error
> > requiring admin privs.
>
> That is a really good point there. The tech unsavvy potential customer
will
> interpret such a message as meaning that your game is a virus if an
> anti-virus program catches it. That is sure to lose a buyer.

Re: [GD-General] Protecting our game

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

> > I imagine some easy ways of
> > handling that, for example, creating a 'secret' file in the system
> > folder...
>
> Do not do that.  You'll only aggravate people that hate programs that
> litter crap all over their system directories, and there's a good
> chance that on tightly locked systems you'll trigger a warning/error
> requiring admin privs.

That is a really good point there. The tech unsavvy potential customer will
interpret such a message as meaning that your game is a virus if an
anti-virus program catches it. That is sure to lose a buyer.

Re: [GD-General] Protecting our game

[Bob <ma...@mb...>]

brian hook wrote:

> Exactly.  People tend to grossly overestimate the technical
> sophistication of the average user.  There is tendency to project our
> own particular biases and proclivities onto that of the "mass market",
> and this often ends up making developers waste a lot of time.


You are right about that, I admit. But my bias is a similar gripe to
those of the registry entries and hard drive garbage that pops up during
the next trojan hunt. No matter how explicit your description of the
demo functionality, both the pirate and the cracker will jump on
time/execution limited software. For the pirate it's easy warez on
someone else's bandwidth, and for the cracker it is something akin to
fixing an annoying bug (especially when a twelve hour file transfer
offers only one hour or a handful of executions -- RealArcade, anyone?).

For the common demo user intent on stealing, it is no less trouble to go
Google for a ready-made patch/crack than to re-install. And the honest
customer (with impeccable ethics and no technical savvy) will probably
forget about the demo come payday since it was deleted right after it
stopped working.

Re: [GD-General] Protecting our game

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

> well, it depends on how 'casual' you casual player is. In my case I'd 
> think that most casual players have no idea what the registry is, so 
> I should be safe until a someone decides to put a .ref file somewhere.

Exactly.  People tend to grossly overestimate the technical 
sophistication of the average user.  There is tendency to project our 
own particular biases and proclivities onto that of the "mass market", 
and this often ends up making developers waste a lot of time.

The vast, vast majority of users have no idea what a registry is.  In 
fact, most don't even know where files are -- they click on icons.  
This is one reason why so many shareware games put an icon on the 
desktop -- if they don't, the users often can't/won't find it.  Sad, 
but true, and I speak from experience.

> Anyway, I don't think the additional download
> is a good thing. "Register and get the key" seems to be more 
> attractive to me.

This seems to be the consensus I've found with a lot of people.  The 
extra bandwidth really isn't that big a deal compared to a typical 1% 
conversion rate, but it's a hassle for many users to register, then 
click a link to an FTP site, etc. etc.  They'd much rather click, 
register and go.

Brian

Re: [GD-General] Protecting our game

[<cas...@ya...>]

Bob wrote:
> Even 'casual' players can't be trusted not to hack. In my not terribly
> humble opinion, the casual player is probably more inclined to fiddle
> with your files than play the game. In truth, time and usage limited
> demos are hard to resist cracking (ahem... not that I would actually
> admit to... er... ever do something like that).

well, it depends on how 'casual' you casual player is. In my case I'd think
that most casual players have no idea what the registry is, so I should be
safe until a someone decides to put a .ref file somewhere.

Actually, the shareware version of my game is bigger than the complete
version, because it contains the nag-screens. The additional levels of the
complete version do not need additional resources, and the size of the level
data is not significant to make a difference. In fact, the levels are
hardcoded in the executable... Anyway, I don't think the additional download
is a good thing. "Register and get the key" seems to be more attractive to
me.


Ignacio Castaño
cas...@ya...

___________________________________________________
Yahoo! Postales
Felicita las Navidades con las postales más
divertidas desde http://postales.yahoo.es

Re: [GD-General] Protecting our game

[Bob <ma...@mb...>]

Even 'casual' players can't be trusted not to hack. In my not terribly
humble opinion, the casual player is probably more inclined to fiddle
with your files than play the game. In truth, time and usage limited
demos are hard to resist cracking (ahem... not that I would actually
admit to... er... ever do something like that). 

To me it seems that the best method with shareware is the old way;
distributing an infinitely functional version that only includes a
fraction of the resources. This makes your demo version smaller, saving
on bandwidth, and you can add a layer of security by using cgi evaluated
and logged passwords for the full version or additional resource package
download. It won't stop pirates, even coupled with password or other
activation schemes, but it will not challenge otherwise fair-minded
individuals who spent time downloading the demo to crack the time/use
limit.


--Bob



Ignacio Castaño wrote:
> 
> Hell you are right! its targeted towards casual players... sometimes I feel
> a bit paranoid. ;-)
> 
> Thanks for your suggestions!
> 
> Ignacio Castaño
> cas...@ya...
> 
> ___________________________________________________
> Yahoo! Postales
> Felicita las Navidades con las postales más
> divertidas desde http://postales.yahoo.es
> 
> -------------------------------------------------------
> 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] Protecting our game

[<cas...@ya...>]

Hell you are right! its targeted towards casual players... sometimes I feel
a bit paranoid. ;-)

Thanks for your suggestions!


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Postales
Felicita las Navidades con las postales más
divertidas desde http://postales.yahoo.es

Re: [GD-General] Protecting our game

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

On Mon, 30 Dec 2002 01:13:10 +0100
Ignacio Casta=F1o <cas...@ya...> wrote:

> I just don't want people reinstalling it to play 20 games again. I
> imagine some easy ways of handling that, for example, creating a
> 'secret' file in the system folder...
> I'm just wondering if there is a better way of doing that.

Don't do that! Some people, including me, feel very strongly about
programs that leave "stuff" behind. Leaving files in system directori=
es
is a big no-no, but I'd argue that leaving stuff in the registry is a=
lso
something you should avoid.

As Brian said earlier, most people who are interested enough in playi=
ng
it over and over, will do so no matter what, so don't waste your time
and don't piss potential buyers off.

I would suggest changing how you deliver your game so it's not limite=
d
to a certain number of uses or a fixed time. Instead let them play
whatever levels/characters/whatever all they want, and buy the full g=
ame
to get the rest of the content. Problem solved.

If you can't do that, then just letting them know their period has
expired and forcing them to uninstall/reinstall should be enough of a
deterrant for most people.=20

One other possibility is to make your game time-limited for a single
session (like the RollerCoaster Tycoon demo).

Whatever you do, please, be very explicit about about what your demo =
can
and cannot do. I hate downloading something that is supposed to have
unlimited usage just to find out I can only run it for 30 days (I
usually delete it right there without running it a single time when t=
hat
happens).


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

Re: [GD-General] Protecting our game

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

> Well, it's a shareware game distributed through internet. 

Then don't worry too much about people bypassing your stuff.

> I just don't want people reinstalling it to play 20 games again.

Who is your target market?  Savvy gamers?  Or more casual players?  If 
it's casual players, then you can use the registry and very few will 
actually bother trying to figure out what key to reset.

If you're targeting hardcore gamers, then piracy will be rampant no 
matter what you do.  The thing I've learned is that past a certain 
point, you're rapidly hitting diminishing returns and your efforts are 
better spent trying to increase conversion rates than reducing piracy.

> I imagine some easy ways of
> handling that, for example, creating a 'secret' file in the system 
> folder...

Do not do that.  You'll only aggravate people that hate programs that 
litter crap all over their system directories, and there's a good 
chance that on tightly locked systems you'll trigger a warning/error 
requiring admin privs.

Brian

Re: [GD-General] Protecting our game

[<cas...@ya...>]

brian hook wrote:
> > How is this usually solved?
>
> Depends on who you are and what type of guy and how it's distributed.
> If you're a commercial, widely distributed game, then you'll have to
> invest in disc copying protection schemes.  If you're a shareware game,
> then it's not worth your time to do anything but the most basic
> protection.

Well, it's a shareware game distributed through internet. I just don't want
people reinstalling it to play 20 games again. I imagine some easy ways of
handling that, for example, creating a 'secret' file in the system folder...
I'm just wondering if there is a better way of doing that.


Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Postales
Felicita las Navidades con las postales más
divertidas desde http://postales.yahoo.es

Re: [GD-General] Protecting our game

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

> How is this usually solved?

Depends on who you are and what type of guy and how it's distributed.  
If you're a commercial, widely distributed game, then you'll have to 
invest in disc copying protection schemes.  If you're a shareware game, 
then it's not worth your time to do anything but the most basic 
protection.

Brian

[GD-General] Protecting our game

[<cas...@ya...>]

Hi,
I'd like to know how do games usually store the number of times played, the
registration key, and other critical information, that should remain on the
computer if the user decides to uninstall and reinstall the game. The
registry is easy to monitor, you can store the data enchrypted, but removing
the entire key you don't know if the game has just been installed or if the
user has removed it on purpouse. How is this usually solved?

Thanks in advance,


Ignacio Castaño
cas...@ya...

___________________________________________________
Yahoo! Postales
Felicita las Navidades con las postales más
divertidas desde http://postales.yahoo.es

RE: [GD-General] Overhead of RTTI

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

Oh yes sorry, too much vacation for my brain lately :)

To explain, I need this when for example I have a MI class and at a
point I cast it into one of the base classes and at a latter point I
want to cast it into the initial derived class. The current workaround
is to set the base class in which I cast as the first one from which my
dervied class inherits, but is not exactly the right way I believe.

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Mickael Putters
Sent: Friday, December 27, 2002 1:13 AM
To: gam...@li...
Subject: Re: [GD-General] Overhead of RTTI

Hmm I hope you meant reinterpret_cast, otherwise I'd understand why you
need
RTTI in order to make things work.

----- Original Message -----
From: "Adrian Cearn=E3u" <ce...@ce...>
To: <gam...@li...>
Sent: Thursday, December 26, 2002 6:34 PM
Subject: RE: [GD-General] Overhead of RTTI


> Okay, but does any of you know what other overhead will RTTI introduce
> if dynamic_cast will be used strictly when static_cast won't work
(like
> when having to do with MI)? Maybe a structure size overhead, but how
> big?
>
> Thanks,
> Adrian
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Nicolas Romantzoff
> Sent: Tuesday, December 24, 2002 6:47 PM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
>
>
>
> > > 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 =3D Override (the "IS A" relationship).
> Object To Interface inheritance =3D Implementation.
> Interface To Interface inheritance =3D Expansion.
> (of course there is never any Interface To Object inheritance).
>
>
>
> Nicolas
>
>
>
> -------------------------------------------------------
> 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=3D557
>
>
>
>
> -------------------------------------------------------
> 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=3D557
>



-------------------------------------------------------
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_idU7

Re: [GD-General] Overhead of RTTI

[Mickael P. <gd...@dr...>]

Hmm I hope you meant reinterpret_cast, otherwise I'd understand why you n=
eed
RTTI in order to make things work.

----- Original Message -----
From: "Adrian Cearn=E3u" <ce...@ce...>
To: <gam...@li...>
Sent: Thursday, December 26, 2002 6:34 PM
Subject: RE: [GD-General] Overhead of RTTI


> Okay, but does any of you know what other overhead will RTTI introduce
> if dynamic_cast will be used strictly when static_cast won't work (like
> when having to do with MI)? Maybe a structure size overhead, but how
> big?
>
> Thanks,
> Adrian
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Nicolas Romantzoff
> Sent: Tuesday, December 24, 2002 6:47 PM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
>
>
>
> > > 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 =3D Override (the "IS A" relationship).
> Object To Interface inheritance =3D Implementation.
> Interface To Interface inheritance =3D Expansion.
> (of course there is never any Interface To Object inheritance).
>
>
>
> Nicolas
>
>
>
> -------------------------------------------------------
> 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=3D557
>
>
>
>
> -------------------------------------------------------
> 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=3D557
>

RE: [GD-General] Overhead of RTTI

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

Okay, but does any of you know what other overhead will RTTI introduce
if dynamic_cast will be used strictly when static_cast won't work (like
when having to do with MI)? Maybe a structure size overhead, but how
big?

Thanks,
Adrian

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Nicolas Romantzoff
Sent: Tuesday, December 24, 2002 6:47 PM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI



> > 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



-------------------------------------------------------
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 !

Of course, I meant exTend (extension, extending, ...). My english has
gone away with xmas... :)


Nicolas.


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Idahosa I. O. Edokpayi
> Sent: Thursday, December 26, 2002 7:42 AM
> To: gam...@li...
> Subject: RE: [GD-General] Overhead of RTTI
> 
> 
> What do you mean by the term expend? I thought I understood 
> the word but obviously no in the context you use here.
> 
> Idahosa Edokpayi
> O2Cool Games Software
> 
> 

RE: [GD-General] Overhead of RTTI

[Idahosa I. O. E. <ida...@sw...>]

What do you mean by the term expend? I thought I understood the word but
obviously no in the context you use here.

Idahosa Edokpayi
O2Cool Games Software


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Nicolas Romantzoff
Sent: Tuesday, December 24, 2002 8:31 AM
To: gam...@li...
Subject: RE: [GD-General] Overhead of RTTI

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.



-------------------------------------------------------
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