Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Trajectories

Reply
Thread Tools

Trajectories

 
 
Thijs Leeflang
Guest
Posts: n/a
 
      11-13-2009
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/pro...csch6/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
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Eleanor McHugh
Guest
Posts: n/a
 
      11-14-2009
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 head
>
> http://www.gamedev.net/reference/pro...csch6/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.new(, :y)
ComponentVector = Struct.new(, :y)

# Assume bearing stored in radians (360 degrees = 2 * Pi radians)
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

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason


 
Reply With Quote
 
 
 
 
Marnen Laibow-Koser
Guest
Posts: n/a
 
      11-14-2009
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 head
>
> http://www.gamedev.net/reference/pro...csch6/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,
--
Marnen Laibow-Koser
http://www.marnen.org
http://www.velocityreviews.com/forums/(E-Mail Removed)
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      11-15-2009
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

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason


 
Reply With Quote
 
Marnen Laibow-Koser
Guest
Posts: n/a
 
      11-15-2009
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.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason


Best,
--
Marnen Laibow-Koser
http://www.marnen.org
(E-Mail Removed)
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Thijs Leeflang
Guest
Posts: n/a
 
      11-15-2009
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
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      11-15-2009
On 15 Nov 2009, at 00:42, Marnen Laibow-Koser wrote:
> 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?


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
----
raise ArgumentError unless @reality.responds_to? :reason


 
Reply With Quote
 
Marnen Laibow-Koser
Guest
Posts: n/a
 
      11-15-2009
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.net
> ----
> raise ArgumentError unless @reality.responds_to? :reason


Best,
--
Marnen Laibow-Koser
http://www.marnen.org
(E-Mail Removed)
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
Eleanor McHugh
Guest
Posts: n/a
 
      11-15-2009
On 15 Nov 2009, at 01:19, Marnen Laibow-Koser wrote:
> Eleanor McHugh wrote:
>> 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.


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
----
raise ArgumentError unless @reality.responds_to? :reason


 
Reply With Quote
 
Marnen Laibow-Koser
Guest
Posts: n/a
 
      11-15-2009
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
>


Best,
--
Marnen Laibow-Koser
http://www.marnen.org
(E-Mail Removed)
--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments