Pixel Projectiles

ID:1544790
 
Apr 14 2014, 10:09 am
(See the best response by Kaiochao.)
Problem description:
I've checked out a few of the libs, they all seem way too err...complex for what I need to accomplish.
Since I'm pretty new at programming with pixel movement I thought I'd get some opinions though.

Is there any reason I shouldn't be handling code like this for instance?

//a movement proc for testing.
Movement()

            step_x++
            step_y++
            HitCheck()
            spawn(world.tick_lag*2)Movement()


Ultimately my goal is to craft projectiles that shoot out at various angles and travel along those angles as well.

Also what would be a good way to transition into getting the proper values to plug into step_x and y when I get ready to use angles.
Apr 14 2014, 10:24 am (Edited on Apr 14 2014, 11:49 am)
Actually, you can use step(movable/atom,direction,step_size) instead. It would be much better to do it this way, because then you could use Bump() to act as a hit detection, rather then creating a procedure that constantly loops. Odds are, all of the pixel projectile libraries you've seen used pixel_x/y. If so, this is because they were created before BYOND had a native pixel movement system.

I made something awhile back you can use(provided you wish to).

**Edited script to reflect Ter13's suggestion.
atom/movable/var
    xAdd=0
    yAdd=0
    xSum
    ySum
    angle
    xDir
    yDir

atom/movable/proc
    angleMove()
        if(isnum(angle))
            xSum+=xAdd*step_size
            ySum+=yAdd*step_size
            var/X=round(xSum+(xSum<0?0.5:0))
            var/Y=round(ySum+(ySum<0?0.5:0))
            var/move
            if(abs(X)>1)
                xSum-=X
                move=1
            if(abs(Y)>1)
                ySum-=Y
                move=1
            if(move)
                Move(loc,dir,X+step_x,Y+step_y)


    angleSet(var/n)
        angle=n
        xAdd=cos(angle)
        yAdd=sin(angle)


mob/verb/TestMovement(ang as num)
    angleSet(ang)
    while(src)
        angleMove()
        sleep(10)


When it comes to pixel movement, it's something you honestly just need to learn. While you can toy around with your own methods of creating it, the sin/cos way seems to be the best. Therefore, I suggest you simply study some libraries for Pixel Projectiles and try to recreate them.
Apr 14 2014, 10:30 am
Out of curiosity, toby, why use step at all? Why not use Move()? You can perform the step in a single function, rather than having to break it up by X and Y.

You don't have to actually calculate the new turf it's going to move into, just feed it the current location, plus a modified step_x/step_y, it should do the rest of the work, and clamp your step_x/step_y variables and set the location properly on its own after the move succeeds.
Apr 14 2014, 10:47 am
In response to Ss4toby
The only issue I have with this is for non circular projectiles it produces a weird, glitchy effect each time the direction changes.
I sort of wanted to set the direction then move the projectile at the angle.
*edit : unless I'm just reading your code wrong, but it seems to call step multiple times*
Apr 14 2014, 10:56 am
In response to Ter13
 
Move(src.loc,0,step_x+step_size,step_y+step_size)

Right also works.
I'll look at this code a bit more and see if I can figure some things out. I guess ultimately what I'm confused about is how to use the angle. I have a few procs for returning an angle, but after I get the angle- then what?
Apr 14 2014, 11:11 am
You need to use trigonometry to find the x and y components.

Once you have the angle, the work is done for you, pretty much.

deltax = velocity * cos(angle)
deltay = velocity * sin(angle)

In practice, there's a problem you will notice once you get this working, and it's that your projectiles are just a little bit inaccurate. The further they move, the worse it gets.

That's because of rounding error. It can be fought to some degree by preserving the remainder before clamping the values. The engine will clamp the values for you when it's converted to step_x/step_y form, so the trick, is to get the whole number approximation of the deltax/y, and then subtract that from deltax/y to get the remainder. Store that remainder elsewhere, and keep adding to it. If it equals or exceeds absolutely 1, you need to get the remainder, and add or subtract 1 from your x/y.

You'll see what I mean.
Apr 14 2014, 11:25 am
Best response
I have a library for this: http://www.byond.com/developer/Kaiochao/absolutepositions

It includes a proc: movable.Project(Distance, Angle) which moves the movable atom as you'd expect. It also accounts for rounding error.
Apr 14 2014, 11:32 am
In response to Ter13
Ter13 wrote:
Out of curiosity, toby, why use step at all? Why not use Move()? You can perform the step in a single function, rather than having to break it up by X and Y.

You don't have to actually calculate the new turf it's going to move into, just feed it the current location, plus a modified step_x/step_y, it should do the rest of the work, and clamp your step_x/step_y variables and set the location properly on its own after the move succeeds.

To be honest, I had no idea you could do that XD.. That is simply awesome... Thank you Ter for pointing that out, it's a much simpler/effective way.
Apr 14 2014, 11:37 am
In response to Ter13
I noticed it with a lib I was checking out earlier. Interesting thanks.
Apr 14 2014, 11:37 am
In response to Kaiochao
Awesome. I'll be checking that out, thanks.