Question for Lummox:

ID:1795786
 
Feb 27 2015, 8:54 pm
(See the best response by Lummox JR.)
How does BYOND internally recognize when an object needs to be sent to the client?

For instance, let's say I have a 1024x1024 image, and a 32x32 tile size.

I've heard Lummox say in the past that BYOND sort of buffers the view sending distance to the largest possible offset that needs to be sent for every client in the world once a large icon is used. Is this still the case? If so, would this not make a single obscenely large object render the entire project's view sending algorithm completely untenable?

Or does it manage it by something of a quadtree by stuffing the minimum visual bounds of an object into a subdivison?


Also, a second question: Are there plans to fix the problem that objects scaled and rotated by matrices still use the AABB of the untransformed image, rather than the AABB of the transformed image for view sending?

What I mean is:

This is the unmodified AABB for the image that determines its physical footprint in game.
x1 = x*TILE_WIDTH + bound_x + step_x + pixel_x
y1 = y*TILE_HEIGHT + bound_y + step_y + pixel_y
x2 = x1+icon.width
y2 = y1+icon.height


Whereas, when you scale an image up, if you move past the original AABB's coordinates, the scaled image disappears as though it's icon ends there.

Is my assumption correct that having a single really large icon would increase the artificial view-sending bounds for every player in the world, thus increasing the network bandwidth on a per-player basis, and secondly, is there a plan in place to fix the objects' footprint not being based on transformed coordinates?
Feb 27 2015, 9:46 pm
Okay, I tested this with a single 1024x768 object. It didn't make a difference to the amount of network communication being sent to the player. So that just leaves me second problem: Is there any plan to fix the bounding algorithm for transformed objects?
Feb 28 2015, 5:58 pm
Best response
There are no current plans to deal with the whole footprint issue, no.

As for how the server decides what to send: Every tick, the server checks every turf (with contents) within the mob's (or rather, the eye's) view range, plus a little padding. All the movables on those turfs are recorded, and if they've changed appearance, location, offset, etc. that update info is sent to the client.

Turfs are slightly different. Prior to 505, any appearance change on a turf would refresh the entire turf map. The turf map bounds are bigger, and when the eye moves a certain distance from where it was, the client is told about the map change and given info about the new turfs. As of 505, most simple turf changes do not refresh the whole map, but instead trigger a smaller message.