I have a number of sprites that I want to orbit a central point, scaling
down as the move away from the screen and scaling up as they move
closer.
I’m able to draw the sprites properly scaled and at the correct
positions statically around the ellipse, but I am having difficulty
getting them to animate correctly.
Does anyone know where I should begin looking for information on moving
a sprite in an elliptical orbit?
-Chris
I have a number of sprites that I want to orbit a central point,
scaling down as the move away from the screen and scaling up as
they move closer.
Hmm… That sounds an awful lot like something I had in mind hacking
the other day… I ended up playing around with the ballfield
instead, though. 
I’m able to draw the sprites properly scaled and at the correct
positions statically around the ellipse, but I am having difficulty
getting them to animate correctly.
Meaning what, exactly…?
The hardest part is usually removing the sprites. The easiest way to
do that is to simply redraw the whole screen every time. If you have
no background graphics and stuff, you’ll have to clear the screen
with an SDL_FillRect() with some suitable color.
However, that’s going to be pretty slow. If the only stuff that moves
are those sprites, just erase them before you update the coordinates
and repaint them. (That is, use SDL_FillRect() over each one of them,
or restore what was there before by other means, such as rendering
from the game map or what have you, into the respective areas.)
Does anyone know where I should begin looking for information on
moving a sprite in an elliptical orbit?
There’s nothing special about that, really…
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 24 September 2003 19.40, Chris Heller wrote:
Meaning what, exactly…?
Heh, good point. I should be more clear.
What I mean is I can animate the sprites, I can even make them swap
positions with each other.
But when I try to get them to move in elliptical paths it just falls
apart.
So I guess my question is a simple as what do I need to do to calculate
movement along a curved path?
Something is telling me this all comes down to basic trigonometry,
right?
-Chris> ----- Original Message -----
From: David Olofson [mailto:david@olofson.net]
Sent: Wednesday, September 24, 2003 2:17 PM
To: sdl at libsdl.org
Subject: Re: [SDL] Orbiting sprites.On Wednesday 24 September 2003 19.40, Chris Heller wrote:
I have a number of sprites that I want to orbit a central point,
scaling down as the move away from the screen and scaling up as they
move closer.Hmm… That sounds an awful lot like something I had in mind hacking
the other day… I ended up playing around with the ballfield
instead, though.I’m able to draw the sprites properly scaled and at the correct
positions statically around the ellipse, but I am having difficulty
getting them to animate correctly.Meaning what, exactly…?
The hardest part is usually removing the sprites. The easiest way to
do that is to simply redraw the whole screen every time. If you have
no background graphics and stuff, you’ll have to clear the screen
with an SDL_FillRect() with some suitable color.However, that’s going to be pretty slow. If the only stuff that moves
are those sprites, just erase them before you update the coordinates
and repaint them. (That is, use SDL_FillRect() over each one of them,
or restore what was there before by other means, such as rendering
from the game map or what have you, into the respective areas.)Does anyone know where I should begin looking for information on
moving a sprite in an elliptical orbit?There’s nothing special about that, really…
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. | MIDI,
| modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
— Chris Heller wrote:
Meaning what, exactly…?
Heh, good point. I should be more clear.
What I mean is I can animate the sprites, I can even make them swap
positions with each other. But when I try to get them to move in
elliptical paths it just falls apart.So I guess my question is a simple as what do I need to do to
calculate movement along a curved path?Something is telling me this all comes down to basic trigonometry,
right?
Pretty much. This is the sort of programming that few libraries
will have for you to use straightforwardly. But the math isn’t all
that hard. My math background blows and I’m confidant that if I wanted
to reimplement Space War that it wouldn’t be too much of a pain.
NBarnes__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
So I guess my question is a simple as what do I need to do to calculate
movement along a curved path?Something is telling me this all comes down to basic trigonometry,
right?
I came in late on this one but assuming you’re in 2d here (not 3d):
You have two radiuses for most ellipses, rx and ry (horizontal and vertical).
Each iteration you want to move A radians around the ellipse, from your
previous position of P radians.
So each iteration your movement must be:
X direction: cos(A+P)*rx - cos§*rx
Y direction: sin(A+P)*ry - sin§*ry
I think thats the sort of thing you are looking for right? Tell me if Ive
misunderstood (or indeed if the above is wrong!)
HTH,
Neil.
Ah, now things are starting to become clear.
That looks familiar.
I’ll test it out this evening (no game coding at work 
) and let you
know how it goes.
Thanks!
Chris> ----- Original Message -----
From: Neil Brown [mailto:neil@twistedsquare.com]
Sent: Wednesday, September 24, 2003 5:36 PM
To: sdl at libsdl.org
Subject: RE: [SDL] Orbiting sprites.So I guess my question is a simple as what do I need to do to calculate
movement along a curved path?
Something is telling me this all comes down to basic trigonometry,
right?I came in late on this one but assuming you’re in 2d here (not 3d):
You have two radiuses for most ellipses, rx and ry (horizontal and
vertical).Each iteration you want to move A radians around the ellipse, from your
previous position of P radians.So each iteration your movement must be:
X direction: cos(A+P)*rx - cos§*rx
Y direction: sin(A+P)*ry - sin§*ryI think thats the sort of thing you are looking for right? Tell me if
Ive misunderstood (or indeed if the above is wrong!)HTH,
Neil.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
So I guess my question is a simple as what do I need to do to calculate
movement along a curved path?
Another trick, rather than ‘hard-coding’ it to a trigonometrically-calculated
ellipse, is to make the objects move around on their own, and gravitate
towards the center.
In other words, each object has the following:
x,y - position on the screen
xm,ym - momentum (negative for left/u; positive for right/down)
To move the objects during even frame (event loop cycle), just do:
x = x + xm;
y = y + ym;
To make them ‘gravitate’ towards something, you can do:
if (x > home_x)
xm–;
else if (x < home_x)
xm++;
if (y > home_y)
ym–;
else if (y < home_y)
ym++;
In other words “if I’m suddenly on the left of the thing I’m homing-in-on,
start heading to the right, to go towards it!”
This, of course, ends up being far less accurate than using trig, but it
can look more ‘realistic’, I guess you could say. ;^)
This is how I’ve done homing-missiles in the past. If you’re clever,
you can even do those cheesy movie stunts where you (e.g., a space-ship
being chased by the above-explained homing missiles) head closer and
closer to some big deadly object, and then suddenly change course.
The missile’s “xm/ym” changes don’t happen quick enough, and the missile
crashes into the object, instead of you. (How cheesy ;^) )
Something is telling me this all comes down to basic trigonometry,
right?
Heheh… it really depends. If you want something that’ll orbit the
same no matter where the ‘center’ is, or what’s going on around it,
then yeah, using trig (or heck, an array filled with some pre-calc’d
trig values) is what you want. “Options” (little defense doo-dads
around a space ship) is one example.
If you want something that might be more inaccurate (hey, there can
be benefit to inaccuracy!), then you can use my hack above. 
YMMV. IANAPGP[*]
-bill!On Wed, Sep 24, 2003 at 04:55:45PM -0400, Chris Heller wrote:
–
bill at newbreedsoftware.com Got kids? Get Tux Paint!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/
[*] I am not a professional game programmer. [+]
[+] For godsake, someone! HIRE ME!! :^(
Neat trick! I’ll have to add that to my scrap book.
For this instance though I need very precise uniform motion. So I think trig is the way to go.
It may be useful to precalc everything, but I’m not sure it is necessary.
Nor am I exactly sure what I’d be pre-calculating yet!
Oh how I should have studied harder in school
Thanks everyone.
-Chris-----Original Message-----
From: Bill Kendrick [mailto:nbs at sonic.net]
Sent: Wed 9/24/2003 6:29 PM
To: sdl at libsdl.org
Cc:
Subject: Re: [SDL] Orbiting sprites.
On Wed, Sep 24, 2003 at 04:55:45PM -0400, Chris Heller wrote:
>
> So I guess my question is a simple as what do I need to do to calculate
> movement along a curved path?
Another trick, rather than 'hard-coding' it to a trigonometrically-calculated
ellipse, is to make the objects move around on their own, and gravitate
towards the center.
In other words, each object has the following:
x,y - position on the screen
xm,ym - momentum (negative for left/u; positive for right/down)
To move the objects during even frame (event loop cycle), just do:
x = x + xm;
y = y + ym;
To make them 'gravitate' towards something, you can do:
if (x > home_x)
xm--;
else if (x < home_x)
xm++;
if (y > home_y)
ym--;
else if (y < home_y)
ym++;
In other words "if I'm suddenly on the left of the thing I'm homing-in-on,
start heading to the right, to go towards it!"
This, of course, ends up being far less accurate than using trig, but it
can look more 'realistic', I guess you could say. ;^)
This is how I've done homing-missiles in the past. If you're clever,
you can even do those cheesy movie stunts where you (e.g., a space-ship
being chased by the above-explained homing missiles) head closer and
closer to some big deadly object, and then suddenly change course.
The missile's "xm/ym" changes don't happen quick enough, and the missile
crashes into the object, instead of you. (How cheesy ;^) )
> Something is telling me this all comes down to basic trigonometry,
> right?
Heheh.. it really depends. If you want something that'll orbit the
same no matter where the 'center' is, or what's going on around it,
then yeah, using trig (or heck, an array filled with some pre-calc'd
trig values) is what you want. "Options" (little defense doo-dads
around a space ship) is one example.
If you want something that might be more inaccurate (hey, there can
be benefit to inaccuracy!), then you can use my hack above. ;)
YMMV. IANAPGP[*]
-bill!
--
bill at newbreedsoftware.com Got kids? Get Tux Paint!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/
[*] I am not a professional game programmer. [+]
[+] For godsake, someone! HIRE ME!! :^(
_______________________________________________
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/ms-tnef
Size: 6622 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20030924/ecc3e0a5/attachment.bin
Do NOT precalc anything ligther than fractals. It’s slower in most
cases. For basic trig LUT is usefull only in 486 and slower machines.
Besides LUT’s are order of magnitude slower in modern CPU’s even in more
complicated things than basic trig. If you find need for optimization,
optimize the algorythm instead. This will lead to much higher
performance gain than using unoptimal algorythm with LUT’s.On Thursday 25 September 2003 01:29, Bill Kendrick wrote:
Heheh… it really depends. If you want something that’ll orbit the
same no matter where the ‘center’ is, or what’s going on around it,
then yeah, using trig (or heck, an array filled with some pre-calc’d
trig values) is what you want. “Options” (little defense doo-dads
around a space ship) is one example.
Do NOT precalc anything ligther than fractals. It’s slower in most
cases. For basic trig LUT is usefull only in 486 and slower machines.
Why, exactly?
Besides LUT’s are order of magnitude slower in modern CPU’s even in more
complicated things than basic trig.
I occasionally program for systems that lack FPUs (Zaurus PDA for example).
LUT and fixed-point math REEEEALLY help.
-bill!On Thu, Sep 25, 2003 at 03:37:52AM +0300, Sami N??t?nen wrote:
–
bill at newbreedsoftware.com Got kids? Get Tux Paint!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/tuxpaint/
Do NOT precalc anything ligther than fractals.
It’s slower in most
cases. For basic trig LUT is usefull only in 486
and slower machines.Why, exactly?
I believe (memory is hazy on this ATM) this is
because the time to compute it (on most modern
processors) is less than the time to fetch it out of
memory… but even if it isn’t, the increase in cache
thrashing (from the memory access) will slow down your
program more anyways.
Besides LUT’s are order of magnitude slower in
modern CPU’s even in more
complicated things than basic trig.
… so what I just said was a too-much-in-depth
version of that :).
I occasionally program for systems that lack FPUs
(Zaurus PDA for example).
LUT and fixed-point math REEEEALLY help.
We’re talking usual/common case. Still, gotta
remember… never say never :). Or not in the context
of meaning never. Or something.
-bill!
-Mike> On Thu, Sep 25, 2003 at 03:37:52AM +0300, Sami N??t?nen wrote:
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Do NOT precalc anything ligther than fractals.
It’s slower in most
cases. For basic trig LUT is usefull only in 486
and slower machines.
Why, exactly?
I believe (memory is hazy on this ATM) this is
because the time to compute it (on most modern
processors) is less than the time to fetch it out of
memory… but even if it isn’t, the increase in cache
thrashing (from the memory access) will slow down your
program more anyways.
Yes the cache trashing is in most cases the more severe result of LUT’s.
There are rare occasions when LUT’s are usefull in modern CPU’s, but
then the LUT’s are really small and the concecutive entries of the
content in the LUT has nothing in common. Or if the CPU is not so
’modern’ ie either PDA processor or old CPU.
I occasionally program for systems that lack FPUs
(Zaurus PDA for example).
LUT and fixed-point math REEEEALLY help.We’re talking usual/common case. Still, gotta
remember… never say never :). Or not in the context
of meaning never. Or something.
There of course are exceptions like PDA’s, but one shouldn’t in the
current situation start to use LUT’s at the begining, but simply add
LUT’s in place after everything else works perfectly, and the speed
really needs improvement. And one should really time those changes to
be absolutely sure they really speed things up and that the possible
error they produce to the calculation is not too severe.On Thursday 25 September 2003 09:14, Michael Rickert wrote:
On Thu, Sep 25, 2003 at 03:37:52AM +0300, Sami N??t?nen wrote: