Side Step

Page: 1 2
ID:265853
 
Jul 10 2008, 3:29 pm
This is what i thought of:
            SideStep(direction)
                var/list/L = list()
                switch(direction)
                    if(SOUTH)
                        L = list(EAST,WEST)
                    if(NORTH)
                        L = list(EAST,WEST)
                    if(EAST)
                        L = list(NORTH,SOUTH)
                    if(WEST)
                        L = list(NORTH,SOUTH)
                    if(NORTHEAST)
                        L = list(NORTHWEST,SOUTHEAST)
                    if(NORTHWEST)
                        L = list(NORTHEAST,SOUTHWEST)
                    if(SOUTHWEST)
                        L = list(NORTHWEST,SOUTHEAST)
                    if(SOUTHEAST)
                        L = list(NORTHEAST,SOUTHWEST)
                var/D = src.dir
                step(src,pick(L))
                src.dir = D

Used in conjunction with:
var/mob/M = src.Target
SideStep(get_dir(src,M))

What kinda method would would you guys use for sidestepping?
Jul 10 2008, 4:03 pm (Edited on Jul 11 2008, 4:44 pm)
 
proc/side_step_dir(dir)
    . = list()

    //This handles orthogonal sidesteps.
    if(dir & (dir - 1))
        var/list/l = .(dir & (NORTH|SOUTH)) + .(dir & (EAST|WEST))
        return list(l[1] | l[4], l[2] | l[3])

    //This handles cardinal sidesteps.
    . += dir << 2
    . += dir << (((dir & (NORTH|EAST)) == dir) ? 3 : 1)

    if(.[1] > 8) .[1] >>= 4
    if(.[2] > 8) .[2] >>= 4

mob/proc/SideStep() step_to(src, pick(side_step_dir(dir))


[Edit]
To offset the confusion that was that code (to most people), here's a simple way, using BYOND's built-in stuff:
proc/side_step_dir(dir)
    return list(turn(dir, 90), turn(dir, -90))

mob/proc/SideStep() step_to(src, pick(Side_step_dir(dir))
Jul 10 2008, 4:58 pm
In response to Popisfizzy
Popisfizzy wrote:
> proc/side_step_dir(dir)
>   . = list()
> 
>   //This handles orthogonal sidesteps.
>   if(dir & (dir - 1))
>       var/list/l = .(dir & (NORTH|SOUTH)) + .(dir & (EAST|WEST))
>       return list(l[1] | l[4], l[2] | l[3])
> 
>   //This handles cardinal sidesteps.
>   . += dir << 2
>   . += dir << (((dir & (NORTH|EAST)) == dir) ? 3 : 1)
> 
>   if(.[1] > 8) .[1] >>= 4
>   if(.[2] > 8) .[2] >>= 4
> 
> mob/proc/SideStep() step_to(src, pick(side_step_dir(dir))
>


Dude, seriously, do you write code for the sole purpose of confusing the heck out of people?
Jul 10 2008, 5:09 pm
In response to Foomer
Not most of the time.
Jul 11 2008, 9:35 am
In response to Popisfizzy
If so, it is customary to add more detailed comments, in the code itself or otherwise in the post. <_<
Jul 11 2008, 10:15 am (Edited on Jul 11 2008, 10:28 am)
Wouldn't strafing simply be better?
mob/proc/Strafe(var/D) return src.Move(get_step(src,D),src.dir)
Jul 12 2008, 5:02 am
I'd probably do it like you did, with some minor differences such as not using lists. Otherwise, I'd do this:

mob/proc/SideStep(direction)
    if(rand() > 0.5)
        step(src,turn(direction,90))
    else
        step(src,turn(direction,-90))


Or at least I think I'd do this, but I'm not sure if it works.

Edit: I just noticed Popisfizzy had the same idea. I guess this makes my post kinda useless. Kek.
Jul 12 2008, 5:11 am
In response to Popisfizzy
I was wondering why you bother with the complex bit operator stuff, when your second solution (using turn()) is much faster and cleaner?
Jul 13 2008, 1:41 am
In response to DivineO'peanut
 
mob/proc/SideStep(direction)
    step(src,turn(direction,pick(90,-90)))

:D
Jul 14 2008, 8:28 am
In response to DivineO'peanut
Bitwise operators operate faster. Speed is what he was aiming for (at least that's what I think he was aiming for). Turn () should already use bitwise operations (and extra stuff due to the fact that degrees is an argument), so I don't think it was necessary.
Jul 14 2008, 9:12 am
In response to Kakashi24142
The proc using turn() works much faster than the one using bits, and it's also less confusing. That's why I asked in the first place.
Jul 14 2008, 3:15 pm
In response to Kakashi24142
To put it simple, nearly all built-in procs are faster than than the operators. The bitwise operators aren't as fast as you think, either; at least not in BYOND. Internally, they have to be converted from a float/double* into an integer, have the operation performed on the fields, and then converted back into float/double.

*I don't know whether fields are internally stored as a float or a double.
Jul 14 2008, 3:24 pm
In response to Popisfizzy
Popisfizzy wrote:
To put it simple, nearly all built-in procs are faster than than the operators.

Taken generally like that, this is quite wrong - in fact operators tend to be generally faster than procs. Of course, additionally, operations done internally tend to be faster than done manually by DM ("soft"-coded).
Jul 14 2008, 3:29 pm
In response to Kaioken
Hiead found that this:
(a > x) ? a : x

Is slower than this:
</dm>
max(a, x)
</dm>
And seeing as how the first part there is rather simple, that's saying something.
Jul 14 2008, 3:52 pm
In response to Popisfizzy
I wrote:
Of course, additionally, operations done internally tend to be faster than done manually by DM ("soft"-coded).

If you do not see the point: ? does not do the same function as max() (so there is no comparing them directly to see which is faster or something to that extent). Neither does it when combined with just > for that matter, but anyway, read up. The difference is that in the first method, a lot of the function is still handled by softcode, but in the latter method, only the proc call is.

And seeing as how the first part there is rather simple, that's saying something.

It's not saying anything I haven't covered in my previous post, or that is surprising, really.
Jul 14 2008, 4:47 pm
In response to Kaioken
strafing.

mob
    var
        const/MOVE_NORMAL = 0 as num
        const/MOVE_STRAFE = 1 as num
        const/MOVE_FACE = 2 as num
        moveMode_ = MOVE_NORMAL as num

        Move(NewLoc,Dir=0)
            if (moveMode_ == MOVE_NORMAL)
                return ..(NewLoc,Dir)
    
            if (moveMode_ == MOVE_STRAFE)
                return ..(NewLoc,dir)
            return FALSE

mob
    verb
        Strafe()
            set category = "Movement"
            if(!usr.strafe)
                moveMode_ = MOVE_STRAFE
                usr.strafe = 1
            else
                moveMode_ = MOVE_NORMAL
                usr.strafe = 0
Jul 14 2008, 5:05 pm (Edited on Jul 14 2008, 5:19 pm)
In response to A.T.H.K
What the-
There's a few problems with the code you posted...
mob/Move(L,D,var/strafe=0)
    .=..()
    if(strafe) return ..(L,src.dir)
    if(src.strafing)
        .=0
        src.Move(L,,1)

mob/var/strafing=0
mob/verb/Strafe()
    if(!src.strafing)
        src.strafing=1
    else src.strafing=0
Jul 14 2008, 5:38 pm
In response to Naokohiro
Code i posted but code i didn't make, and it seems to work fine.
Jul 14 2008, 5:43 pm
In response to A.T.H.K
I didn't say it wouldn't work. It's just not a good way to do it.
Jul 14 2008, 11:07 pm
In response to Naokohiro
You're calling Move() twice. You don't notice of course, because you're moving to the same location, but since the first move changes your direction by the time you get to the second you're not preserving the strafed direction.

mob/Move(NewLoc)
    .=..(NewLoc, src.strafing ? src.dir :)

mob/var/strafing
mob/verb/Strafe()
    src.strafing=!src.strafing


Notice the idea behind this, (only) if they are strafing send their current direction to Move() for realignment.
Page: 1 2