Something strange I just noticed about Monster Kingdom's CPU usage: When in the outside/city area, CPU usage fluctuates around 3-6%. However, if I go inside a cave, the CPU is at a steady 0%.

This usage seems to be caused by a transparent fog effect that I have over the area, and from a few animals I have wandering about. The effect from the moving animals is definitely worse when combined with the fog effect, and the fog doesn't seem to be an issue unless movement is involved (be it the player moving, or things moving around, even out of view). This is all when running locally, so I'm not sure if the effect is from the client sided rendering dragging down the server or what. Either way, it seems odd that such simple effects would cause such a large hit to CPU usage. Using 5% CPU per player limits a server to a mere 20 players before it maxes out.

EDIT: After testing on a remotely hosted server, it seems that the issue similarly exists. Testing wasn't as thorough, but being outside uses CPU, while being in a cave uses none. So I'm not sure how tied to rendering it is.

EDIT 2: I have also changed world.fps from 30 to 60 in this update, and increased the speed at which systems ran for a hopefully smoother experience. This seems to have worked, however, I may be experiencing the same slowdown that people were complaining about. Movement still works smoothly, and at the same rate (which is what they were specifically complaining about). However, battle effects (which are screen objects) seem to move at double speed when playing on the server vs running locally.

Forum_account wrote:

I'm confused, is the CPU usage on the client or the server? If it's on the client that's not as big of a deal.

Its the server's CPU, but at the time, I was running it locally, so technically they were the same thing. As far as I know, there isn't even a way to pull client.cpu you like you can world.cpu. The official server seems to be using about 3-4% per player for now, next update I'm going to disable fog and wandering NPCs, and see how that effects the overall server performance. Preferably, it should be using <1% per player.

flick()ing screen objects seems to perform terribly. I have systems updating icon_states every tick, and an attack animation flicked in front of them. The icon_state updates run decently, but the flick() animation only seems to update like once a second. It also seems to be a problem when flicking a fade out effect, which is a single tile object spanning the screen.

The current version is running at 100fps. One of the people that was complaining about slow movement when playing locally, is now saying that server play is animating movement (icon_state wise) in slow motion, but moving at normal speeds.
EDIT: Seems like a lot of people are having this issue, even after lowing world.fps to 50
EDIT 2: It may be an issue with hardware vs software rendering. Software being problematic. For some people, hardware mode even seems to fail just by logging in.
EDIT 3: Stretching graphics seems to impact this issue as well.
EDIT 4: When running in software mode, I can notice the movement speed slowdown when running locally as well.

Well, 100FPS provides sleep() type functions with a proper scale. Where sleep(0.1) will actually sleep for that amount of time. 50FPS also provides such a scale, but to a minimum of 0.2. Using something like 30 or 60 for world.fps provides a fractional amount for the minimum sleep times, which I'm not sure if BYOND still rounds down input sleep values or not, but either way, programming around fractional sleep delays seems awkward. Games only seem to draw at the maximum frame rate when necessary (unlike Flash apps). So it seems like 100FPS could just be an internal performance boost available when necessary.

It is understandable that more effort has to go into processing transparent graphics. However, the massive hit to performance isn't quite as acceptable. Every available game engine that I know of is capable of transparent graphics (which BYOND hasn't been until somewhat recently) and they can all handle it with no noticeable change in performance. On BYOND, they can drop you into a practically unplayable state.

More info about screen object performance:
Converting HU2 to pixel movement has made screen objects performance impact more apparent.
If I shoot a ki blast, it will smoothly move across the screen. However, if I power up after shooting a ki blast, it will cause severe lag due to the HUD bar icon_states updating (I have tested this by disabling them, and it is definitely the cause).
If I try this when running the game locally, it seems to drag down the entire game, not just dropping the visual frame rate, but lowering the actual speed that ki blasts move. The updates here will still be somewhat smooth, just a lot slower overall.
If I try it by connecting to a daemon instance, then it only seems to cause local lag. The ki blasts, as well as the health HUD will have very skippy looking updates. Instead of actually moving slower, the ki blasts will just graphically hop several tiles at a time here.
That is all when running in hardware mode. When running in software mode, the problem appears to be completely non-existent.

I'm working a simple demo that causes the lag (not having much luck thus far). From the looks of it, though, updating screen objects causes the game to draw twice as often? Moving an object across the screen with a 0.2 delay causes an FPS (according to Fraps) of ~60 (with world.fps set to 60). However, updating the icon_state of a screen object every 0.2 causes an FPS of ~120. I can't test this against software mode since the Fraps overlay won't show up...

EDIT: After a little more testing, and under the assumption that screen object updates are somehow causing the game to draw additional times; It seems like the issue may be caused by having the screen update out of sync with in-game objects. ie: A mapped object moving every other tick, and a HUD bar updating every tick. Still working on this demo to get a clearer example of the lag.

EDIT 2: Though its hardly noticeable visually, I have gotten the demo to present a slowdown. Using a spawn(10) and comparing world.timeofdays provides a correct 10 delay without updating HUD icon_states. When updating HUD icon_states, this delay extends to 13. 12 if spamming the HUDed verb. Still trying to see if I can get the demo to drop as low in visual quality it goes in HU2 or MK.

EDIT 3: It appears that map complexity may effect the issue as well. Moving to a map area of nothing but solid green turfs lowers the extended delay to 11 or 12. While moving to an area covered in mobs raises it to 14 or 15.

Anyway, here is what I have so far. I also threw another edit onto my previous post, not sure if you saw it.
EDIT: Also, though there is the option of shooting blasts in that demo, that seems irrelevant. The HUD updates alone will cause a drop in performance, with or without map updates going on.

I didn't actually test that demo with DD myself, but the HU2 issue appears to be present in both, so I would assume its the same here. The difference is just in the delivery. The player's game drops to says 50% performance either way. However, in DS, this effects the server running the code, so the entire game just goes into a softer slow motion. Whereas with a DD connection, the client is only updating at half the frame rate, but the server is still running at full speed, so the data updates appear jumpy.

Were you noticing a major timing difference in DS vs DD? I would think the DD hosted version could always perform the tasks in the proper 10 ticks, while the DS instance would take longer.

EDIT: I just tested with DD, and the above inferences do indeed seem to be the case for me.
You may also be able to notice the severe slowdown in basic animations when connected to DD (in both software and hardware modes)? It plays each frame for nearly a second on my machine, instead of the assigned 1/10th. But runs fine in DS. There also seems to be a general slowing of movement speed, which I have no explanation for at the moment. It may just be due to slower visual updates.

You may think it looks fine (that's why I was trying to get a clearer visual from the demo) but if you'll note the output time comparisons; they should account for an overall decrease in execution time with DS (they should be 10). From what I can tell, even though the game still seems to be drawing at x fps (or even x*2 fps), it only seems to be processing at say x/2 fps. This provides a still smooth looking, but far slower gameplay experience. When you're connected to the server, the server isn't being hindered by whatever graphical issue this may be, and therefor still runs at the full x fps, but since the client is only running at x/2 fps, it graphically updates things half as often, but with data from the full x speed, making them look jumpy. It basically seems to be the same graphical flaw on both the client and the server, but the server-side slows down the entire game, while the client still receives timely network updates but only graphically draws them at half speed.

On a vaguely related note, if you scroll a browser control using the mouse wheel (by holding it down and dragging) it will freeze the game. If you're the host, this freezes the entire server for everybody, if you're just a client, then your map simply stops updating, and jumps to the new point when you stop scrolling.

I also edited my previous post, in case you hadn't noticed.