Please recheck your worst-case cases in 510.1339. I found a way to improve performance when using simple filters like color, and that seems to have been one of the worst issues impacting those cases.
I didn't, ultimately, mess with the matrix stuff. I may do that if that still shows up as a bad actor. I also intended to create a pool for the MapAtom class so it could be reused, but in practice that ended up causing more headaches than it was worth, due to the need to reinitialize everything.
As of 510.1340:
Specs- http://puu.sh/outnd/31939e741a.png Idle FPS: 60 Movement FPS: 58-60 Lowest FPS: 55 Specs- http://puu.sh/outKx/6153aa3a48.jpg Idle FPS: 60 Movement FPS: 50-60 Lowest FPS: 40 Specs- http://puu.sh/outR5/dbc0dac6c9.png Idle FPS: 45 Movement FPS: 40 Lowest FPS: 20 Screenshot of Specs: https://gyazo.com/ae796a334e112ea31bae59cbece9f717 Idle FPS: 58 (This was while inside & Outside) Movement FPS: 45 - 52 (this was while inside house) 25-35 (while outside) Lowest FPS: 18 (This was only for a brief moment while exiting the house, and it quickly popped back up.) Screenshot of Specs: https://gyazo.com/bf5e11809e043e6cbc37b5b8ce8a47a1 Idle FPS: 30fps Movement FPS: 25 - 30 Lowest FPS: 25 Screenshot of Specs: https://gyazo.com/c499952903150fe9cac26b75cd843be9 Idle FPS:(Wouldn't keep still) .7 - 8.9 Movement FPS: .8 - 5.8 Lowest FPS: .7 Notes: Constant Blackscreen so i couldn't quite tell where I was going or if I was moving in the first place, but i just assumed I was. Screenshot of Specs: https://gyazo.com/c361a4d3c918d3f23e0cfa89faea323f Idle FPS: 40.0 - 59.8~ FPS (appears to be rather smooth, no major drops below 40 fps Movement FPS: 30-45 FPS (Slight latency due to IPS issues, slight fps drop during dash movement) Lowest FPS: 20 FPS (Small choke during movement and accidental combat against boar, but suspecting that this might be my laptop) [00:08:06] Urthrem: FPS during combat/boss encounter : 40 - 50~ (No major fps drop/change during mob and boss encounter even during additional spell casts) [00:10:53] Urthrem: FPS during fire spell spam: Average 30-40 ~ with huge spikes going below to 20 during moments when the fire spell was nearly everywhere Screenshot of Specs: https://gyazo.com/7d250f9c43581210d8ae7518c8c69b0c Idle FPS: 35-30 Movement FPS: 22-30 Lowest FPS: 15 [24/04/2016 23:58:08] Chance: can you try updating chrome? [24/04/2016 23:58:53] Sabatagear: https://gyazo.com/51c93f8f305a4a8d4380272353e9a758 [24/04/2016 23:58:57] Sabatagear: I'll give it a shot. [24/04/2016 23:59:19] Chance: that's during idle? [24/04/2016 23:59:43] Sabatagear: Yeah. [24/04/2016 23:59:46] Sabatagear: Chrome's upto date. [24/04/2016 23:59:54] Sabatagear: The drop at the end was when I started moving. [00:00:00] Sabatagear: It's actually lower than earlier for some reason. [00:00:12] Chance: odd [00:00:18] Chance: and youve noticed no weirdness with your ocmputer recently? [00:00:22] Chance: while playing other games etc [00:04:05] Sabatagear: None whatsoever. [00:04:25] Sabatagear: Was playing League of Legends on Ultra, The Secret World on High and Final Fantasy XIV on high. [00:04:42] Sabatagear: Can also play Phantasy Star Online 2 on Ultra, although the bulk loading causes freezes from time to time. [00:04:55] Sabatagear: The computer was also picked up yesterday from the shop for a tune up and repair so... it's very strange. [00:05:07] Sabatagear: It was even wiped clean. I'm reinstalling things later on this evening. [00:10:00] Sabatagear: Boss, your fire wave spam just dropped me to 15 FPS. | |
The above results are of 10 random players from Eternia that I grabbed to test the FPS. 5 of them thought that the animation/FPS was choppy and not in a playable state for this type of game.
I also had those suffering from low FPS try out a HTML5 MMO on Kongregate (I went with http://www.kongregate.com/games/Playsaurus/cloudstone), none of which had any FPS drops below 55. At this point I'm a little worried, since it's been over 9 months since I created the thread and the webclient still isn't a viable option. Since our game was built with JS for all menus etc, the webclient is our only choice and we'd essentially be losing several thousand hours of work if it isn't salvageable. We're wanting to beta test but simply can't see that happening in the near future because of the current FPS. I really think it would be a good idea to opensource the webclient code. Extra pairs of eyes, such as Ter13 or the SS13 folk, might be able to point out potential problem areas as was done early in the thread. | |
Keep in mind, a custom-written HTML5 game that knows exactly what it's going to do for its display code is going to have a performance edge regardless; it's an apples-and-oranges comparison. The game those users tested may have managed display, resources, etc. all very differently from what the webclient does.
Considering five of your players didn't have any significant dips, that's really promising actually. What I need from those other five players is profile data, specifically from the spots where they saw the worst performance drops. (Also, it would be ideal if they retest after clearing their caches, because I've noticed on a couple of occasions that Chrome was hanging onto the webclient.dart.js file when it shouldn't have, and I can't rule out that there's a possibility they had an older client somehow in play.) Basically I need hard data to tell me where things are going wrong for those specific users. If they can gather multiple profiles and provide info about what was happening during each (performance, memory usage, what happened in the game, etc.), that's even better, but one profile showing a worst-case scenario is still useful. In each case where I've made headway on performance, it's been a direct result of having profiler data point out problem areas. | |
For the majority of these profiles the user's FPS was 10 or less, with dozens of projectiles and moving monsters in action.
#1 http://puu.sh/ouKmQ/b1194b1e2f #2 http://puu.sh/ouKtA/58ba7c3d74 #3 http://puu.sh/ouKvo/b9001cacfb | |
Big improvements in 510.1341. My idle FPS doesn't drop below 60 and my movement is consistently 58-60.
Today I'm going to ask the profilers from 510.1340 take their FPS again for a comparison, and I'm pretty optimistic we'll see a better round of numbers. | |
I made a number of improvements under the hood that weren't documented for 1341:
- Alpha maps for icons are preloaded and used for all mouse hit detection, avoiding costly calls to GetPixel32() on the BitmapData class. - The ArrangeAll() function was tightened up considerably to remove three internal functions. UpdateChildren() was moved elsewhere and is still a function in its own right, but NewMapPlane() and ArrangePlane() have been subsumed into ArrangeAll() directly, eliminating closures. Some of that code was originally written with JS closures in mind, but Dart2JS handles them very differently, by creating an object literal {}, filling it with vars it will share with the closures, and sending that object to the closure function. It's a safe way to handle such things, but it's not as nice as the way JS does it and because of the lack of pointers, it's not as nice as the way C++ does it either. - DwawMap(), doAtoms(), copyMapAtoms(), and copyScreenAtoms() were tightened up to remove a lot of closures as well. Particularly important was inlining for-each loops, which simply aren't handled well in the case of routines demanding high performance. - The use of FlattenFilter() for KEEP_TOGETHER objects has been removed, since it appears to be moot anyway. In a previous build it was taken out for cases where there was just one icon, but it appears to be useless now due to the way the icons are grouped and drawn. - The rendering loops for MapPlane and MapAtom were tightened up, overriding their DisplayObjectContainer parent from StageXL. The changes basically just eliminate some checks that we don't use, and also store the length of the children list in a local var for faster looping--a very old JS performance trick. Also, I fixed an issue I found with color matrices not being handled properly in certain cases, but I didn't think it was worth putting in a bug report. | |
I played around a bit and was fighting some mobs with my fire punch and whatnot. The lowest fps I got was 58. I didn't play much though, so I haven't tested the more demanding skills. Good shit though. I remember playing this game a bit before .1341 and my frame rate was like 5fps.
| |
The alpha map preloading in 1341 was actually kinda buggy, in that it didn't preload as planned--it waited until later, mid-game, whenever the icons first appeared. Bad news if a bunch of new icons appeared at once.
My new setup does preloading properly, but only for icons that are known at startup. Dynamic icons that may be created later don't get this preloading, and their mouse hits have to fall back on the old method. Considering the vast majority of icons are not dynamic, especially anymore, this is a pretty good tradeoff. | |
Oh, neat. I'm eager to check out the next update then since that looked to be the biggest performance hit... and things improved regardless with the last set of optimizations, so that'll be fun to see.
| |
That will probably end up being the stable 510 build. During 511 I'm sure I'll have a few maintenance releases on 510 with more webclient updates, though, so the webclient won't sit fallow while 511 is bubbling away under the hood.
| |
Eek, just found a massive problem in the alpha preloading: It's turning out to be a ginormous memory hog. The problem isn't obvious in a test project but in Severed World it's undeniable. I tried to alter it to force it to be as frugal as possible, but it's still using a crapton of memory.
I'm starting to think the mouse optimization was a failure; if it can't be done in a way that doesn't do massive harm to memory consumption, then it can't be done period, and the hit from GetPixel32() may be inevitable. Probably the best-case scenario would be to find out if there are massive blocks of solidness in the icon, and at least say the icon is all-solid--like for a turf set, for instance. Or I might be able to adapt my solution to never use in-depth data, and instead simply say yes/no/maybe for major massive chunks, so that at least some optimization is possible. I'll look into this further. Still going to look into the sound bug before the new release. I may scrap the mouse preloading altogether (or at least table it for now) since the improvements you did see in 1341 almost certainly had nothing to do with it, and the broken 1341 preloading (that loaded the alpha when the icon was first shown, causing delays) would have been just as bad on memory in the end. | |
Seeing less red in the latest version, and IconInfo isn't causing spikes, though there's still a lot of jank showing up. The FPS definitely feels more consistent regardless.
http://puu.sh/oU0xe/cfaf24e030.png http://puu.sh/oU0A6/6fa15d55a0.png http://puu.sh/oU0Ba/e1eb987a1a.png http://puu.sh/oU0BY/32242e3928.png http://puu.sh/oU0Ds/7b16c44c82.png Mostly image processing functions that're slowing things down. | |
http://puu.sh/oXxZn/c58e9e643f.png
http://puu.sh/oXy0G/0b20302c63.png http://puu.sh/oXy2y/bcf51a36f7.png http://puu.sh/oXy3v/934a340797.png http://puu.sh/oXy4x/1bb1e4e11d.png These functions cause spikes, but the dart code/image processing in general probably needs major work: rarely are there frames below 10ms, which causes jank/poor performance. | |
Those .png files aren't really helpful; I need actual profile results, not pictures from the live profile, that I can examine on my own.
I'm really not sure what you mean about image processing being a problem. I know that getImageData() which gets called by mouse routines can be slow, which is why I went to great efforts to try preloading alpha pixels but to no avail--Chrome has a serious bug that keeps the raw data in memory for too long instead of immediately releasing it. (Incidentally, there is one workaround you can do to help that: Set your turfs to all use mouse_opacity 2.) | |
A lot of the dart code functions take up big chunks of the resources, such as HashMap.$index, Matrix.copyFromandConcat, ByondMapdoAtoms, MapAtomRender, MapInfo.drawMap, etc etc, that sound like image processing to me, so I'm hoping the code here could be optimized further rather than more drastic approaches (atlasing).
http://puu.sh/oXJaj/3d243bb989.png http://puu.sh/oXJEt/73bb944f26.cpuprofile Lummox JR wrote: (Incidentally, there is one workaround you can do to help that: Set your turfs to all use mouse_opacity 2.) We'll apply this, thanks. We're also going to be reducing our FPS to 10 but I'm hoping that performance is salvageable at 20. | |
Pixel Realms wrote:
A lot of the dart code functions take up big chunks of the resources, such as HashMap.$index, Matrix.copyFromandConcat, ByondMapdoAtoms, MapAtomRender, MapInfo.drawMap, etc etc, that sound like image processing to me, so I hoping the code here could be optimized further rather than more drastic approaches (atlasing). Those aren't image processing at all; image processing is when you physically manipulate image data. Those are all related to map handling. As I mentioned previously it may be possible to eke some more performance out of Matrix.copyFromandConcat(), but I don't know that it'd be huge. Given the number of times it's called (that's why its usage percentage is so high), it might be worth it. The performance of some other functions like doAtoms() and drawMap() is really hard to tell without digging further into the profile, so I'll take a look soon at the profile you sent and see if I can find anything useful there. One of the big bad actors in that .png is activateRenderTexture(), which is taking up a whopping 16%. The profiles I've examined from Doohl and from myself have showed nowhere near that level of usage. That's something happening on your system at a low level, and the only way to avoid it that I'm aware of is a mondo texture atlas. However my experiment with preloading alphas convinces me that building a texture atlas at the client end is never going to work. You may find it desirable performance-wise to combine more of your turfs into single icons with many frames, especially if if they all share a theme, and likewise it'd be ideal to do the same for trees and such if you can. Fewer texture changes will mean better performance. | |
Lummox JR wrote:
You may find it desirable performance-wise to combine more of your turfs into single icons with many frames, especially if if they all share a theme, and likewise it'd be ideal to do the same for trees and such if you can. Fewer texture changes will mean better performance. I'm wondering if it'd be worth going as far as possible here, such as having all 32x32 turfs in a single file and vice versa with other sizes. This is our forest tileset at the moment: http://puu.sh/p2DEg/b1bb364b85.png | |
You should post a bug report with a demo included. If you're still getting the FPS drop while hosting with DreamDaemon, like with Epoch's issue, then it might be something different all together.