That'll help. If you can tell me how to unlock that spell myself I can try it as well; I'll probably need to when I try to test this.
| |
It's the fourth spell in the fire tree, so bring the ones before it up to level 3 and it'll become unlockable. You'll want to upgrade the spell to level 10 for the full AoE effect.
| |
We set the fire wave's cooldown to 0 and spammed it while this taking profile: https://dl.dropboxusercontent.com/u/10657252/1336.cpuprofile
I'm assuming the user's own performance doesn't influence the outcome of the profile, since Doohl took the profile and his FPS isn't really effected by this. | |
Hey, I took a look, and fps seem a bit more stable on the webclient for /tg/station13, but not quite where I bet you'd want them to be.
https://tgstation13.org/msoshit/ CPU-20160402T215055.cpuprofile If you wanted to do a test run of /tg/station13 yourself, just grab the latest build here: https://github.com/tgstation/-tg-station/archive/master.zip (automatic latest build download link) and edit config/config.txt to enable the web client and enable auto admin (admins everybody who connects) (Or add the following to the bottom of the config.txt file) AUTOADMIN Host | |
Would more profiles be helpful by the way, or is the current data sufficient enough to work with? Other than the slowdowns during object generation the webclient is in decent shape now. Hopefully it'll play nice with those on lower spec machines in the future, too, since that's a major portion of the kinds of people who play browser games & BYOND.
| |
In the April 2nd profile, I'm not seeing any evidence that animation is impacting the performance at all. The main bad actors I'm seeing are RenderContextWebGL.activateRenderTexture() (a minor player in this, but it does point to the notion that switching to a texture atlas will help), and matches(). The latter is something that I think your jQuery scrollbar code is calling. IMO that scrollbar code is costing you more performance than you think; consider updating or replacing it.
I think more profiles would indeed be helpful, especially if you can start profiling just before or during a spell spam that drops the FPS, and stop profiling during or just after. The more of the profile that catches the bad behavior, the clearer it will be why the slowdown is happening. | |
Hmmm, I really don't understand this when moving around alone can cause FPS drops. We'll temporarily remove the scrollbar to see if that helps and take more profiles, though.
| |
I'm not saying the scrollbar is the main devil behind the drops down to 10 FPS, mostly that it's cluttering results and IMO it's hurting performance on a steady basis. But I'm more concerned by far with the serious drops, and those will be easiest to catch if you record the most severe cases and make sure the profile mostly consists of those times. E.g., if 90% of the profile is when the framerate dropped to 30 FPS, that will yield very good data.
| |
Yeah, I'll take some profiles and post them tonight. Thanks.
| |
Spawned a few hundred dragon bosses while moving about in their AoE that generates a lot of projectiles(http://puu.sh/oiO2W/d3fb6c64f6.jpg):
https://dl.dropboxusercontent.com/u/10657252/ DragonTestA.cpuprofile https://dl.dropboxusercontent.com/u/10657252/ DragonTestB.cpuprofile Exploring areas, spamming spells: https://dl.dropboxusercontent.com/u/10657252/ FireWaves.cpuprofile Standing still, spamming spells: https://dl.dropboxusercontent.com/u/10657252/ BasicFirewaves.cpuprofile | |
So far in the first two profiles, I've seen a few standout troublemakers:
- The MapAtom constructor is taking too much time for icons that aren't being displayed--they're instead copied to atoms that are displayed. (This itself is something I want to deal with eventually; I'd rather not have to copy icons, and just bring them over to the map wholesale, but that doesn't seem to be a big performance burden.) By adjusting that I think I can shave off a bit. - The Matrix.copyFromAndConcat function is being called an awful lot still, and in bad-performance cases it seems to take up a few percentage points at a time. I'm positive many of these cases are just translations, and don't need to do all the multiplications that they do. I'm going to see if I can alter this function to eke out a little better performance in the majority of cases. - renderObject and renderObjectFiltered are the biggest time sucks, some of which is due to the matrix copy-and-concat. Some of it is WebGL calls, which I'm not sure I can prune at all, but I'm looking at what's involved there. I believe that texture atlasing may have an impact here, albeit a small one. This is really just a preliminary work; I have a lot more analysis to go, so I think I can make some progress here. | |
One thing I should advise: I would recommend ditching KEEP_TOGETHER on anything that does not really need it. You turned it on for all atoms, which is really never a good idea, but for anything with an overlay it's going to always do extra work.
You only really need KEEP_TOGETHER for cases like changing alpha on an atom with overlays, and things like that. most atoms see no benefit from it. The reason I mention this is that I'm seeing a lot of cases where the renderer is flushing and switching textures, particularly in anything filtered, which shouldn't have to happen (I think) if it's showing multiple versions of the same basic object in a row. Knowing that KEEP_TOGETHER is on for all atoms in your project, I can't help but think that's a factor. | |
So I've done some testing and it turns out this isn't just a webclient issue it actually happens in dreamseeker aswell where the FPS dips from 58-59 to around 30-50 while moving, because most of my projects are around 30-40 fps this wasn't something I though of trying. But not only that but I've also done some tests using 30 and 40 fps and even though it isn't as notisable I've seen it go from 40 fps to 35-30-28 and then back up to 40 but it doesn't happen as often as it does when the game is set up to 60 fps.
60 fps Test: https://www.dropbox.com/s/mjynjmhrigavwe9/ 2016-04-18-1707-25.flv?dl=0 | |
Zasif wrote:
... Try hosting the game in DreamDaemon and then joining, as explained in: http://www.byond.com/ forum/?post=1911651&page=186#comment19297141 This is a separate issue for single-player games, I think, and warrants its own bug report. | |
Alright I'm give that a try. Brb!
EDIT: Followed those steps, issue still occures. EDIT 2: Another thing whats up with the FPS why can't we have a constant 60 fps instead of 55-58 at most. | |
I've been looking into that issue with playing directly in DS, something that seems to come up a lot in Yut Put's games. I did some profiling on Epoch but so far my results have been underwhelming; the profiling is not giving me a smoking gun.
| |
Lummox I've even tested it without anything I mean absolutly anything on the Screen and no mechanics or systems involved what so ever just the world.fps set to 60 I even ran it on a black screen map 10x10,100x100,200x200. All yeld same result drops to 30-40, and this isn't just an issue with the 60 fps the only reason we are seen it at 60 fps is because 60 fps is a higher number which means dips are higher number aswell, but you can also test this with 40 fps with 30 fps and with 25 fps, you will notice that even in those cases you will see dps dips to around 5 to 10 randomly and is definitely noticeable if you know you are looking for the fps drops even if the game sometimes still feels smooth but not really.
| |
Those random dips may have nothing to do with the webclient code. I'm interested in puzzling out the issues that happen during an exchange of fire/spells, and stuff like that, caused by player actions.
| |
Those random dips arn't webclient related they are Dream Seeker and Dream Daemon related.
Edit: I still think both are related though if it seems to happen in both Webclient and dreamseeker. | |
http://puu.sh/o3vUw/e960a1d205.png However, when I use spells like this, that generate a lot of objects at once, FPS can drop to as low as 10 for a few seconds. I'll post some more profiles a little later.