gdalgorithms-list

RE: [Algorithms] rather curious

[Akbar A. <sye...@ea...>]

>where is a good place or a good book to get started with physics?
here i will lay this out in stages, i am sure a lot of people can offer some
advice.

check out André lamothes' newest book, chapter 13 is well worth a read.
like always, he gives a good intro and finishes off with some good old
simple kinematics (demos included, not just text and a code blips like most
texts) he also tries to keep calculus at a down low most of the time.

after that you might want to look into
Thomas/Finney edition 9
Calculus
published by Addison Wesley (www.awl.com)
ISBN = 0-201-53174-7

check out Chapter 9 and Chapter 11. you really want to parameterize all your
objects. helps with keeping bandwidth at an all time low and predication
issues.

chris hecker has written some *very good* stuff and has "demos" on his site.
www.d6.com
he gives some good books as well.

jeff lander has also written some good articles on physics, as well as
demos.
you should check out archived issues of gdmag.
www.gdmag.com


you should also check out this book as well ( i am not sure if it's
available *everywhere*, got at it at ut, one of those *ut* books i suppose?)

Dynamics (Engineering Mechanics)by: Anthony Bedford, Wallance Fowler

your best bet to really understanding this is "learn" the fundamentals
really well. pull out some paper, work out the problems, make fake problems,
then do them again, and again. repeat till get sleepy. then write code...
goto starbucks write more code..
pass out :)

imho in general you should get really good at integrals, your going to get
sick of them after a while though, but later on when you have to
implement/reading some algo it will help you out..


peace,
akbar A.







-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Joe
Silver
Sent: Sunday, September 10, 2000 8:30 PM
To: gda...@li...
Subject: Re: [Algorithms] rather curious


Not that I have anything to add to this conversation..  but I did want to
ask.. where is a good place or a good book to get started with physics?  my
physics knowledge is pretty low..

-Joe

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] rather curious

[Akbar A. <sye...@ea...>]

>The reason people don't know a lot about relativistic physics is they have
>trouble with Galileo let alone Einstein.
i don't want to sound stupid (being that i have not had *any* experience
with Einstein's work) but wasn't most of his stuff, derived from material
which was pretty trivial?


>No one believed us that the objects hit at basically the same time
regardless >of mass.  So we all started dropping stuff on the table to prove
it.
>Pretty funny.
been there, done that :)

well you can always look at it and explain to other people that' it's a
formula and you are just putting in data which has a very *large* gap.
the precision is small but the difference is *still* there, so in all of
it's actuality they *don't* fall at the same rate :)
just cause we can't see it, doesn't mean it doesn't exsist ;)

imho, it must of been a pain in the ass to convince people that we/objects
are "attracted" to each other ;)


>The whole what is gravity thing is pretty tough.  Claiming to have the
>"right" answer is probably folly.
aren't researchers still clamoring about a "true/right way" to describe
light and all it's properties;
"wait a second it's a wave, oh No it's a particle!" (i will stop this, i'm
going on a tangent ;)
<grin>

>Using Newton's equations for the force of gravity and f=ma
the mind is so weird.
maybe i saw this in a dream or something but wasn't it first published as
-f = -ma
?

>Didn't they do the feather and rock demo on an Apollo mission as a pr
thing?  >I seem to remember seeing a video of it.

do we even have video capture devices that are that accurate to get the
10^-24 precision, so we could "see" the diff?


anyways,
i think i got some reading to do about this topic so i can argue with a
better foot hold.
i hope this book does the trick, just put the order in.
http://www.amazon.com/exec/obidos/ASIN/0517029618/o/qid=968634459/sr=2-1/102
-7947677-2983366



peace,
akbar A.

being in the game biz, we actually *apply* all these fancy equations most
people just memorize for the midterm and forget about.




-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Jeff
Lander
Sent: Sunday, September 10, 2000 6:37 PM
To: gda...@li...
Subject: Re: [Algorithms] rather curious


The reason people don't know a lot about relativistic physics is they have
trouble with Galileo let alone Einstein.

Funny this should come up today since last night we got into a little debate
about this at dinner with some friends.  My friend works at JPL and we were
talking about skydiving and this came up.  No one believed us that the
objects hit at basically the same time regardless of mass.  So we all
started dropping stuff on the table to prove it.  Pretty funny.  It is
always amazing how a simple "try it yourself" can surprise people.  In
general they just believe it should be some way and never check it out.  No
wonder Galileo ended up in jail.

The whole what is gravity thing is pretty tough.  Claiming to have the
"right" answer is probably folly.  Clearly Galileo/Newton works fine for
most applications any human would run into.  I am no expert on gravitational
physics but from what I know, common thinking is based  on  Einstein's
theory of General relativity.  The mass of objects warp spacetime and the
falling is explained by objects following a straight path in space-time.

Galileo went to great pains to prove that Aristotle and Plato were wrong
about falling objects.  If he wasn't exactly right to the order of 10^-24 or
whatever, I am not sure it matters.  At JPL, good old Newton does the job
for most things.

Using Newton's equations for the force of gravity and f=ma you can see how
the mass of the falling object just drops out.  Different masses do cause
the objects to hit with different forces but that is different from the
time, eh.

If someone wants to implement actual relativistic physics for simple rigid
body simulations, I am sure it would be cool, but Newton is good enough for
me :)

Didn't they do the feather and rock demo on an Apollo mission as a pr thing?
I seem to remember seeing a video of it.

-Jeff

At 04:26 PM 9/10/2000 -0500, you wrote:
>hey,
>i am just wondering, but how many people know about *this*
>"gravity isn't really a force" and that it is caused by the curvature in
the
>space time fabric.
>
>And, if you drop two objects in a vacuum they *really* don't fall
>at the same rate (difference is very small, order of 10^-24) <this *makes
>sense*>
>why don't more people know this?
>
>even if it's at a difference 10^-24,
>i assure you, if we had money that was this accurate, banks would "require"
>this much precision in there software :|
>
>i am just curious what is the *the few on this list*  knowledge about
>this...
>
>i recently (3 minutes ago) got in an argument with a friend on this
*topic*,
>he told me his professor said that "Gravity is a FORCE" and saying anything
>different from that is pure anarchy.
>
>i told him what is above is true and André Lamothe writes this in all of
his
>books, and i'm pretty sure he knows more than your professor (the laws make
>sense as well), ...
>
>
>
>i am probably just t-ed of cause i didn't have more proof about the space
>time fabric one :|
>
>
>btw, andre, if your not on the list;
>i highly suggest you join :) i know your busy with volume 2 and all...
>
>peace,
>akbar A.
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] rather curious

[Joe S. <jo...@ax...>]

Not that I have anything to add to this conversation..  but I did want to
ask.. where is a good place or a good book to get started with physics?  my
physics knowledge is pretty low..

-Joe

Re: [Algorithms] rather curious

[Eric L. <le...@C4...>]

> i am just wondering, but how many people know about *this* "gravity isn't
> really a force" and that it is caused by the curvature in the space time
> fabric.
> 
> And, if you drop two objects in a vacuum they *really* don't fall at the same
> rate (difference is very small, order of 10^-24) <this *makes sense*> why
> don't more people know this?
> 
> even if it's at a difference 10^-24, i assure you, if we had money that was
> this accurate, banks would "require" this much precision in there software :|
> 
> i am just curious what is the *the few on this list*  knowledge about this...
> 
> i recently (3 minutes ago) got in an argument with a friend on this *topic*,
> he told me his professor said that "Gravity is a FORCE" and saying anything
> different from that is pure anarchy.

Due to my degree in astrophysics, I have had some exposure to this kind of
stuff.  The presence of matter or energy in space (which are actually
equivalent -- remember E = mc^2) causes the space surrounding it to become
curved.  The more mass (or energy), the greater the curvature.  Gravity is
the attractive force which arises due to this curvature.

General Relativity is very interesting, but I doubt that many programmers
need it unless they're simulating near-light-speed travel or plan to let
users fly a spaceship near black holes.  Basic Newtonian physics ought to
serve you just fine.  For a character standing on the surface of a planet,
time actually travels faster for his head than it does for his feet, but the
difference is so miniscule that it's difficult to measure with even our best
technology.  Implementing a relativistic effect like this would never
produce any noticeable results.

If you're curious about the subject of General Relativity, I have found the
following book to be very well written:

Foster and Nightingale, "A Short Course in General Relativity",
Springer-Verlag.

http://www.amazon.com/exec/obidos/ASIN/0387942955/

Let me warn you though, unless you have an M.S. or better in physics or
mathematics, this book will scare you.

-- Eric Lengyel

Re: [Algorithms] rather curious

[Jeff L. <je...@di...>]

The reason people don't know a lot about relativistic physics is they have trouble with Galileo let alone Einstein.

Funny this should come up today since last night we got into a little debate about this at dinner with some friends.  My friend works at JPL and we were talking about skydiving and this came up.  No one believed us that the objects hit at basically the same time regardless of mass.  So we all started dropping stuff on the table to prove it.  Pretty funny.  It is always amazing how a simple "try it yourself" can surprise people.  In general they just believe it should be some way and never check it out.  No wonder Galileo ended up in jail.

The whole what is gravity thing is pretty tough.  Claiming to have the "right" answer is probably folly.  Clearly Galileo/Newton works fine for most applications any human would run into.  I am no expert on gravitational physics but from what I know, common thinking is based  on  Einstein's theory of General relativity.  The mass of objects warp spacetime and the falling is explained by objects following a straight path in space-time. 

Galileo went to great pains to prove that Aristotle and Plato were wrong about falling objects.  If he wasn't exactly right to the order of 10^-24 or whatever, I am not sure it matters.  At JPL, good old Newton does the job for most things.

Using Newton's equations for the force of gravity and f=ma you can see how the mass of the falling object just drops out.  Different masses do cause the objects to hit with different forces but that is different from the time, eh.

If someone wants to implement actual relativistic physics for simple rigid body simulations, I am sure it would be cool, but Newton is good enough for me :)

Didn't they do the feather and rock demo on an Apollo mission as a pr thing?  I seem to remember seeing a video of it.

-Jeff

At 04:26 PM 9/10/2000 -0500, you wrote:
>hey,
>i am just wondering, but how many people know about *this*
>"gravity isn't really a force" and that it is caused by the curvature in the
>space time fabric.
>
>And, if you drop two objects in a vacuum they *really* don't fall
>at the same rate (difference is very small, order of 10^-24) <this *makes
>sense*>
>why don't more people know this?
>
>even if it's at a difference 10^-24,
>i assure you, if we had money that was this accurate, banks would "require"
>this much precision in there software :|
>
>i am just curious what is the *the few on this list*  knowledge about
>this...
>
>i recently (3 minutes ago) got in an argument with a friend on this *topic*,
>he told me his professor said that "Gravity is a FORCE" and saying anything
>different from that is pure anarchy.
>
>i told him what is above is true and André Lamothe writes this in all of his
>books, and i'm pretty sure he knows more than your professor (the laws make
>sense as well), ...
>
>
>
>i am probably just t-ed of cause i didn't have more proof about the space
>time fabric one :|
>
>
>btw, andre, if your not on the list;
>i highly suggest you join :) i know your busy with volume 2 and all...
>
>peace,
>akbar A.
>
>
>_______________________________________________
>GDAlgorithms-list mailing list
>GDA...@li...
>http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] rather curious

[Robert D. <RD...@ac...>]

> hey,
> i am just wondering, but how many people know about *this*
> "gravity isn't really a force" and that it is caused by the 
> curvature in the space time fabric.

What is it then ?
I mean being caused by the curvature of space-time doesn't explain what it
is.
A ball rolls down a hill because of gravity, not because of the curvature of
the surface its on.

Rob

RE: [Algorithms] Sorting polys

[Ignacio C. <i6...@ho...>]

Stefano 'Panda' Baraldi wrote:
> Of course this has to be done on manually transformed vertex coords.
> Anyone knows how commercial quality engines (Q3,UnrealT,...) handle polygon
> sorting for alpha blending?
> Do they use underlying structures like bsp?

As far as i know q3 uses qsort for dynamic objects, but there's no sorting for bsp faces. Those
polygons are only sorted at the beginning depending on their sort number and material.

Ignacio Castano
ca...@cr...

[Algorithms] Flexporter update

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

A quick post to tell Flexporter users there's a new version (1.05) here:
www.codercorner.com/Flexporter.htm

With some code to read ZCB files, support for compressed files, an option to
fix non-manifold meshes, among other little things.

Pierre

[Algorithms] rather curious

[Akbar A. <sye...@ea...>]

hey,
i am just wondering, but how many people know about *this*
"gravity isn't really a force" and that it is caused by the curvature in the
space time fabric.

And, if you drop two objects in a vacuum they *really* don't fall
at the same rate (difference is very small, order of 10^-24) <this *makes
sense*>
why don't more people know this?

even if it's at a difference 10^-24,
i assure you, if we had money that was this accurate, banks would "require"
this much precision in there software :|

i am just curious what is the *the few on this list*  knowledge about
this...

i recently (3 minutes ago) got in an argument with a friend on this *topic*,
he told me his professor said that "Gravity is a FORCE" and saying anything
different from that is pure anarchy.

i told him what is above is true and André Lamothe writes this in all of his
books, and i'm pretty sure he knows more than your professor (the laws make
sense as well), ...



i am probably just t-ed of cause i didn't have more proof about the space
time fabric one :|


btw, andre, if your not on the list;
i highly suggest you join :) i know your busy with volume 2 and all...

peace,
akbar A.

Re: [Algorithms] FIST optimization

[Timur D. <ti...@3d...>]

After running into this bug sometime ago i just did this:
there`s very few places where this code actually needed,
simple check of profiling result will give all places where this function
should be used, without sacraficing
precision in code where speed is not relevant.

inline int ftoi( float f ) {
  int temp;
  __asm   fld [f]
  __asm fistp [temp]
  return temp;
}

_______________________
 Timur Davidenko.
 Lead Programmer.
 3Dion Inc. (www.3dion.com)
 e-mail: ti...@3d...


----- Original Message -----
From: "Pierre Terdiman" <p.t...@wa...>
To: <gda...@li...>
Sent: Sunday, September 10, 2000 4:55 PM
Subject: Re: [Algorithms] FIST optimization


> > 3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway,
> *and*
> > reset the FPU after D3D has been initialized.
>
> Another idea: maybe we could just put the render code in a separate thread
> and let it go... Since the FPU mode is saved/restored during task switches
> (I checked), it could probably be the simplest way.
>
> And John, I just found that my Perlin noise code was not working anymore
in
> Release mode (I didn't use it for a long time), because of the /Qifist as
> well ! I checked it after reading about your wacked hash-table, since the
> standard Perlin also use the hash-way. And that was here, crystal clear,
> completely biased with a round-to-nearest mode......
>
> ...suddenly I'm scared...
>
> Pierre
>
>
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

Re: [Algorithms] FIST optimization

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

> 3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway,
*and*
> reset the FPU after D3D has been initialized.

Another idea: maybe we could just put the render code in a separate thread
and let it go... Since the FPU mode is saved/restored during task switches
(I checked), it could probably be the simplest way.

And John, I just found that my Perlin noise code was not working anymore in
Release mode (I didn't use it for a long time), because of the /Qifist as
well ! I checked it after reading about your wacked hash-table, since the
standard Perlin also use the hash-way. And that was here, crystal clear,
completely biased with a round-to-nearest mode......

...suddenly I'm scared...

Pierre

Re: [Algorithms] FIST optimization

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

Well,

I've just experienced the very same bug, just today, with some skeletal
animation code:

- it works in Debug build
- it works in Release build without /Qifist
- it fails in Release build with /Qifist

After some time, I managed to find the wacked line. Just that:

 curidx  = udword(mPlayTime);

...where mPlayTime is obviously a float.

This modification fixed it:

  curidx  = (udword)floorf(mPlayTime);

...which means one way or another the FPU rounding mode actually had been
modified before, somewhere. This is quite "fun" to face that bug just when
the topic comes to the list. But this is frightening to realize it
*actually* happens. And since I'm *always* compiling with /Qifist, I wonder
how many of them silently lie all over the place, ready to bomb.

Then I thought about the recent mails here. I then changed the way I
initialize Direct3D, and used DDSCL_FPUPRESERVE instead of DDSCL_FPUSETUP.
Nothing changed.


...but the guilty one is D3D anyway...

When I reset the FPU to the "chop" rounding mode before calling
Renderer->Init(), it still does not work.

When I reset the FPU to the "chop" rounding mode after Renderer->Init(), it
*does* work.

Hence:
1) Initializing D3D changes the rounding mode.
2) ...even if you use DDSCL_FPUPRESERVE..... !
3) So the probable best way so far is to use DDSCL_FPUPRESERVE anyway, *and*
reset the FPU after D3D has been initialized.

Maybe I'm missing something with D3D (perhaps another magic flag in another
place), but for the moment and for my particular bug, I clearly found the
guilty one.

Hope it helps.

Pierre



----- Original Message -----
From: John Ratcliff <jra...@ve...>
To: <gda...@li...>
Sent: Saturday, September 09, 2000 7:27 PM
Subject: [Algorithms] FIST optimization


> As many of you already know, the call to 'ftol' can be one of the biggest
> hotspot spikes in a 3d application.  Every time a floating point number is
> converted into an integer, rather than simply producing a 'fist'
> instruction, MSVC will instead invoke a very slow procedure call to
'ftol'.
> I have heard this is to ensure that the rounding behaviour of the
operation
> conforms to ANSI standard or something like that.
>
> Back when I was an assembly programmer I just used the fist instruction
> wherever needed.  With MSVC there is a compiler optimization switch called
> /Qifist, which allows MSVC to use the 'fist' instruction instead of the
call
> to 'ftol'.
>
> When I enable this optimization my performance profile is greatly
improved.
> At the heart of my collision detection routines is a hash, where I take
the
> floating point x,y co-ordinate in world space and remap it into an index
to
> this precomputed collision detection table.  This is a critical operation
> that requires the conversion from floating point to int, very efficiently.
>
> However, the behavior I am experiencing is as if the rounding mode were
> occasionally set to something other than truncate behavior.  Meaning,
where
> I expect a conversion from 2.99999 to int to produce a 2, not a 3.  The
> behaviour is spurious and unpredictable.  When I worked in assembly code I
> never had this problem.
>
> My main question is, how can the rounding mode ever get changed?  Or am I
> missunderstanding the behavior possibly?
>
> The symptom is as follows.  Without the /Qifist option enabled my
collision
> detection works flawlessly.  With the /Qifist enabled it behaves
spuriously,
> exactly as if sometimes it rounds the float to hash index incorrectly,
thus
> accessing the wrong pre-computed collision detection polygon set.
>
> Why can't you guarentee that the rounding mode is set to truncate
throughout
> the application?  I could switch to inline assembly I suppose, but I
prefer
> to have the compiler generate the code naturally with all of it's normal
> optimizations enabled.  Does anyone know the preferred method to guarentee
> the processor is in a rounding mode which causes truncation to always
occur?
> Or am I missinterpreting the problem entirely?
>
> Thanks,
>
> John
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

RE: [Algorithms] Game Developer Salary

[Gavan H. <gh...@si...>]

I would have to agree with you Scott, I have noticed that my salary in the
US is higher than that quoted for Game companies, and we have the same level
of complexity and challenges. I have also noticed varied reasons for low
salaries, outside the Game industry it is often due to people that see quick
one off apps made in RAD languages (VB etc) as being more bang for buck even
though they spend hours trying to finish and fine the app which is where
they would reaped huge benifits if they used a talented guy and a flexible
language such as C /C++.

In the Game Industry I have witnessed an attitude that IT companies also
posses being, we are a cool company, our product is cool the best will
sacrafice salary just be associated with us, sure that might work for a
short period with a few people trying to upgrade thier skills but
experienced guys just dodge them for obvious reasons.

I wish I knew a solution, but I usually end up just steering clear of those
who will not pay, hoping that one day I will find a couple of other
experiences guys (10+ years expertise...) and make our own product, I think
lots of people have that hope :-)

Gavan

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Scott
LeGrand
Sent: Sunday, September 10, 2000 9:31 AM
To: gda...@li...
Subject: RE: [Algorithms] Game Developer Salary


That's a great albeit short article.  And it's so true.  If they
sniff a single molecule's essence that you might come cheap, say
goodbye to a decent offer.  OTOH game companies in general pay
about 70-80% on the average of what one could get elsewhere with
the same coding skills...

At least that's been my experience.  I've never been offered
a project sufficiently interesting for me to take the pay cut
(though I would if such a project were ever offered).

Scott
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Simple player collision response problem

[<SHA...@ao...>]

In a message dated 09/09/00 15:56:29 !!!First Boot!!!, zi...@n-... 
writes:

<<   By just getting the height
 under the player you will often run into trouble with stairs where you will
 just kind of pop up and it looks/feels quite bad. >>

True, but what I do with stairs is make the player jump just a little like 
you would if you were running up stairs. I just compute how much higher the 
next surface is and then give the player some negative gravity :) to bounce 
them up into the air.

John.

RE: [Algorithms] Game Developer Salary

[Scott L. <va...@be...>]

That's a great albeit short article.  And it's so true.  If they
sniff a single molecule's essence that you might come cheap, say
goodbye to a decent offer.  OTOH game companies in general pay
about 70-80% on the average of what one could get elsewhere with
the same coding skills...

At least that's been my experience.  I've never been offered
a project sufficiently interesting for me to take the pay cut
(though I would if such a project were ever offered).

Scott

RE: [Algorithms] Game Developer Salary

[Sam M. <sa...@dn...>]

Sorry for the off-topicness, but this list IS full of game developers and I
don't know of a list which is used to discuss these topics.

I found the article you mentioned, it's at
http://www.voodooextreme.com/ask/askgrand.html#startingpayrates.

Thanks,
Sam

At 04:49 PM 9/9/2000 -0500, you wrote:
>a.) this is not a game salaray list.
>b.) see above
>
>see www.gamasutra.com or do a search on www.google.com, there 
>was a survey done.
>also brian hook wrote up a "long" article on going rates, etc..
>it should be archived somewhere on www.ve3d.net
>
>peace,
>akbar A.
>
>EOT <end of topic>

Re: [Algorithms] Game Developer Salary

[Scott L. <va...@be...>]

The highest game company salary I was offered in the past 2 years
was $91K in Silicon Valley.  The lowest offer was $55K in Los
Angeles.  I took neither job...

RE: [Algorithms] Game Developer Salary

[Akbar A. <sye...@ea...>]

a.) this is not a game salaray list.
b.) see above

see www.gamasutra.com or do a search on www.google.com, there 
was a survey done.
also brian hook wrote up a "long" article on going rates, etc..
it should be archived somewhere on www.ve3d.net

peace,
akbar A.

EOT <end of topic>


-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Sam
McGrath
Sent: Saturday, September 09, 2000 4:33 PM
To: gda...@li...
Subject: [Algorithms] Game Developer Salary


Hi all,

I don't know if this has been discussed recently or not, but what's the
going rate these days for a programmer at a game company?  I'm wondering
more about 3d programmers / tool developers / etc, not project leads.

-Sam
______________________
Sam McGrath
sa...@dn...
http://www.dnai.com/~sammy
ICQ 5151160
fax: (413) 473-0905

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

[Algorithms] Game Developer Salary

[Sam M. <sa...@dn...>]

Hi all,

I don't know if this has been discussed recently or not, but what's the
going rate these days for a programmer at a game company?  I'm wondering
more about 3d programmers / tool developers / etc, not project leads.

-Sam
______________________
Sam McGrath
sa...@dn...
http://www.dnai.com/~sammy
ICQ 5151160
fax: (413) 473-0905

Re: [Algorithms] FIST optimization

[Amit B. <am...@de...>]

If you're using D3D, then it's quite possible that D3D is
changing the rounding mode. I think there's a flag somewhere
in D3D which you can set so it restores the FPU control
word every time D3D decides to change it.

Ahh.. found it :

IDirectDraw7::SetCooperativeLevel

has a flag called "DDSCL_FPUPRESERVE". From the
docs :

"The calling application cares about the FPU state and does 
not want Direct3D to modify it in ways visible to the application. 
In this mode, Direct3D saves and restores the FPU state every 
time that it needs to modify the FPU state. For more information, 
see DirectDraw Cooperative Levels and FPU Precision. "

That might resolve your issues.

Re: [Algorithms] FIST optimization

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

> I have heard this is to ensure that the rounding behaviour of the
operation
> conforms to ANSI standard or something like that.

Exactly. Else the FIST instruction alone can produce anything, as you stated
(a floor, a ceil or a best, depending on the current FPU rounding mode).


> My main question is, how can the rounding mode ever get changed?  Or am I
> missunderstanding the behavior possibly?

I would have said the rounding mode was saved/restored during task switchs,
but I'm not so sure. If it's not, I guess it's perfectly possible for a
thread to setup a "ceil" rounding mode, and then you're in trouble later.
But I really doubt the FPU mode is not saved, since many apps would already
have exploded otherwise.

So, maybe somewhere in your code you call a third-party API which changes
the FPU rounding mode. IIRC you're using some of them (some RAD Tools apps
or maybe a physics one). You'd better restore the correct FPU rounding mode
after you call'em.

IIRC the LoadLibrary method also resets the FPU to a particular state, which
might not suits your needs. All in all it's worth reconfiguring the FPU
before your collision code. Once / frame, it's free.

Use the _controlfp and _control87 functions if you don't want inline
assembly.

And BTW I would say this is a common problem. I had similar troubles, more
than one time...

Pierre

RE: [Algorithms] FIST optimization

[Norman V. <nh...@ca...>]

John Ratcliff writes:
>
>My main question is, how can the rounding mode ever get changed?

There was a discussion about the fpu being reset recently on the MingW32
list

This URL should get you lots of hits
http://www.egroups.com/messagesearch/mingw32?query=long%20double

See any of the thread

"More on 'long double' problems under Win9x"

Let us know if you come up with anything 'definate'

Norman Vine

[Algorithms] FIST optimization

[John R. <jra...@ve...>]

As many of you already know, the call to 'ftol' can be one of the biggest
hotspot spikes in a 3d application.  Every time a floating point number is
converted into an integer, rather than simply producing a 'fist'
instruction, MSVC will instead invoke a very slow procedure call to 'ftol'.
I have heard this is to ensure that the rounding behaviour of the operation
conforms to ANSI standard or something like that.

Back when I was an assembly programmer I just used the fist instruction
wherever needed.  With MSVC there is a compiler optimization switch called
/Qifist, which allows MSVC to use the 'fist' instruction instead of the call
to 'ftol'.

When I enable this optimization my performance profile is greatly improved.
At the heart of my collision detection routines is a hash, where I take the
floating point x,y co-ordinate in world space and remap it into an index to
this precomputed collision detection table.  This is a critical operation
that requires the conversion from floating point to int, very efficiently.

However, the behavior I am experiencing is as if the rounding mode were
occasionally set to something other than truncate behavior.  Meaning, where
I expect a conversion from 2.99999 to int to produce a 2, not a 3.  The
behaviour is spurious and unpredictable.  When I worked in assembly code I
never had this problem.

My main question is, how can the rounding mode ever get changed?  Or am I
missunderstanding the behavior possibly?

The symptom is as follows.  Without the /Qifist option enabled my collision
detection works flawlessly.  With the /Qifist enabled it behaves spuriously,
exactly as if sometimes it rounds the float to hash index incorrectly, thus
accessing the wrong pre-computed collision detection polygon set.

Why can't you guarentee that the rounding mode is set to truncate throughout
the application?  I could switch to inline assembly I suppose, but I prefer
to have the compiler generate the code naturally with all of it's normal
optimizations enabled.  Does anyone know the preferred method to guarentee
the processor is in a rounding mode which causes truncation to always occur?
Or am I missinterpreting the problem entirely?

Thanks,

John

RE: [Algorithms] Simple player collision response problem

[Robert D. <RD...@ac...>]

> But since the algorithm is the same for walls and floors
> I'd assume it would happen for both.

Not necessarily a correct assumption, since gravity acts downwards you
always have a force pulling you down into the crease, but when walking into
a corner you could simply zero the walking force since the player is doing
something silly, and this won't look bad.  Whereas to zero gravity could
look very wrong.

Robert

Re: [Algorithms] Simple player collision response problem

[Jason Z. <zi...@n-...>]

I am going to test to see if happens with corners as well, if it only
happens on valleys in the terrain I might be able to hack something.  But
since the algorithm is the same for walls and floors I'd assume it would
happen for both.

I actually want to use the same algorithm for all polygons, mainly because
of things like walking up stairs.  This algorithm (found on flipcode.com)
allows the player to smoothly walk up stairs.  By just getting the height
under the player you will often run into trouble with stairs where you will
just kind of pop up and it looks/feels quite bad.

- Jason Zisk
- nFusion Interactive LLC


----- Original Message -----
From: <SHA...@ao...>
To: <gda...@li...>
Sent: Saturday, September 09, 2000 1:54 AM
Subject: Re: [Algorithms] Simple player collision response problem


> In a message dated 09/09/00 00:14:16 !!!First Boot!!!,
Ste...@im...
> writes:
>
> << Don't wait until the next frame to recurse the rebound.  In my
collision
>  detection I let the movement continue as far as is possible during the
frame
>  that the collision takes place so the frame displays only the results of
the
>  bouncing.  What I see at creases is a smooth migration toward the center
of
>  the crease until the player is directly on the crease. >>
>
> Hi,
>
> What I do is only test collision on tri's which the player is not allowed
to
> walk on i.e. by testing the normal->y component of the surface.
> Then, to determine the player's y position, I shoot a ray straight down
and
> see which tri this hits and from that compute the y of where the player is
> standing.
> This stops wallowing around in creases :) and also cues which sounds to
play
> for the players footsteps based on the texture type under the player.
>
> Does your algorithm also have the undesirable effect in a concave corner
> where two walls meet??
>
> John.
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list