Trajectories

[Thijs Leeflang]

hello,

im having a problem with trajectories,
im trying to make an arrow like movement
i did find this but it's way over my head

http://www.gamedev.net/reference/programming/features/physicsch6/ch06.pdf

i have these values,
@x and @y is the x and y the image is drawn

@targetx = targetx
@targety = targety
@fromx = fromx
@fromy = fromx
@x = fromx
@y = fromy

can anybody help me with this?
thanx

 

[Eleanor McHugh]

hello,

im having a problem with trajectories,
im trying to make an arrow like movement
i did find this but it's way over my head

http://www.gamedev.net/reference/programming/features/physicsch6/ch06.pdf

This is mostly for people who want to model the real-world movement of
projectiles, i.e. parabolic ballistic curves resulting from the action
of gravity. The math isn't hugely complicated, but it does assume a
basic familiarity with trigonometry.

i have these values,
@x and @y is the x and y the image is drawn

@targetx = targetx
@targety = targety
@fromx = fromx
@fromy = fromx
@x = fromx
@y = fromy

can anybody help me with this?

I'm going to assume you want an OO solution that wraps stuff up in a
nice reusable fashion, so here's an example for what such a solution
might look like (it's not tested so treat with caution).

Point = Struct.newx, :y)
ComponentVector = Struct.newx, :y)

# Assume bearing stored in radians (360 degrees = 2 * Pi radians)
BearingVector = Struct.newbearing, :magnitude)

class Entity
attr_accessor :location, :forces

def initialize location = nil
@location = location || Point.new(0, 0)
@forces = {}
end

def move timeslices = 1
@forces.each do |f|
case
when f.bearing
@location.x += Math.cos(f.bearing) * f.magnitude * timeslices
@location.y += Math.sin(f.bearing) * f.magnitude * timeslices
when f.x && f.y
@location.x += f.x * timeslices
@location.y += f.y * timeslices
end
end
end
end

The solution is generalised to allow more than one force to be applied
to an individual entity, and to allow the force vector to be defined
as either (x, y) components or as an angle and a magnitude.

football = Entity.new(Point.new(100, 100)
football.forces[:gravity] = ComponentVector.new(0, -9.81)
football.forces[:kick] = BearingVector(0.5, 27)
football.forces[:wind] = BearingVector(5, 3)
football.move 3

Here I've set up a simple football scenario combining gravity, a kick
and a prevailing wind. The scenario for an arrow would look very
similar.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Marnen Laibow-Koser]

hello,

im having a problem with trajectories,
im trying to make an arrow like movement
i did find this but it's way over my head

http://www.gamedev.net/reference/programming/features/physicsch6/ch06.pdf

Those algorithms look like they'd be fairly simple to implement, but as
Ellie said, you will need to review basic trigonometry.

i have these values,
@x and @y is the x and y the image is drawn

@targetx = targetx
@targety = targety
@fromx = fromx
@fromy = fromx
@x = fromx
@y = fromy

can anybody help me with this?
thanx

It should be fairly clear from the formulae. One thing that bears
repeating, though: never use the default floating-point numbers for
math; they're simply not precise enough. Use integers or BigDecimal.
Best,

 

[Eleanor McHugh]

It should be fairly clear from the formulae. One thing that bears
repeating, though: never use the default floating-point numbers for
math; they're simply not precise enough. Use integers or BigDecimal.

That rather depends on the required level of precision...


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Marnen Laibow-Koser]

That rather depends on the required level of precision...

Well, error accumulates pretty quickly in IEEE 754 floats, and
trajectories require lots of calculation. I wouldn't trust floats in a
situation like that -- would you?

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

Best,

 

[Thijs Leeflang]

hey all,

i finally done it,
i set gravity to -10
then every x millisecs i added +1 to the gravity
this made a nice curve motion

after this i calculated the width between start and endpoint and voila

thanx for everything

 

[Eleanor McHugh]

Well, error accumulates pretty quickly in IEEE 754 floats, and
trajectories require lots of calculation. I wouldn't trust floats
in a
situation like that -- would you?

In a hardcore physics simulation with many forces then no I wouldn't,
but in a simple game then yes I'd probably go with floating-point


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Marnen Laibow-Koser]

In a hardcore physics simulation with many forces then no I wouldn't,
but in a simple game then yes I'd probably go with floating-point

Why? I can't see a single reason to use IEEE floats, unless you've done
benchmarks and are absolutely certain that it's causing a performance
problem. (Ward Cunningham did just that on a computationally intensive
Smalltalk application that used fixed-point for all math -- and found
that he couldn't even measure a difference in performance.)

IEEE floats have no advantages that I can see and huge disadvantages. I
just don't see them as being even slightly appropriate or useful for
math.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

Best,

 

[Eleanor McHugh]

Why? I can't see a single reason to use IEEE floats, unless you've
done
benchmarks and are absolutely certain that it's causing a performance
problem. (Ward Cunningham did just that on a computationally intensive
Smalltalk application that used fixed-point for all math -- and found
that he couldn't even measure a difference in performance.)

IEEE floats have no advantages that I can see and huge
disadvantages. I
just don't see them as being even slightly appropriate or useful for
math.

Because often expressing non-integral values as floating-point in code
better represents intent than using fixed-point math, and unless the
latter will have a performance or accuracy advantage for a given
problem I consider semantic simplicity to be my primary design
criterion.

That said I agree that floating-point sucks and that many programmers
use it in a carefree manner that suggests they're unaware of the
limitations it imposes.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Marnen Laibow-Koser]

Because often expressing non-integral values as floating-point in code
better represents intent than using fixed-point math,

True, perhaps. Ward was doing fixed-point currency, so expressing
amounts as pennies is semantically clear.

But that's where BigDecimal comes in. It's clearly a floating-point
number, but it's actually accurate. Semantically clear, numerically
precise. What more could you want?

and unless the
latter will have a performance or accuracy advantage for a given
problem I consider semantic simplicity to be my primary design
criterion.

BigDecimal is no less semantically simple than Float (particularly when
coupled with Ruby's operator overloading), and it will always have an
accuracy advantage for any conceivable problem.

That said I agree that floating-point sucks and that many programmers
use it in a carefree manner that suggests they're unaware of the
limitations it imposes.


Ellie

Best,

 

[James Edward Gray II]

But that's where BigDecimal comes in. It's clearly a floating-point=20=

number, but it's actually accurate. Semantically clear, numerically=20=

If you put BigDecimal against Float, I'm pretty darn certain you will =
notice a very real speed difference.

James Edward Gray II=

 

[Marnen Laibow-Koser]

If you put BigDecimal against Float, I'm pretty darn certain you will
notice a very real speed difference.

Ruby 1.8.7p72 on Mac OS 10.6.1:

$ time ruby -rbigdecimal -e "1000.times{x = BigDecimal.new('3.5') *
BigDecimal.new('4.2')}"

real 0m0.009s
user 0m0.005s
sys 0m0.003s

$ time ruby -rbigdecimal -e "a = BigDecimal.new('3.5'); b =
BigDecimal.new('4.2'); 1000.times{x = a * b}"

real 0m0.007s
user 0m0.004s
sys 0m0.003s

$ time ruby -e "1000.times{x = 3.5 * 4.2}"
real 0m0.008s
user 0m0.004s
sys 0m0.004s

Looks darn close to me.

James Edward Gray II

Best,

 

[Marnen Laibow-Koser]

Shot (Piotr Szotkowski) wrote:
[...]

When the time results are so small they don’t really mean anything:

shot@devielle:~$ ruby -v
ruby 1.9.1p243 (2009-07-16) [x86_64-linux]

shot@devielle:~$ time ruby -rbigdecimal -e "10_000_000.times{x =
BigDecimal.new('3.5') * BigDecimal.new('4.2')}"
real 0m50.280s
user 0m47.719s
sys 0m0.112s

[...]

Yeah, I tried longer runs as well and saw larger differences. I
question the applicability of those to actual programs, though; even
computationally intensive programs are going to be spending lots of time
doing things other than number crunching.

Besides, what good are fast calculations if they're wrong?

— Shot

Best,

 

[Marnen Laibow-Koser]

Marnen Laibow-Koser:


To clarify, I also believe BigDecimals should be used by default (when
one’s serious about the results’ acccuracy) until they are actually
determined to be a performance bottleneck.

Yes, this is what I was trying to say.

There even was a motion
to make them the language default, but the resolution was that
the performance cost was way too large, and that most (if not all)
other general-purpose languages default to IEEE floats for exactly
this reason.

Interesting.


Well, if they’re slightly wrong, but a couple of times faster, they
might be good enough; the previous example in this thread was IMHO
a good one – you don’t usually need accurate float arithmetics in
action games, but you do often care for the performance gain.

Perhaps. I would think you actually would want accurate math, but it
depends on the game.

— Shot, who wouldn’t mind if Ruby defaulted to BigDecimals

Likewise.

Best,

 

[Josh Cheek]

[Note: parts of this message were removed to make it a legal post.]

Why? I can't see a single reason to use IEEE floats, unless you've done
benchmarks and are absolutely certain that it's causing a performance
problem. [...] IEEE floats have no advantages that I can see and huge
disadvantages. I
just don't see them as being even slightly appropriate or useful for
math.

Why? unless you've done benchmarks and are absolutely certain it's causing a
precision problem.

 

[Rick DeNatale]

Why? =A0I can't see a single reason to use IEEE floats, unless you've don= e
benchmarks and are absolutely certain that it's causing a performance
problem. (Ward Cunningham did just that on a computationally intensive
Smalltalk application that used fixed-point for all math -- and found
that he couldn't even measure a difference in performance.)

So Ward found that fixed point integers weren't SLOWER then floats,
what a surprise!

IEEE floats have no advantages that I can see and huge disadvantages. =A0= I
just don't see them as being even slightly appropriate or useful for
math.

That's just silly if you ask me.

First of all BigDecimals are still floats, with a decimal base and a
variable length, but floats nonetheless.

They aren't a magic bullet, and despite what you said in a slightly
later post, they are neither semantically clear:
=3D> "1.85000000000000008882"

but also
0.999999999999999999999999999999999999999999999999999999E0

Usually people flock to BigDecimal when they discover something like
the first example. But changing the base to 10 only
changes WHICH rational numbers can't be represented, it doesn't
eliminate the problem entirely.

or numerically precise.

Yes perhaps they are more precise but at an increasing cost of
performance as the 'need' to carry around extra digits increases.


I.E.E.E Floating point is just the culmination of the floating point
data types which got us to the moon in the 1960s. They are quite
usable as long as the programmer understands their properties and
limitations, BigDecimal has these limitations as well, just different
parameters on those limitations.

Engineers back then were very used to working with primitive computers
which used floating point numbers of extremely limited precision,
maybe 2 or 3 digits in the fractional part, those computers were
called slide rules.

When I was a young lad, it used to be that young programmers took a
semester long course on numerical analysis, which started with, and
continuously came back to dealing with the properties of floating
point numbers.

I guess that doesn't happen much anymore.

--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Eleanor McHugh]

True, perhaps. Ward was doing fixed-point currency, so expressing
amounts as pennies is semantically clear.

Well currency is an interesting problem. It can be viewed as a scalar =20=

floating-point system, or as an N-dimensional integral system =20
(conventionally 2D but =A3/s/d was a clear example of a 3D currency =20
system and there's no reason why we shouldn't generalise further).

But that's where BigDecimal comes in. It's clearly a floating-point
number, but it's actually accurate. Semantically clear, numerically
precise. What more could you want?

Something that for irrational numbers gives me a useful approximation =20=

without consuming all of the available memory would be nice

BigDecimal is no less semantically simple than Float (particularly =20
when
coupled with Ruby's operator overloading), and it will always have an
accuracy advantage for any conceivable problem.

Accuracy is not precision. It gives me little benefit to be accurate =20
if I only need to be precise to a certain number of decimal places, =20
which is the reason for the existence of floating-point in the first =20
place. One of the dirty secrets of computational physics is that =20
floating-point math is used all over the place...


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Eleanor McHugh]

I.E.E.E Floating point is just the culmination of the floating point
data types which got us to the moon in the 1960s. They are quite
usable as long as the programmer understands their properties and
limitations, BigDecimal has these limitations as well, just different
parameters on those limitations.

Engineers back then were very used to working with primitive computers
which used floating point numbers of extremely limited precision,
maybe 2 or 3 digits in the fractional part, those computers were
called slide rules.

Well there were books of log tables for greater precision, but the
funny thing about the physical world is that it rarely seems to need
precision higher than that.

When I was a young lad, it used to be that young programmers took a
semester long course on numerical analysis, which started with, and
continuously came back to dealing with the properties of floating
point numbers.

The fun of coding numerical methods in Fortran and Assembler. That's a
couple of hundred hours of my life I'll never see again


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

 

[Marnen Laibow-Koser]

So Ward found that fixed point integers weren't SLOWER then floats,
what a surprise!


That's just silly if you ask me.

Why? Sure, I could work around their problems, but I don't care to when
BigDecimals are available.

First of all BigDecimals are still floats, with a decimal base and a
variable length, but floats nonetheless.

They aren't a magic bullet, and despite what you said in a slightly
later post, they are neither semantically clear:

=> "1.85000000000000008882"

but also

0.999999999999999999999999999999999999999999999999999999E0

That's not a question of semantics, but of accuracy. Anyway, it's
easily worked areound by using Rational.

Usually people flock to BigDecimal when they discover something like
the first example. But changing the base to 10 only
changes WHICH rational numbers can't be represented, it doesn't
eliminate the problem entirely.

I know. But BigDecimal + Rational *will* eliminate the problem insofar
as it's possible to do so.

or numerically precise.

Yes perhaps they are more precise but at an increasing cost of
performance as the 'need' to carry around extra digits increases.

Of course. That's always the cost. I'd rather calculate as accurately
as possible and introduce performance hacks (such as IEEE floats) as
necessary.

I.E.E.E Floating point is just the culmination of the floating point
data types which got us to the moon in the 1960s. They are quite
usable as long as the programmer understands their properties and
limitations, BigDecimal has these limitations as well, just different
parameters on those limitations.

Engineers back then were very used to working with primitive computers
which used floating point numbers of extremely limited precision,
maybe 2 or 3 digits in the fractional part, those computers were
called slide rules.

Yes. And you know what? We're not using slide rules any more. It is
silly in 2009 to be bound by the limitations of slide rules.

When I was a young lad, it used to be that young programmers took a
semester long course on numerical analysis, which started with, and
continuously came back to dealing with the properties of floating
point numbers.

I guess that doesn't happen much anymore.

Again, I could do that or (more likely) find out how to do it. But why
bother when wise use of BigDecimal and Rational will completely obviate
the need?

--
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

Best,

 

[Eleanor McHugh]

Again, I could do that or (more likely) find out how to do it. But
why
bother when wise use of BigDecimal and Rational will completely
obviate
the need?

The physical limitations imposed on arbitrary-precision decimal
computation by binary representation are something you should know
*before* arguing that one representation is better than another.


Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net