ID:2495960
 
Resolved
Old code altering client.lazy_eye automatically when the world size was small resulted in some unexpected/annoying behavior, so it has been disabled for projects compiled in 512 or higher. Also, lazy_eye and EDGE_PERSPECTIVE interacted catastrophically in certain situations, causing a constant jump back and forth on each frame.
BYOND Version:512.1477
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 76.0.3809.100
Applies to:Dream Daemon
Status: Resolved (512.1478)

This issue has been resolved.
Descriptive Problem Summary:
Normally if you move around on a decent size map, using pixel movement, part of turfs are loaded in smoothly as the client.eye follows the mob. If you set world.maxx to client.view x and world.maxy to a number larger than client.view y, or vice versa, turfs are loaded in as an entire tile instead of based on your step_size value.

Furthermore, if you use a similar setup as noted above and set client.perspective to EDGE_PERSPECTIVE, it heavily bugs out the client.eye.

Numbered Steps to Reproduce Problem:
Test Build with instructions

Code Snippet (if applicable) to Reproduce Problem:
world
maxx = 20 // Currently testing north/south camera behavior. change this to 30 to test for east/west behavior
maxy = 20 // Currently testing north/south camera behavior. change this to 15 to test for east/west behavior
maxz = 1
fps = 40

turf
icon = 'ikon.dmi'
New()
..()
icon_state = num2text(pick(1,2)) // randomizes grass color so you can see the issue

client
// perspective = EDGE_PERSPECTIVE // enable this and set maxx to 20 and maxy to 16 for even more camera oddness.
New()
..()
view = "20x15"

mob
icon = 'ikon.dmi'
step_size = 4


Expected Results:
client.eye to not bug out.

Actual Results:
client.eye bugs out.

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

When does the problem NOT occur?
The problem doesn't occur when world.maxx and world.maxy are both set to higher values than client.view x and y.

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:
Set world.maxx and world.maxy to higher values than client.view x and y.

I wonder if this connects to NSBR's gliding issues. I'll take a look at your demo Monday and see what I can find.
In response to Lummox JR
I don't think so cause I don't use pixel_movement nor edge_perspective.
This bug appears to be related to the fact that client.lazy_eye is being set automatically because of the small world view. If client.lazy_eye is set to 0 manually (can be at compile-time, doesn't have to be in New()), then the problem disappears.

However lazy_eye is behaving very badly here with EDGE_PERSPECTIVE, and TBH I don't like the auto-lazy flag here so I think I might try nixing it completely. I have a hard time believing it would mess up any legacy code, although if it did I could always make this behavior DMB-version-dependent.
Lummox JR resolved issue with message:
Old code altering client.lazy_eye automatically when the world size was small resulted in some unexpected/annoying behavior, so it has been disabled for projects compiled in 512 or higher. Also, lazy_eye and EDGE_PERSPECTIVE interacted catastrophically in certain situations, causing a constant jump back and forth on each frame.
In response to Lummox JR
Was this related to my report afterall?
In response to NSBR
No, not really a sync issue.