client.fps gliding flicker

Page: 1 2
ID:2195503
 
Jan 2 2017, 8:27 pm (Edited on Jan 9 2017, 4:41 pm)
Resolved
BYOND Version:511.1366
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Chrome 55.0.2883.87
Applies to:Dream Seeker
Status: Resolved
This issue has been resolved.
Descriptive Problem Summary:
So I set client.fps to 40 and call for mobs to follow me (walk_to(ref,trg)) at every 10 ticks, and they flick a lot! (This doesn't happen to me)

world
    icon_size = 32
    view="32x32"
    fps = 20


Here are some gifs (sorry for poor quality):
Sideways

Diagonally


Expected Results:
Smooth, as it is without setting client.fps

Actual Results:
Flickering.

Does the problem occur:
Every time? Or how often? Every time
In other games? I assume so
In other user accounts? Yes
On other computers? I assume so

When does the problem NOT occur?
Happens every time :(

Workarounds:
None that I know of.

Jan 2 2017, 8:36 pm
I can confirm that client.fps still has a bit of chop or clunk that only seems to happen to gliding objects periodically.
Jan 3 2017, 2:05 pm
So to be clear here, the problem is that the pursuer isn't staying in sync with the pursued?
Jan 3 2017, 2:06 pm
In response to Lummox JR
Yes
Jan 3 2017, 2:08 pm
Okay, good to know. Assuming they're moving at the same time, there has to be something about the glide here that I'm missing. Any chance you could get this to happen in a simple test project?
Jan 3 2017, 2:15 pm (Edited on Jan 3 2017, 3:04 pm)
In response to Lummox JR
I'll try sending you one in a few minutes.
Jan 3 2017, 2:49 pm (Edited on Jan 3 2017, 3:05 pm)
In response to Lummox JR
Sent you a demo download link on PM.

Edit: If this could be adressed aswell (Mobs keep swaping locations wich eachother. Not sure why).
Jan 3 2017, 4:48 pm
In response to NSBR
NSBR wrote:
Sent you a demo download link on PM.

Edit: If this could be adressed aswell (Mobs keep swaping locations wich eachother. Not sure why).

Am I the only one laughing out loud at this gif? Dude... the blue guy makes me feel sad
Jan 3 2017, 5:06 pm
In response to Inutaishos
That's a representation of my life.
Jan 5 2017, 11:44 pm
In response to NSBR
NSBR wrote:
That's a representation of my life.

We've all felt like blue or green people at some point in our lives.
Jan 6 2017, 12:21 am
In the demo, I see a lot of stuttering in the NPCs' movements if I'm not running; they're running themselves, which is generally causing their move routine to make them catch up to me quicker. If I change the running=1 line to running=M.running, that issue disappears, so I assume this is not part of the bug report.

The "swapping" isn't actually swapping; the mobs are simply finding other paths to the target that involve diagonal movements, and it's possible for those paths to cross. So no bug with that part.

What I am seeing, and this is gonna be a royal pain to diagnose, is that every now and then when I'm moving and they're moving after me, there's a "jump" where they all seem to fall out of sync with me. I'm not entirely convinced this isn't just an artifact of the weird NPC movement loop behavior; that NPCAI() routine coupled with NPCWALK() could simply be setting up a super weird timing scenario, since NPCWALK() doesn't maintain its own loop and NPCAI() sleeps for 1s every time.

So I'm seeing some jagged movement here, although I can't rule out some kind of timing sync issue caused by the movement logic. The next logical step is to add something that always tracks my position every time I move, in 1:1 sync, without any limitations on its own movement loop. If that gets out of sync with me, I'll know something is up.
Jan 6 2017, 5:46 am (Edited on Jan 6 2017, 5:58 am)
In response to Lummox JR
Lummox Jr. wrote:
In the demo, I see a lot of stuttering in the NPCs' movements if I'm not running; they're running themselves, which is generally causing their move routine to make them catch up to me quicker. If I change the running=1 line to running=M.running, that issue disappears, so I assume this is not part of the bug report.

I changed the line like you said and I can still experience it. Here is another gif (I'm with running=0 on it)

As you can see, the mobs are still stuttering a little.

Lummox Jr. wrote:
The "swapping" isn't actually swapping; the mobs are simply finding other paths to the target that involve diagonal movements, and it's possible for those paths to cross. So no bug with that part.

But they're moving at the same time with the same speed to the same dir. I think this shouldn't be happening.
Edit: It seems to happen only when the mob and the usr are with different speeds and the mob reaches the min distance.

Lummox Jr. wrote:
What I am seeing, and this is gonna be a royal pain to diagnose, is that every now and then when I'm moving and they're moving after me, there's a "jump" where they all seem to fall out of sync with me. I'm not entirely convinced this isn't just an artifact of the weird NPC movement loop behavior; that NPCAI() routine coupled with NPCWALK() could simply be setting up a super weird timing scenario, since NPCWALK() doesn't maintain its own loop and NPCAI() sleeps for 1s every time.

I'm entirely sure it's not anything related to the movement loop since I've already tested it with different, big, time sleeps and with no loop at all.
Jan 6 2017, 9:32 am
JR, not Jr.
Jan 6 2017, 10:56 am
In response to Lummox JR
Lummox JR wrote:
JR, not Jr.

I literally laughed out loud reading this.
Jan 6 2017, 11:07 am
When I retested this with a change that forces other mobs to step in sync when I move, and removes their movement logic and restrictions entirely, the problem went away completely. That is, I made sure their moves were perfectly synced with mine, and as a result the glides were perfectly synced as well.

These are the specific changes, aside from commenting out all references to NPCAI and NPCWALK:
        // in atom/movable/Move():
        if(istype(src,/mob/player) && next_move>world.time+0.001) return 0<

mob/player/Move(newloc,newdir)
    . = ..()
    if(.)
        for(var/mob/M in orange(src))
            step(M,newdir)

I'm quite certain now that if you hook up some output to this to say exactly when each mob moves, you'll have data that shows the glitches correspond to times when their moves did not happen at the same time as the mob they followed or at a consistent offset time.

However, here's where things get really interesting:

mob/player/Move(newloc,newdir)
    . = ..()
    if(.)
        for(var/mob/M in orange(src))
            spawn(world.tick_lag) step(M,newdir)

When spawn() is in play, the moves once again show a susceptibility to glitch out and go out of sync.

I think the next stage of testing will have to involve setting up a movement scheduler to see if I can eliminate any timing variables.
Mar 6 2018, 4:33 pm
In response to Lummox JR
Any follow ups on this?
Nov 24 2018, 9:22 pm
In response to Lummox JR
Still waiting on you :)
Apr 26 2019, 8:05 am
Bumping.
Jan 14 2020, 9:28 am (Edited on Jan 14 2020, 9:58 am)
You were going to follow up on this but I've discovered something. I was seeing the stuttering when my client fps differed from the world fps. When setting both to the same value, the stuttering stopped. (That along with your suggestions and pointers, wich by themselves didn't fix the issue)

world.fps=20/client.fps=40 = stutter
world.fps=40/client.fps=40 = no stuttering
Aug 13 2021, 3:37 pm
I'll need a current test case for this if there's still an issue. Timing has been changed a lot so I kinda doubt there's much left to see here.
Page: 1 2