What exactly happens internally when pixel_x is set to a large number...

ID:1360141
 
Aug 23 2013, 10:44 am
(See the best response by Zaoshi.)
What exactly happens internally when pixel_x is set to a large number?

I am noticing some rather large lag of sorts when this first occurs (actually, I'm not totally certain that pixel_x change is the cause). I've also been told that the internal view range buffer for the number of tiles sent per client is affected by pixel_x in general, but have had no confirmation from a developer.

Finally, what would be the recommended way to display a really large animation to a set of clients where icon size is the same width and height (in pixels) as the actual client.view range and the animation must start at frame 1 at a specific tick. I'm currently doing this by setting the animation's icon to an object, and then flick()ing the icon state of the animation within the tick I want the animation to start. However, the first time this happens, the animation barely plays or plays extremely fast (like its catching up to itself).

Due to that side effect, I question the efficiency of my approach or what is happening internally.

Thanks!
Aug 23 2013, 12:03 pm
Best response
When you set pixel_x to 320, it means actual icon will be 10 tiles to the right from it's real location. To make sure it actually draws that tile it has to check all the tiles within extra range whether they contain icons with ridiculous offsets. It gets even worse in multiplayer games.
Aug 25 2013, 1:12 pm
In response to Zaoshi
Ok, I understand that then, but would then be the proper way to do this without having to increase the buffer zone? BTW, I'm setting pixel_x to like "-544" icon_size at 64.
Aug 25 2013, 1:23 pm
I'm guessing the first step is to calculate the lower left hand tile instead of a reference center. From there, your pixel_x only changes within the range of icon_size and probably does not cause alarm for the view buffer.

I am just searching for official word. If you set pixel_x over world.icon_size, does view_buffer get a new radius of +2?
Aug 25 2013, 1:24 pm (Edited on Aug 25 2013, 1:43 pm)
Paging Dr. Lummox...
Paging Dr. Lummox.

This brings up an interesting question. How, internally are shifted objects sent to the client?

I understand that an object having a bounding box of 32x32, and having an icon of 1024x768 (That's insane, I know, but... Derp), will not physically locate itself in the other tiles it overlaps, and thus will cause some problems with buffering it out of view, which is the whole reason that the view buffer exists.

However, is this the same if the object has a 1024x768 bounding box? Does the object still require the server to do more work in order to send this object to viewing clients since it resides in the contents list of every tile it overlaps?
Aug 25 2013, 2:06 pm
I'm thinking it might be this "not a bug" rearing its ugly head:

http://www.byond.com/forum/?post=117892&hl=large%20icons

If so, there's no elegant solution to the problem. Part of the issue. This shockwave attack is just too large to break up into multiple smaller icons elegantly, and due to the large area it covers, you'll be trading out built-in client rendering FPS hit for extra load on the world by writing your own built-in handler for it.

This issue, if it hasn't since been addressed, really worries me, because a number of my projects have been using 320x240 icons to handle some really complex boss mobs, and pre-generated collision objects triggered in sequence to the animation, in order to create damage zones and fight sequences.
Aug 25 2013, 3:59 pm (Edited on Aug 25 2013, 4:11 pm)
Turns out the best way for this to work smoothly with no stuttering on the first display of the large animation, you have to show this to the client upon logging in, so that it's unique appearance is cached and not seeked. Thanks to Ter13 for helping me figure that out.

To cache an appearance...

obj/thing
    icon = 'large_animation.dmi'
    icon_state = "the animation"
var/obj/thing/thing = new

client/New()
    ..()
    while(!mob) sleep(1)
    src << thing


As far as pixel_x goes, its better to just locate to the tile it would end up on, and only set pixel_x < world.icon_state. Any greater and you should recalculate the tile x it belongs to.