improve internal usage of appearances for pixel offsets in Feature Requests

ID:114938
 
Jun 24 2011, 12:27 pm
Resolved
Handling of pixel offsets for movable atoms has been improved, causing network performance gains for games that make heavy use of pixel offsets for smooth movement.
Applies to:Dream Daemon
Status: Resolved (489)
This issue has been resolved.
Taken from Lummox's comment in the Pixel Movement feature request:

In a nutshell, an Appearance is everything about the physical appearance of an atom or a component of one. It has information about the icon, state, text, name, direction (this can be overridden by other things), layer, overlays and underlays, verbs, mouse pointers, opacity and luminosity and other visual doodads, and pixel offsets. Whenever you add an item to atom.overlays, two things happen: 1) An Appearance snapshot is taken of what you're adding, and that's what gets added to or subtracted from the overlays. 2) Adding to the overlays creates a new Appearance for the main object, since it has a different list of overlays. (If you loop through an overlays list and use the \ref macro you'll see that they use a different internal type than atoms; however the : operator can access most of their vars on at least a read-only basis.) As another example, if you change mob.icon, a new Appearance is generated if necessary and assigned to the mob.

Appearances are sent to the client on an as-needed basis, if the client doesn't have them already. Any client that knows about the appearance counts toward its refcount, and it won't be recycled until nobody is left who knows or cares about it. Clients also periodically tell the server about appearances they don't need to hold onto anymore.

The speed problem I'm referring to here is that Appearances also contain pixel offsets. This is a good thing because it lets overlays have pixel offsets, but if you change the pixel offset of a mob it would probably be more sensible to just send an update of the offsets and send a "neutral" appearance with no offsets or at least just the defaults. If the server didn't have to create a new Appearance for these cases, it would be able to skip a few steps like trying to find if an Appearance with the correct offsets already existed and if not creating it. In a game with lots of pixel movement, this can obviously happen frequently, more so than say a change of direction. The speed benefits might be subtle but with lower tick_lag I think they may come into play more and more. This also could translate into bandwidth savings as the offsets could represent just a six-byte bump per atom instead of sending a whole Appearance to the client, with the only downside being that in theory Appearances wouldn't need to be sent after a while but the offsets still would.
#1 Jun 24 2011, 12:28 pm
Does the internal processing of things like this get represented in world.cpu or in the timing in the profiler?
#2 Jul 21 2011, 12:49 pm
To answer your question (belatedly), probably both. The generation of new Appearances would impact things like changing pixel_x. That said, the C++ profiler has given me fairly murky results on this, and I think the bigger impact here is not on the CPU usage but on networking. Pixel-movement environments over the network, particularly with lower tick_lag, show considerable improvement with this feature.

The bandwidth of a pixel change in this new system is actually 2+12n bytes, where n is the number of objects in the message (and the extra 2 are always present if the message is sent at all). However this will usually offset 10n for the appearance changes that would have happened otherwise, plus the size of the appearance message itself which was not small.

Note that this change will have no impact for older clients. The code was setup to be backwards-compatible so older clients will receive the old Appearance updates and newer ones will receive the offset updates.
#3 Jul 21 2011, 1:06 pm
Excellent, thanks. I've done some network profiling of pixel movement but ill be sure to do some more (whenever I get the time) to see the improvement.
#4 Jul 21 2011, 1:11 pm
Where I'm seeing significant improvement right now is in a little demo I threw together, and also in your pixel movement lib's performance demo.

The basic demo in your lib doesn't show the gain as strongly, but it also is running at normal tick_lag without a lot of things going. With those shooters active in the performance demo the difference is a lot stronger. Also I tried using A Miner Adventure for testing, but that one seems to perform pretty well already.

My expectation is that some games will see the change more than others. Lower tick_lag and/or more pixel movement seem to be the performance killers on the network and this update smooths a lot of stuff over.
#5 Jul 22 2011, 6:19 am
I just tested it with the benchmark demo that comes with the library. With 100 moving mobs running at 30 fps, these are the results:
v486.1095
User           Type       In    Out     Time
-------------  ------  -----  -----  -------
Forum_account  seeker  762 B  275 K  0:00:10
Forum_account  seeker  741 B  287 K  0:00:10
Forum_account  seeker  727 B  289 K  0:00:10
Forum_account  seeker  748 B  290 K  0:00:10
Forum_account  seeker  769 B  289 K  0:00:10

v489.1099
User           Type       In    Out     Time
-------------  ------  -----  -----  -------
Forum_account  seeker  759 B  217 K  0:00:10
Forum_account  seeker  763 B  215 K  0:00:10
Forum_account  seeker  745 B  213 K  0:00:10
Forum_account  seeker  763 B  216 K  0:00:10
Forum_account  seeker  784 B  217 K  0:00:10

The averages are 286 K and 215.6 K. Basically the only thing going on in the benchmark is the changing of pixel_x and pixel_y.
#6 Jul 22 2011, 7:50 am
That's definitely a significant drop in bandwidth. What I tend to see even more is a change in overall responsiveness; DS crawls during your performance demo over the network, but in 489 it's pretty fast unless something else is sucking up my CPU cycles (my system has only one core).