Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Help out my Archers please...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 Vanz   Members   -  Reputation: 204

Like
0Likes
Like

Posted 21 August 2012 - 12:12 AM

So I have many small archers and I want to draw their arrows as pixels. I need a working solution that doesn't require a lot of calcs,like sines and arctans cause there are many many archers...

So to define the problem in terms of variables:

1. Start with any point x1,y1
2. Arrow can fly to any endpoint, call it x2,y2
3. Now pretend you draw a line from x1,y1 to x2,y2
4. Now take the middle of the line and move it away a distance "h", end points don't move.
5. I need an arc, starting at x1,y1 and ending at x2,y2, with a height of h... make sense?

I need an efficient algorithm for calculating this, Here's how I'm drawing a straight line from x1, y1 to x2, y2

int  x1,y1,x2,y2,h;
float Dist, Angle;
//---------------------------------------------------------------------------------------------------------------

// These can be any combination of numbers
x1=90; y1=90; x2=300; y2=295, h=50;

Graphics.DrawLine(x1, y1, x2, y2, Red, *g2); //From my Graphics Library

Dist=sqrt(float(x2-x1)*float(x2-x1)+float(y2-y1)+float(y2-y1));
Angle=atan(float(y2-y1)/float(x2-x1) ) ;

for(i=0;i<Dist;i++)
{
Graphics.SetPixel(int(x1+i), int(y1+i*tan(Angle)), RGB(255, i, i), *g2);
}



Posted Image

I'd like to have little to no trig functions like sine or tan if possible...

All my men are in a 2d iso view, so I don't think gravity formula's will work well as the arc would come out weird, if everything was 2d then gravity would work fine...

I was thinking of using the equation of an ellipse and rotating it but I think it'll look to bulgy or rounded on the ends, plus it would use lots of time consuming eqn's with sqrt's....

Hope that made sense?

Any help would be appreciate...

Vanz

Edited by rhuala, 21 August 2012 - 12:50 AM.


Sponsor:

#2 SimonForsman   Crossbones+   -  Reputation: 6323

Like
0Likes
Like

Posted 21 August 2012 - 01:05 AM

How about something like:

Since you are representing it as a pixel you don't need to get a perfect line so..

when the arrow is fired you calculate these:
distance = (endpoint - startpoint).length();
totalFlightTime = distance / arrowSpeed;
direction = (endpoint - startpoint).normalize();
offset.x = -direction.y
offset.y = direction.x
//if you want the offset to always point upwards just flip the signs on both components if offset.y is negative
thus:
if (offset.y<0) {
offset.y = -offset.y;
offset.x = -offset.x;
}
offset = offset.normalize();

Now things can be kept fairly simple for the per frame update:

to get the x.y position on a straight line we just do:
currentPos = startPoint + direction*time*velocity;
to get an arc shape we probably want a curve with its peak at half the flighttime, since our offset is normalized we can do:
timeFraction = (time/totalFlightTime)-0.5;
offset.scale(timeFraction*timeFraction*arcHeight);
currentPos += offset;

The only expensive operations here are the vector normalizations and length calculation (1 sqrt each) but they are only done when the arrow is fired so it shouldn't be a big deal. (3 total per arrow), the part that has to be done for each step on the way is extremely lightweight. (The biggest problem with this approach is that quite a bit of data has to be stored for each arrow which could cause problems for the CPU cache if you got an extremely high number of arrows that are updated on a per frame basis in which case it might be better to only store the startpoint, endpoint and start time for each arrow and recalculate the rest each frame (the CPU is alot faster than RAM so if you can't fit it all in cache it will probably be faster to do a few extra calculations)) (If you draw out the entire arc for one arrow at the time rather than animate the arrows as flying pixels the potential cache issue becomes irrelevant but that won't be as cool Posted Image)

Edited by SimonForsman, 21 August 2012 - 01:10 AM.

I don't suffer from insanity, I'm enjoying every minute of it.
The voices in my head may not be real, but they have some good ideas!

#3 Bluefirehawk   Crossbones+   -  Reputation: 1232

Like
0Likes
Like

Posted 21 August 2012 - 01:22 AM

I agree, the blue line looks weird for an Iso view. One thing you have to keep in mind, when you add an arc shot in Iso, it is hard to tell if it goes up or right. If you have an Action RPG and the player should evade the arrows, an arc may be frustrating for the user, because it is hard to tell where it's target is. If you have a strategy game, it might look better with an arc.


e: didn't see the first response


Edited by Bluefirehawk, 21 August 2012 - 01:24 AM.

Project: Project
Setting fire to these damn cows one entry at a time!




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS