gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Collecting info from players

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

On Thu, 10 Jul 2003 20:18:06 +0300
Ivan-Assen Ivanov <as...@ha...> wrote:

> Do we design the system to cater to the preferences of
> a small, vocal minority, severely reducing its utility in
> the process?

Clearly it depends on the program (whether it's online only or not),
your audience, and the type of information. However, I would also advice
against sending any information without the player first approving it. 

I have downloaded many programs/demos in the past that during the
installation or as the first thing they did when I ran them was to try
to access the internet. My firewall caught that, I denied the access,
and promptly uninstalled the program and decided not to purchase it.

For what it's worth, I know of many people who feel this same way, or
even much more strongly, so it's not such a small, vocal minority as you
might think.


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

RE: [GD-General] Collecting info from players

[<ma...@ch...>]

On Thu, 10 Jul 2003, Ivan-Assen Ivanov wrote:

> I agree that there should be a way to turn the system off,
> but any visible mentions of it, and especially defaulting to "no",
> will reduce greatly the number of submitted reports.

And? That simply means that you wont be able to take the data they would 
have provided into consideration... So, if people wish for you to cater 
for their pattern of usage/hardware platform/whatever, they can enable it. 

So, if I wish for you to know that I am running Linux, I will say, OK, 
give this information away, because that may improve the Linux support. If 
I do not care, thats just my fault/problem.

Its funny - you/we would never think of _demanding_ that people submit
information about themselves to _buy_ your game, but just because it is
technically feasible to automatically collect this kind of information, 
you/we whip up all kind of arguments for it to be the default behaviour. 

I do not like that kind of rationale.

Of course, I am one of those guys that does run a privacy/no ads proxy.

Mads

P.S. Please understand that there is nothing personal in this post - I am 
a bit uncertain on how to express this in english but I am not trying to 
flame anyone.

-- 
Mads Bondo Dydensborg.                               ma...@ch...
If you're a command-line user (that is, someone who knows how to read and
type, rather than a 2-year-old who knows only how to point), Linux is potent, 
flexible and totally accessible. And if you must point, Linux offers X-windows.
                                - Ed Quillen, Denver post.

RE: [GD-General] Collecting info from players

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

> Most privacy-conscious users will have a firewall, 
> and if you try to sneak info out of them before they can 
> override the option, they will know, they won't like it, and 
> you won't get the info anyway.

OK, so basically the problem turns into the following:

Do we design the system to cater to the preferences of
a small, vocal minority, severely reducing its utility in
the process?

I'm sure "privacy-conscious users" won't like the simple
hitting of a static URL by our current system.
(by the way: we don't provide a way to turn it off. 
We haven't heard a single complaint about it.
Maybe if our game was a major hit we would have heard
more than one. But we have tens of thousands of
unique IPs hitting that URL, and no hate mail. Google
doesn't find any mentions of it by third parties.)

The argument "but everyone's doing it anyway, why shouldn't we"
is of dubious quality when judging questions of ethical origin,
and so is the argument "but we're doing it to provide better
games for our users".

I agree that there should be a way to turn the system off,
but any visible mentions of it, and especially defaulting to "no",
will reduce greatly the number of submitted reports.
Users have been scared to death by the press about
Big Brother Microsoft, and frankly, I'm not sure that a text such
as "No information except some technical data about your
computer configuration" would be understood by the majority
of users.

Wait, here's a solution. Maybe place in each outgoing packet the text:
"Okay smartass, you got us. Edit config.ini in your game folder and
add the text 'UserType=Paranoid' to turn this off." :-)

RE: [GD-General] Collecting info from players

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

> I belive the Epic data is sent automatically along with the 
> CD key-checking stuff.

Correct.

I wish we kept track of more than OS/ platform used to connect to the
master server though we opted against it for privacy reasons.

-- Daniel, Epic Games Inc.

Re: [GD-General] Collecting info from players

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

Ivan Galic wrote:

> And when they try to turn it off, show them some
> kind of confirmation dialog with an explanation that sending such
> information to you doesn't invade their privacy, and helps you
> deliver them better games, etc.

I don't know about you, but the more I am told it is ok, the more annoyed
and suspicius I grow. I suggest you put a privacy statement hyperlink
control right next to the checkbox, but don't tell the user that he's making
a dumb choice when he unchecks the option.

Another thing to be careful about is to ensure that no data is sent before
the user has had the chance to turn off that option. Most privacy-conscious
users will have a firewall, and if you try to sneak info out of them before
they can override the option, they will know, they won't like it, and you
won't get the info anyway.

  Javier Arevalo
  Pyro Studios

Re: [GD-General] Collecting info from players

[Ivan G. <dea...@ga...>]

> I would _not_ encrypt this data (unless it's a bandwidth hit), and happily
> tell them exactly what data you report. Don't _ask_, because by reflex
> people say no, which defeats the whole point, but do give them the option
to
> turn it off if they can bothered to find the option.

I agree with this. Simply turn it on by default, and leave the option to
disable it if the user wants to. Also, give some kind of privacy statement,
in which you guarantee that no personal information will be sent, blah...
And when they try to turn it off, show them some kind of confirmation dialog
with an explanation that sending such information to you doesn't invade
their privacy, and helps you deliver them better games, etc.

-Ivan

RE: [GD-General] Collecting info from players

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

I would _not_ encrypt this data (unless it's a bandwidth hit), and happily
tell them exactly what data you report. Don't _ask_, because by reflex
people say no, which defeats the whole point, but do give them the option to
turn it off if they can bothered to find the option.

So people can disable it if they like, and they can inspect the data
themselves - none of it is particularly privacy-invading, and it's certainly
nothing that playing any other online game (CS, Quake, etc) doesn't reveal.

I belive the Epic data is sent automatically along with the CD key-checking
stuff. Data very similar to what you want to collect is collected and sent
by HalfLife - I think that data has been posted before or is on Valve's
website somewhere. So far, no reports of mobs with blazing pitchforks have
been reported. :-)


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: Ivan-Assen Ivanov [mailto:as...@ha...]
> Sent: 10 July 2003 11:53
> To: gam...@li...
> Subject: [GD-General] Collecting info from players
> 
> 
> Here's an Internet ethics question for you. I don't really
> expect to hear a definite answer, more like gather some
> of your thoughts.
> 
> What info about the player is appropriate for the game to report to a
> central server?
> 
> There are privacy junkies who would be outraged by the
> question itself. These are the people who browse through anonymizers
> when they read online comics and daily news.
> 
> So their answer is "None" and they would happily flame us, threat to
> boycott us and report us to slashdot. (hey, free publicity!)
> 
> Our previous title has an update notification system which fetches an
> XML file from our webserver once every three days and 
> notifies the user
> of patches, maps etc.
> This reports to us only the users' IPs. Indirectly, you can translate
> this to country code, e.g. by MaxMind's excellent free GeoIP database.
> 
> We are considering collecting some info from the users' 
> machine, but we
> are somewhat hesitant. What do you think about the following items:
> 
> - a unique machine ID, so we can differentiate hits from users behind
> firewalls/NATs/whatever
> 
> - hardware and OS details - memory, CPU, videocard, version
> of Windows, DirectX and drivers
> (Daniel Vogel of Epic recently reported such info on this 
> list - how was
> it obtained? Was your office torched by a mob of privacy advocates?)
> 
> - statistics about how much the game is played - average session, max
> session, frequency of running the game etc.
> 
> This info can be packed to a 10-15 digits and letters and 
> e.g. added to
> the URL request, and later extracted from the web server 
> logfiles. Or it
> can be steganographically hidden in clever ways - but do we need to?
> 
> I'm sure Microsoft can't get away with anything like this without
> creating a major brouhaha, but first, we aren't as well known 
> and hated
> as Microsoft, and second, see the publicity remark.
> 
> What are your thoughts on this? What are you doing currently? 
> Or maybe we should take this discussion to a closed forum ;-)
> 
> regards,
> Assen
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps
> _______________________________________________
> 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] Collecting info from players

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

Here's an Internet ethics question for you. I don't really
expect to hear a definite answer, more like gather some
of your thoughts.

What info about the player is appropriate for the game to report to a
central server?

There are privacy junkies who would be outraged by the
question itself. These are the people who browse through anonymizers
when they read online comics and daily news.

So their answer is "None" and they would happily flame us, threat to
boycott us and report us to slashdot. (hey, free publicity!)

Our previous title has an update notification system which fetches an
XML file from our webserver once every three days and notifies the user
of patches, maps etc.
This reports to us only the users' IPs. Indirectly, you can translate
this to country code, e.g. by MaxMind's excellent free GeoIP database.

We are considering collecting some info from the users' machine, but we
are somewhat hesitant. What do you think about the following items:

- a unique machine ID, so we can differentiate hits from users behind
firewalls/NATs/whatever

- hardware and OS details - memory, CPU, videocard, version
of Windows, DirectX and drivers
(Daniel Vogel of Epic recently reported such info on this list - how was
it obtained? Was your office torched by a mob of privacy advocates?)

- statistics about how much the game is played - average session, max
session, frequency of running the game etc.

This info can be packed to a 10-15 digits and letters and e.g. added to
the URL request, and later extracted from the web server logfiles. Or it
can be steganographically hidden in clever ways - but do we need to?

I'm sure Microsoft can't get away with anything like this without
creating a major brouhaha, but first, we aren't as well known and hated
as Microsoft, and second, see the publicity remark.

What are your thoughts on this? What are you doing currently? 
Or maybe we should take this discussion to a closed forum ;-)

regards,
Assen

Re: Re[2]: [GD-General] profiling with CodeAnalyst

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

>> Pssssst! Careful about sharing such optimization techniques on a
>> public forum! You know they are listening! They are everywhere!!

If only "they" would answer your question!  :-(

...or is this all a ruse to get me to divulge the location
of the secret rebel base?  Well, okay, but I want to be rich,
with lots of chicks.  Taking the red pill was just a big 
mistake.  Oh, and I want a 2000 SUX with really bad gas milage!
The ashtray, the remote control, the paddle game, this magazine
and the chair...That's all I need!  And a Pepsi!  Just one Pepsi...
I'm not crazy! (Institutionalized!) You're the one who's crazy!
(Institutionalized!)  You're driving me crazy!  (Institutionalized!)
etc, etc.

Re[2]: [GD-General] profiling with CodeAnalyst

[Andras B. <bn...@ma...>]

Pssssst! Careful about sharing such optimization techniques on a
public forum! You know they are listening! They are everywhere!!

:))))))


b

Saturday, July 05, 2003, 1:12:02 PM, Colin Fahey wrote:

>   > Hi, I'm new to profiling [...]

>   > Running the timer-based profiling on my app says:
>   [...]

>   > And of course the only thing I see in the hotspot view
>   > is one fat bar called <unknown>.exe, which is supposed
>   > to be my app...

> So...just optimize <unknown>.exe and your app will really smoke!
> Maybe you could even eliminate it and check the figures.
> If you told your supervisor that you produced a 4000000%
> increase in speed, I don't think he or she will care that
> it meant sacrificing, uh, ALL features -- but bugs too!
> I once heard or read that an ongoing assessment of whether
> or not a project is worth finishing should be part of the
> software development process.

> Maybe an ongoing assessment of whether or not this joke
> was funny should be part of my e-mail process!  ;^)

> --- Colin

> cp...@ea...

Re: [GD-General] profiling with CodeAnalyst

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

  > Hi, I'm new to profiling [...]

  > Running the timer-based profiling on my app says:
  [...]

  > And of course the only thing I see in the hotspot view
  > is one fat bar called <unknown>.exe, which is supposed
  > to be my app...

So...just optimize <unknown>.exe and your app will really smoke!
Maybe you could even eliminate it and check the figures.
If you told your supervisor that you produced a 4000000% 
increase in speed, I don't think he or she will care that
it meant sacrificing, uh, ALL features -- but bugs too!
I once heard or read that an ongoing assessment of whether
or not a project is worth finishing should be part of the
software development process.

Maybe an ongoing assessment of whether or not this joke
was funny should be part of my e-mail process!  ;^)

--- Colin

cp...@ea...

[GD-General] profiling with CodeAnalyst

[Andras B. <bn...@ma...>]

Hi, I'm new to profiling, and I just wanted to try out AMD's
CodeAnalyst, but have got some problems. I've already read the
troubleshooting sections in the help, but find nothing helpful.
I've also asked AMD's CodeAnalyst's support team, but got no
answer... So I've decided to ask the list, as my last chance :)

Running the timer-based profiling on my app says:

Using device driver CAPROF version 1.01 build 3
Process launched.  ID is 00000564
Warning:  Can't identify EXE module being loaded
New Process <unknown>.EXE loaded at 0x00400000;  ID is 00000564
Load DLL      ntdll.dll at 0x77F50000 in process 00000564
Load DLL   kernel32.dll at 0x77E60000 in process 00000564
Load DLL      DDRAW.dll at 0x51000000 in process 00000564
Load DLL     msvcrt.dll at 0x77C10000 in process 00000564
Load DLL     USER32.dll at 0x77D40000 in process 00000564
Load DLL      GDI32.dll at 0x77C70000 in process 00000564
Load DLL   ADVAPI32.dll at 0x77DD0000 in process 00000564
Load DLL     RPCRT4.dll at 0x77CC0000 in process 00000564
Load DLL   DCIMAN32.dll at 0x73BC0000 in process 00000564
Load DLL    MSVCR70.dll at 0x7C000000 in process 00000564
Process 00000564 started.
Load DLL      MSCTF.dll at 0x74720000 in process 00000564
Load DLL   OLEAUT32.DLL at 0x77120000 in process 00000564
Load DLL      OLE32.DLL at 0x771B0000 in process 00000564
Process 00000564 ended
All Debuggee Processes Have Terminated.

And of course the only thing I see in the hotspot view is one fat bar
called <unknown>.exe, which is supposed to be my app...

What's the problem? I've used the VC7 compiler to generate the .exe
and the corresponding .pdb file. I can see the source code in EIP
view, so it must be okay. 

I guess it must be something very trivial...

Thanks,

Bandi

Re: [GD-General] quaternion conversion

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

Hi Colin,

Yes, I think so. And that explains the strange results. The flipping was
more or less done out of 'I did not know what to do' :)
The problem is that our rendering system and scenegraph is left-handed while
a sensor connected to my PC is outputting quaternions in right-handed
space.....
I'll try the hack with the matrices.

Thanks, Chris

----- Original Message ----- 
From: "Colin Fahey" <cp...@ea...>
To: <gam...@li...>
Sent: Wednesday, July 02, 2003 8:00 PM
Subject: Re: [GD-General] quaternion conversion


>
> By "flipping the sign of the x-coordinate" do you mean you
> are doing the following:
>
>     q = ( x, y, z, w )
>
>   -->  ( n; theta ) = ( nx, ny, nz; theta )
>
>   --> ( n'; theta ) = ( -nx, ny, nz; theta ) ?
>
> Flipping the x-component normal vector (the "axis" part of
> axis-angle) is not the same as flipping the x-coordinate of
> points transformed by that quarternion.
>
> One temporary hack experiment is to convert the quaternion
> to a matrix, invert the sign of elements in the row that
> yields the x-coordinate ( i.e., x = r31 * x + r32 * y + r33 * z
> ==> Invert to:  (-r31), (-r32), (-r33) ).
>
> Basically, I think you have to postpone switching to a
> left-handed coordinate system until you are finished doing
> your calculations.  You cannot, for example, benefit from
> taking the modified matrix described in the previous
> paragraph and converting it back to a right-handed
> quaternion; it's meaning would be perverse and useless.
>
>
> OFF-TOPIC:
>
> D3D had more than five years to switch to a right-handed
> coordinate system.  Isn't there an incentive to do so, to
> coincide with conventional right-handed cross-products,
> quaternions, and all the mathematical results based on
> such things?  Doesn't anyone complain?  If as many
> textbooks on D3D point out "It is easy to switch to a
> right-handed coordinate system by changing the transformation
> matrix", why not simply change the default to a right-handed
> system?
>
>
> --- Colin
>
>
> ----- Original Message -----
> From: "Chris Haarmeijer" <c.h...@ke...>
> To: "gdgeneral" <gam...@li...>
> Sent: Wednesday, July 02, 2003 2:16 AM
> Subject: [GD-General] quaternion conversion
>
>
> Hi,
>
> I've got an incoming quaternion from a sensor. This sensor has a
coordinate system that is right-handed. Our rendering system is
> based on a left-handed system. I've tried converting the quaternion to
Axis-Angle and then flipping the sign of the
> x-coordinate, but that produces strange results.
>
> Anyone knows an answer or hint to this problem?
>
> Chris
>
> ---
> Keep IT Simple Software
> Van Alphenstraat 12
> 7514 DD Enschede
>
> W: http://www.keepitsimple.nl
> E: mailto:in...@ke...
> T: +31 53 4356687
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> 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] quaternion conversion

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

By "flipping the sign of the x-coordinate" do you mean you
are doing the following:

    q = ( x, y, z, w )

  -->  ( n; theta ) = ( nx, ny, nz; theta )

  --> ( n'; theta ) = ( -nx, ny, nz; theta ) ?

Flipping the x-component normal vector (the "axis" part of
axis-angle) is not the same as flipping the x-coordinate of
points transformed by that quarternion.

One temporary hack experiment is to convert the quaternion
to a matrix, invert the sign of elements in the row that
yields the x-coordinate ( i.e., x = r31 * x + r32 * y + r33 * z
==> Invert to:  (-r31), (-r32), (-r33) ).

Basically, I think you have to postpone switching to a
left-handed coordinate system until you are finished doing
your calculations.  You cannot, for example, benefit from
taking the modified matrix described in the previous
paragraph and converting it back to a right-handed
quaternion; it's meaning would be perverse and useless.


OFF-TOPIC:

D3D had more than five years to switch to a right-handed
coordinate system.  Isn't there an incentive to do so, to
coincide with conventional right-handed cross-products,
quaternions, and all the mathematical results based on
such things?  Doesn't anyone complain?  If as many
textbooks on D3D point out "It is easy to switch to a
right-handed coordinate system by changing the transformation
matrix", why not simply change the default to a right-handed
system?


--- Colin


----- Original Message -----
From: "Chris Haarmeijer" <c.h...@ke...>
To: "gdgeneral" <gam...@li...>
Sent: Wednesday, July 02, 2003 2:16 AM
Subject: [GD-General] quaternion conversion


Hi,

I've got an incoming quaternion from a sensor. This sensor has a coordinate system that is right-handed. Our rendering system is
based on a left-handed system. I've tried converting the quaternion to Axis-Angle and then flipping the sign of the
x-coordinate, but that produces strange results.

Anyone knows an answer or hint to this problem?

Chris

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

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

[GD-General] quaternion conversion

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

Hi,

I've got an incoming quaternion from a sensor. This sensor has a =
coordinate system that is right-handed. Our rendering system is based on =
a left-handed system. I've tried converting the quaternion to Axis-Angle =
and then flipping the sign of the x-coordinate, but that produces =
strange results.

Anyone knows an answer or hint to this problem?

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] meaning of sizeof(int) on all plateform

[J C L. <cl...@ka...>]

On Fri, 27 Jun 2003 16:52:01 -0700
Jay Woodward <woo...@Ro...> wrote:

> Hold on -- it seems to me that the existence of forward declaration
> necessitates that all pointers be the same size.

Nope.  ANSI doesn't require it.  It merely requires that a void* be able
to store a pointer of any other type, and that a void* can be converted
to a pointer of any other type without loss (and get the proper
address).  Now as to how the compiler accomplishes this is of course
part of that undefined black magic which is left up to compiler authors.

  ObNote: I've worked on platforms where different pointer types had
  different sizes and the compilers handled it just fine.

> I suppose you wouldn't lose information when casting, as long as it's
> guaranteed that sizeof(void*) >= sizeof(any other pointer).  Still, my
> understanding has always been that all pointers are the same size.

Even that's not required.  You're assuming a flat memory model and that
pointers are basically integral types.  This is not required and is in
fact not true on several platforms where pointers are variously complex
structures.

The real kickers are those systems where:

  type_foo *ptr1, *ptr2;
  ...code that messes with ptr1 and ptr2...
  if (memcmp (ptr1, ptr2, sizeof (ptr1))) {
      printf ("memcmp comparison failed!\n");
  }
  if (ptr1 == tr2) {
    printf ("pointer comparison succeeded!\n");
  }

On some hosts you can get cases where both printf() calls will be
executed.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] meaning of sizeof(int) on all plateform

[J C L. <cl...@ka...>]

On Thu, 26 Jun 2003 15:24:45 -0700 
Evan Robinson <ev...@en...> wrote:

> If you are trying to make sure that your code will run equally
> efficiently on *all platforms* and *all compilers*, you are
> (probably=20 wasting your time) probably best off relying on "int" and
> "void *" and not worrying about how they match to the platform until
> you have a=20 specific platform and compiler combination in mind.

If you are going that route, also make sure that you're not assuming
that the local system has a flat memory model, that pointers are simple
integral types, that two pointers which have different internal
bit-patterns are necessarily unequal (they can be), that the comparison
of two pointers not from the same allocation buffer is valid (its not),
and that NULL is all bits zero at run time (it may not be).

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] meaning of sizeof(int) on all plateform

[J C L. <cl...@ka...>]

On Thu, 26 Jun 2003 22:12:52 +0200 
iso  <iso-8859-1> wrote:

> another question, is sizeof(int) =3D=3D sizeof(void*) ?  sizeof(void*)
> must be : size of memory bus address so sizeof(int)....

No.  There's no requirement for pointers to be integral types, and in
fact on several platforms pointers are variously complex structures and
not integral at all.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] meaning of sizeof(int) on all plateform

[J C L. <cl...@ka...>]

On Thu, 26 Jun 2003 15:12:48 -0700 
Chris Jones <Jones> wrote:

> This is all the standard has to say on the size of ints: "There are
> four signed integer types: "signed char", "short int", "int", and
> "long int." In this list, each type provides at least as much storage
> as those preceding it in the list. Plain ints have the natural size
> suggested by the architecture of the execution environment (1); the
> other signed integer types are provided to meet special needs."

Precisely.  This is why on Crays there's a compilation environment
where:

  sizeof(char) == sizeof(short) == sizeof(int) == sizeof(long)
  == sizeof(void*) == 1

Note also that ANSI doesn't require bytes to be 8bits.  In the above
case bytes are 64bits.

> In other words, the result of sizeof(int) is never guaranteed to be of
> a certain size.  Although I believe the ISO C99 standard added new
> header file, stdint.h, which declares some typedefs for specific sized
> integer types.  If only more compilers would follow the standards...

Yeah.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] OS usage statistics

[Ivan G. <dea...@ga...>]

Thanks for the info! 

I'm very happy with the fact that most clients use WinXP :)))

-------------------------------------------------
Leave all your expectations behind, or
they'll pull you down on your way to the top.
-------------------------------------------------
-Ivan

[GD-General] Re: meaning of sizeof(int) on all plateform

[Enno R. <en...@de...>]

Jay Woodward wrote:

> Hold on -- it seems to me that the existence of forward declaration necessitates that all pointers be the same size.
> 
> I suppose you wouldn't lose information when casting, as long as it's guaranteed that sizeof(void*) >= sizeof(any other pointer).  Still, my understanding has always been that all pointers are the same size.

Life would be so nice if we had some guarantees like that.

The only thing that I know you have a guarantee for is that void* and char* 
are compatible, and it's necessary that pointers to structs can be cast 
between each other. However, on several architectures function pointers will 
be of a different size than data pointers.

On a Cray, if I remember this correctly, both void* and char* are 64 bits, 
but all other pointers are only represented using 32 bits. And you can 
choose to have ints represented with only 46 instead of the full 64 bits!

Enno.
-- 
<xterm> The problem with America is stupidity. I'm not saying there should
      be a capital punishment for stupidity, but why don't we just take
      the safety labels off of everything and let the problem solve itself?

RE: [GD-General] meaning of sizeof(int) on all plateform

[Phil T. <ph...@mi...>]

Actually pointer to member functions throw a wrench into this =
discussion, specifically when forward declaring classes.  There was a =
thread on this in the software engineering list.
=20
The example given was this:
=20
class C;
int (C::*pmf)();
C* p;
=20
int n =3D (p->*pmf)();
=20
Note that the full declaration of the class C is not required for this =
code to compile; however, the member function could be virtual/multiply =
inherited/etc so the pointer has to encode this information.
=20
On Win32 some compilers will generate this as a 16 byte pointer; others, =
will generate stub code and return a pointer to that code which is then =
a 4 byte pointer.  VC 7 has some compiler options that let you choose =
the behavior.
=20
The point being that there are things that look like pointers but that =
aren't the same size as other native pointers.
=20
Phil
=20

________________________________

From: gam...@li... on behalf of =
Daniel Vogel
Sent: Sat 28.06.2003 12:54
To: gam...@li...
Subject: RE: [GD-General] meaning of sizeof(int) on all plateform



> I state that sizeof(T*) is the same, whatever T might be. Am I wrong?

I'm not aware of any implementation where this is not the case though
the standard doesn't guarantee it.

-- Daniel, Epic Games Inc.



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
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] meaning of sizeof(int) on all plateform

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

It is wrong to assume that all pointers are the same size, even on 
"normal" architectures.  Pointers to class members are not required to 
be sizeof(void *), and in the case of virtual inheritance, probably 
aren't. 

This program:

    // Compile under VC++ with "cl /ML /GX test.cpp"

    #include <iostream>
    using namespace std;

    struct Base
    {
    };

    struct Derived : public virtual Base
    {
    };

    typedef void (Base::*BasePtrToMember)();
    typedef void (Derived::*DerivedPtrToMember)();

    int main(int argc, char **argv)
    {
    cout << "sizeof(BasePtrToMember) " << sizeof(BasePtrToMember) << endl;
    cout << "sizeof(DerivedPtrToMember) " << sizeof(DerivedPtrToMember) 
<< endl;

    return 1;
    }

Produces the following output:

    sizeof(BasePtrToMember) 4
    sizeof(DerivedPtrToMember) 12

There you go, a 12 byte pointer on Win32.  You can imagine that this 
causes brain-bending bugs for the unwary :)

--brian

Jay Woodward wrote:

>Hold on -- it seems to me that the existence of forward declaration necessitates that all pointers be the same size.
>
>I suppose you wouldn't lose information when casting, as long as it's guaranteed that sizeof(void*) >= sizeof(any other pointer).  Still, my understanding has always been that all pointers are the same size.
> 
>
>  
>
>>-----Original Message-----
>>From: Gareth Lewin [mailto:GL...@cl...]
>>Sent: Friday, June 27, 2003 1:45 AM
>>To: gam...@li...
>>Subject: RE: [GD-General] meaning of sizeof(int) on all plateform
>>
>>
>>btw, sizeof(pointer) isn't a real value, it is perfectly 
>>valid for a certain
>>platform to have differant sizes of pointers, so sizeof (void*) is not
>>always == sizeof(int*).
>>    
>>

Re: [GD-General] meaning of sizeof(int) on all plateform

[Bo-Staffan L. <bo-...@gb...>]

> I'm not aware of any implementation where this is not the case though
> the standard doesn't guarantee it.

It depends on the CPU architecture. The smallest addressable unit in the C++
memory model is the byte. The number of bits in a C++ byte is
implementation-specific, but to be compatible with C, it must contain
atleast 8 bits. Typically, if the size of a built in type is smaller than
the smallest addressable unit of the CPU, the CPU-byte, the implementation
must include an offset, in conjunction with the CPU-byte address, to be able
to address the C++ byte within the CPU-byte.

Bo-Staffan

Re: [GD-General] OS usage statistics

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

Here are the stats that Daniel provided earlier this year as well.

There are more Win98/ME machines than Win2K machines.  But it looks like
users are moving away from Win98/ME to XP.

On Fri, 2003-06-27 at 20:01, Daniel Vogel wrote:

> Dedicated servers currently online (absolute numbers).
>=20
> Linux/x86          925  --> 43.04%
> Win2K              859  --> 39.97%
> Win98/WinME         28  -->  1.30%=20
> WinNT               38  -->  1.76%
> WinXP              299  --> 13.91%
>=20
> Last OS used for unique clients connecting to masterserver
> (percentages).
>=20
> Linux/x86         0.73
> Win2K            10.70
> Win98/WinME      15.35
> WinNT             0.01
> WinXP            73.19

On Sat, 2003-01-04 at 13:09, Daniel Vogel wrote:

> UT 2003           Client      Server
>=20
> 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 %