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
On 13 Nov 2009, at 23:33, Thijs Leeflang wrote:
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 headhttp://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.
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.new(:x, :y)
ComponentVector = Struct.new(:x, :y)
BearingVector = Struct.new(:bearing, :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
raise ArgumentError unless @reality.responds_to? :reason
Thijs Leeflang wrote:
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 headhttp://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 = fromycan anybody help me with this?
thanx
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Eleanor McHugh wrote:
On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
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…
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.netraise ArgumentError unless @reality.responds_to? :reason
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On 14 Nov 2009, at 23:40, Marnen Laibow-Koser wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
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 
On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh wrote:
On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
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
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.netraise ArgumentError unless @reality.responds_to? :reason
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Eleanor McHugh wrote:
On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
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,
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
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Nov 14, 2009, at 7:41 PM, Marnen Laibow-Koser wrote:
But that’s where BigDecimal comes in. It’s clearly a floating-point
number, but it’s actually accurate. Semantically clear, numerically
If you put BigDecimal against Float, I’m pretty darn certain you will
notice a very real speed difference.
James Edward G. II
On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
James Edward G. II wrote:
On Nov 14, 2009, at 7:41 PM, Marnen Laibow-Koser wrote:
But that’s where BigDecimal comes in. It’s clearly a floating-point
number, but it’s actually accurate. Semantically clear, numericallyIf 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 G. II
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Marnen Laibow-Koser:
James Edward G. II wrote:
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.
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
shot@devielle:~$ time ruby -rbigdecimal -e “a = BigDecimal.new(‘3.5’); b
= BigDecimal.new(‘4.2’); 10_000_000.times{x = a * b}”
real 0m16.507s
user 0m14.213s
sys 0m0.020s
shot@devielle:~$ time ruby -e “10_000_000.times{x = 3.5 * 4.2}”
real 0m3.506s
user 0m2.960s
sys 0m0.008s
— Shot
Marnen Laibow-Koser:
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.
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. 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.
Besides, what good are fast calculations if they’re wrong?
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.
— Shot, who wouldn’t mind if Ruby defaulted to BigDecimals 
Shot (Piotr S.) 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
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Shot (Piotr S.) wrote:
Marnen Laibow-Koser:
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.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.
Besides, what good are fast calculations if they’re wrong?
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.
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Sat, Nov 14, 2009 at 8:19 PM, Marnen Laibow-Koser [email protected]
wrote:
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.)
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. 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:
“%.20f” % ((1.85 / 10.0) * 10.0)
=> “1.85000000000000008882”
but also
puts (BigDecimal.new(“1.0”) / 3) * 3
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.
–
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
On 15 Nov 2009, at 01:41, Marnen Laibow-Koser wrote:
better represents intent than using fixed-point math,
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
floating-point system, or as an N-dimensional integral system
(conventionally 2D but £/s/d was a clear example of a 3D currency
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
without consuming all of the available memory would be nice
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.
Accuracy is not precision. It gives me little benefit to be accurate
if I only need to be precise to a certain number of decimal places,
which is the reason for the existence of floating-point in the first
place. One of the dirty secrets of computational physics is that
floating-point math is used all over the place…
Ellie
raise ArgumentError unless @reality.responds_to? :reason
On Sat, Nov 14, 2009 at 7:19 PM, Marnen Laibow-Koser
[email protected]wrote:
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.
On 15 Nov 2009, at 19:13, Rick DeNatale wrote:
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
raise ArgumentError unless @reality.responds_to? :reason
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs