Screen->Line to; Screen->WavyLine?

You mean curvy-wavy, like a sin wave? Huh. I don't think there's an easy way to do that without drawing tiles to the screen or drawing nearly every pixel.

If you want a jagged line, that you could do. I was planning on doing something like that for an electrical-style attack in Zodiac.

You'd do this. First, find the equation for the straight line you'd draw from the beginning to the end of where you want your jaggy line. Thats the guide line.

Then use BigJoe's function for finding the distance from a point to a line. Then have a bunch of drawline functions that draw short lines back and forth crossing your guide line. Your first short line probably starts at one end of the guide line and goes away from the guide line at 45 degrees (you'll have to calculate!) and stops at the proper distance from the guide line. Then the second short line goes off at 90 degrees from the first short line, crosses the guide line, and stops at the appropriate distance on the other side of the guide line. Get it?

And you can randomize the process too by letting the angle and distance from the guide line vary slightly from short line to short line.

C-Dawg wrote:Then use BigJoe's function for finding the distance from a point to a line.

Did you mean Joe123's function for finding the distance from a point to a line?

Wouldn't you still need to know the cordinates before hand for distance from a point to a line? So like, now Joe has to script an inverse of his routine, where we can find a point from a lines distance. What do you say Joe? XD

Even something like creating over 100 instances of raw pixels wouldn't be so tough to do, actually, I made a weapon select screen that draws 960 pixels each frame. It's actually not too tough.

I think I've figured this out already though C-Dawg:

Lets say the line goes from 20,20 to 80,80.

For Zscript that degree angle would be Sin(45) and Cos(45). If we had a simple loop;

for(i;i<60:i++)Screen->PutPixel(2,x+i*Sin(45),y+i*Cos(45),color,0,0,0,64);

We just made a line. Now if I'm able to get to this point, I'm completely certain that some sick looking 'sine waves' and effects would be easy. But another step would be needed also; Finding the length of the line. Which would change the loop to be;

distance_of_line=Max(x-y,y-x);
for(int i;i<distance_of_line:i++)Screen->PutPixel(2,x+i*Sin(45),y+i*Cos(45),color,0,0,0,64);

So we're still missing two steps here. The first being either converting some of this away from, or to degrees...I think:

atan = ArcTan(80-20,80-20); ..In which case I have no idea how to make this degrees....But I *think* we can use radians for Sin too:

distance_of_line=Max(x-y,y-x);
for(int i;i<distance_of_line:i++)Screen->PutPixel(2,x+i*RadianSin(atan),y+i*RadianCos(atan),color,0,0,0,64);

So that might work, right?

Gleeok wrote:Wouldn't you still need to know the cordinates before hand for distance from a point to a line? So like, now Joe has to script an inverse of his routine, where we can find a point from a lines distance. What do you say Joe? XD

You can't find a point from a line's distance, you can find a parallel line.
Loci.

It doesn't work like that.

Joe123 wrote:You can't find a point from a line's distance, you can find a parallel line.
Loci.

It doesn't work like that.

Thank you Professer Science.

Maybe so, but once I know the angle and pixels, I can divide that up however I would like. So Nyah. :P

Now, howabout turning you attention towards this and telling me why the line is off by ??? degrees.

ffc script pixels{
	void run(){
		int COLOR=13;
		int a; int b;
		int c; int d;
		while(true){
			Waitframe();
			int lx = Link->X; int ly = Link->Y;
			npc e = Screen->LoadNPC(1);
			int x = Abs(e->X-lx); int y = Abs(e->Y-ly);
			int atan = ArcTan(e->X-lx,e->Y-ly);
			int distance_of_line = Max(x,y);
			for(int i;i<distance_of_line;i++){
				Screen->PutPixel(2,lx+i*RadianSin(atan),ly+i*RadianCos(atan),COLOR,0,0,0,64);
			}
		}
	}
}

Joe123 wrote:Did you mean Joe123's function for finding the distance from a point to a line?

Oops, yes.

And Gleeok - I thought draw primitives were fairly expensive in terms of processor time. You're able to execute a few hundred per tic without any ill effect? Must not be as bad as I thought.

Well more like a thousand. But it's the weapon select screen so there's no other code running, plus it's just pixels and not drawtiles or anything.

You know, I wish there was a debug variable to test processing speed. We could multiply that by say 6000 to get a rough millisecond average perhaps. So far the only thing we know is checking items and exessive drawtiles is slow, not much more. I wish there was some kind of list or something.