ID:991683
 
Not a bug
BYOND Version:496
Operating System:Windows 7 Home Premium
Web Browser:Chrome 21.0.1180.89
Applies to:Dream Seeker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
Camera which works perfect with straight movement, cannot keep up to mob that moves diagonally.
EDIT:
Sorry, I made a mistake: it's the mob who cannot keep up to the camera. Mob while moving should be at the center of client's screen and it's not in this case.

Numbered Steps to Reproduce Problem:
- Hold down your keyboard key for diagonal movement

OR

- Just press diagonal key, then quickly hold down arrow key for straight movement


Code Snippet (if applicable) to Reproduce Problem:
world
fps = 25
icon_size = 32

client
glide_size = 4

mob
var/canmove = 1
mob/Move()
//var/delay = 3
if(src.canmove)
src.canmove=0
spawn(3.26)//((32/delay*world.tick_lag)-1)
src.canmove=1
..()

PS. spawn's argument which is 3.26 is my own number that I discovered to be good delay for perfectly smooth movement for my world.fps and client.glide_size settings.

Download demo:
http://www.sendspace.com/file/olfm4q

Video:
http://www.youtube.com/watch?v=mbW4Z6NNx0Q

- to 28th second mob is moving straight and you can see that camera works perfectly
- at 29th second I start moving diagonally or combining diagonal movement with straight movement




Expected Results:
Camera moving as smoothly when mob moves diagonally as when the mob moves straight

Actual Results:
Camera can't keep up when the mob moves diagonally

Does the problem occur:
Every time? yes
In other games? yes
In other user accounts? yes
On other computers? yes

When does the problem NOT occur?
When mob's move delay is greater - spawn(5) instead of spawn(3) in my example (but then moving straigh looks delayed)

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

Workarounds:
I don't know
I don't think this is a bug. You've set client.glide_size but haven't set the mob's glide_size. Ordinarily the client will use whatever the mob uses, but here you've told it to use a hard-and-fast value for the client without doing the same for the mob. Therefore they can easily get out of sync. The mob will use the "acceleration" model--in which it attempts to find an ideal glide speed based on its movements--when a glide_size isn't specified. The client meanwhile has been constrained to a 4-pixel glide. The gliding code is doing exactly what you told it to do.

Set your mob's glide_size to 4 and see if the problem persists. If it does, we may have a bug. If it goes away, no bug. Similarly, you should also see good results if the glide_size is set for the mob but not the client, since the client will use whatever the mob uses unless you specify otherwise.
I've added mob's glide_size = 4 and it partially fixed the problem. Now the mob is always in the center of client's screen, but when I move diagonally now, the screen moves too slow and creates jump effect - tested at delay = 3.266

I increased delay to 4.666 in order to see how the screen will act then. When moving straight, because of the high delay value; camera had to wait for a split of second before start gliding to the next tile. Continuous diagonal movement didn't cause any noticeable stop in camera gliding as straight moving did.

Video:
http://www.youtube.com/watch?v=7vzD7UVdd0A
- at 26th second I change delay from 3.266 to 4.666

Updated demo:
http://www.sendspace.com/file/d2pqgq
Based on your description and the new video, everything is working as expected, so I'm closing this as a non-bug.

The reason you're seeing a slight jump effect when moving diagonally is that your movement delay is calibrated for cardinal directions, not for diagonals.

Gliding in a diagonal direction takes longer because it accounts for the angle of movement. That is, a glide_size of 4 doesn't glide by 4 pixels in both the x and y directions; instead it glides by approximately 4/sqrt(2) in each, which is about 3 pixels. Therefore to achieve the effect you want, you need either a longer delay on diagonal movement or an updated glide_size.

Alternatively, you can leave glide_size alone and let the built-in acceleration system calculate it on the fly for you.
Lummox JR resolved issue (Not a bug)