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.
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. 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. I haven't tried to replicate it in a demo, but I'm still noticing worse performance when screen objects are present. Even having just one screen object will drop the game's framerate from 40 fps to 20-30 fps when the screen is scrolling. | |
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. | |
For graphical issues you'd want to be looking at Dream Seeker's CPU usage in Task Manager, or use something like Fraps to see the framerate. The number and complexity (ex: transparency) of objects shouldn't affect the server's CPU usage much at all.
It'd be nice if there was some way to display the rate a map control is being drawn at. | |
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.
| |
Ok, that's likely a server-side issue with the timing. I suspect that's also the problem with hud updates. We'll make looking into those a priority for the upcoming releases (since we'll be getting more into software changes pretty soon).
| |
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. | |
Mind you, 100 fps is problematic. Timing is difficult to get right in Windows past 60 fps, and Flash outright says any rate higher than that will be a problem. I think 50 is a much more reasonable rate.
With software rendering, I know there is definitely a slowdown when you use any alpha value between 0 and 255, because it needs to call the AlphaBlend() function to render that properly. I'd have to check the code to confirm this, but I believe if you only have fully opaque or fully transparent pixels, a much more basic drawing operation is done that uses a simple mask. | |
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. | |
BYOND has always been capable of transparency; it's partial opacity that's a recent introduction. In software rendering mode there is really no way to do alpha blending any better than what GDI has to offer, since by definition that's what the software rendering mode is. What I can check on though is whether we're using AlphaBlend() in inappropriate situations like when transparency is strictly on/off.
| |
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. | |
That's quite interesting information. The HUD slowdown is something that seems like it should be addressable if we have a good test case to work with. The fact that this is running slower in hardware mode is definitely not what I would have expected, but it seems like something we should be able to fix.
| |
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. | |
Screen objects do currently result in extra drawing (technically, each screen object is drawn twice, while each non-screen object is drawn once) in hardware-mode. This is due to the way the clipping works. We can probably optimize it, though. I didn't think it was a big deal because it seems like the drawing itself is pretty fast (and if we were to optimize this, we could likely get better performance by omitting parts of the screen that don't need to be redrawn).
| |
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. | |
Wow, that is a dramatic difference.
In my tests, standalone DS worked fine in both hardware/software mode. DD+DS was horrendously slow in hardware mode and fine in software mode. Is this consistent with your results? The fact that the standalone works tells me it is not a front-end problem, but something to do with the difference in how we communicate or bufferinformation in hardware vs software rendering. I'll see what I can find. I'm sure this is totally fixable. | |
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. | |
In my test, the DS version looked fine, but the DD-DS version had extremely poor updates in hardware mode (it was fine in software mode). I suspect it's a buffering issue, where for whatever reason it's not drawing the data it receives. Clearly the hardware can keep up with your frame rate because it works just fine in the DS-only version.
I'll look into it tomorrow. | |
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. | |
I've noticed this but haven't found a way to demonstrate the problem that isn't too subtle. It's definitely better than it used to be, but the problem still exists. I was actually planning to work on this problem this weekend, so I'll let you know what I find.