Nov 26 2015, 9:39 pm
|
|
Lummox JR
   |
It's probably that the icon textures are being loaded. That also explains the slowdown during an animation sequence, especially if it's better later on.
|
Are there ways to speed that up so it's not as noticeable? And what changes would you like to make in general to improve the FPS?
I'm also wondering what the optimizations were in this version, since I don't think they were documented. | |
I don't have any general FPS improvement ideas besides continuing to examine profiles for places where I can trim out bad behavior. The only specific idea I have in mind beyond that is to switch to using a texture atlas--maybe a global one, or many of them--to reduce the number of texture changes in the render. My earlier experiments with that (treating the raw sprite sheet as a texture atlas) had bleed issues, which may not be solvable without more drastic measures.
The main optimizations in 1315 were: 1) Switched from built-in dual pivot quicksort to Timsort. I'd tried this before but wasn't happy with the results, yet this time I was seeing more significant sort time in a recent log, so it made good sense. Timsort is optimized to handle mostly-sorted data, which makes it good for this situation. 2) Removed an internal call that grabbed an icon's height from its bounds rectangle, forcing a recalculation. Apparently this was calculating much more than it should have, and in any case the result of the function call was always the same as a var that was already set. There may be a couple of things I'm forgetting, but those were the big ones. #2 in particular was, I think, the real winner, as the apparent excess function calling was taking up a significant amount of the total time--a little under 10% if I read the profile correctly. | |
Pixel Realms wrote:
Lummox JR wrote: I'm no programmer but I think it may have to do with how Byond handles threading with servers. | |
Here's a new video in the latest version: https://www.youtube.com/watch?v=Yrr9rcW5kAo&
At 1:40 you'll see what I was referring to with the big drop in performance when enemies attack, though it always gets better over time. If there's anything in particular you'd like me to record, I can do that too. | |
Outside of the initial slowdown on joining the game, I think this feels better/more consistent with the timsort removed. I've not had any slowdowns when going idle and returning.
It's still sluggish overall, mind, but the lag spikes are less of a problem. EDIT: After ten minutes of playing, the slowdowns are non-existent from what I've seen. It's just the initial one that's an issue. | |
That's good to hear. I think Timsort would be really awesome to have here, but unfortunately my implementation had one thing broken, and even after fixing that I saw some serious problems that I couldn't account for. So for now it's off the table.
| |
This is just wild speculation (granted, from what I've seen using Chrome's various network/cpu profilers) but I think the cause of Chance's "initial slowdown" is similar to the slowdown you get when you enter a new area or an area populated with lots of new sprites.
I've noticed that after the client downloads the game's resources and joins the server, the browser, for each individual resource / icon, performs an HTTP request at the server. If the client's already loaded the resources, however, it shouldn't need to keep sending requests to the server - and, in many cases, redownloading the resources altogether. I think this could be solved by splitting up the resources into atlases or a global atlas, as you've previously mentioned. | |
Another issue here is that when the sprites are actually used for the first time, they get loaded into a new texture. So a piece of the sprite sheet (just the .png that is your actual .dmi icon) is snipped and made into a new image. I've seen in the profiling that that process can be significant. Atlasing would sort of partially fix that, except it'd be a matter of basically doing that on a larger scale all at once for each .dmi.
| |
Lummox JR wrote:
Choppiness I think can be averted by preloading all icons as soon as they're downloaded, effectively front-loading them. Dream Seeker uses icons only as soon as it needs to, but because it's working at such a low level it tends not to show these kinds of slowdowns. Lummox JR wrote: The only specific idea I have in mind beyond that is to switch to using a texture atlas--maybe a global one, or many of them--to reduce the number of texture changes in the render. My earlier experiments with that (treating the raw sprite sheet as a texture atlas) had bleed issues, which may not be solvable without more drastic measures. Preloading the resources sounds very promising, by the way. Was it what you were attempting to do in the second quote? It seems like the kind of optimization that could snip the problem right in the bud. | |
Another issue here is that when the sprites are actually used for the first time, they get loaded into a new texture. Javascript supports asynchronous loaders. You could reference a transparent 1x1 texture on load, and then swap the texture reference for the 1x1 texture with the actual texture you are attempting to load when the asynchronous loader completes its job of loading the texture. See the concept of promises for more information. If a game is loading assets during live play, it's best to either do it completely on the background, or to do it all in one blocking pass. Modern games don't hang up the rendering process just because something hasn't been loaded by the time it's in the viewport. | |
Do you think there will be any time for this in January? At this point our game is ready and in need of group testing, but the FPS is the roadblock preventing this, and our game only runs in the webclient.
I understand that you have a rather full plate on your hands, so sorry if I seem a little pushy here! Just very eager. | |
I promise I'll be looking into the FPS issues further this month. There are some webclient issues on my slate here so I can get started on this while I look at them, but I'm sure there will be further tests and experiments.
| |
Is this still on the cards for January, or is 510 taking more time than expected?
| |
510 has taken a bit longer, but it's close to release now. Before release I can eke out some time to take another look at FPS issues. I don't recall if you ever sent me a profile for 1319, but if you can send a new one that'd be good. The 1315 profile data probably won't be as helpful.
Mind you I can't promise I'll find anything I can act on, but I'll definitely take a look at the profiler data and see. This might need a more thorough solution like the pixel atlases I mentioned. | |
Lummox JR wrote:
Mind you I can't promise I'll find anything I can act on, but I'll definitely take a look at the profiler data and see. This might need a more thorough solution like the pixel atlases I mentioned. Yeah, I think it will. The sane approach if you want the performance to be close to DS will be preloading instead of loaded on the fly, since http isn't too fast when it comes to this kind of stuff. I figured the pixel atlases would be what you were going to look at first. Is it a very big/complicated change that you're not too eager to get into? | |
Pixel Realms wrote:
Lummox JR wrote: It's complex enough I don't think I can knock it out quickly. The proof of concept was easy, but it proved I'd have to add some boundary pixels around each sprite, and that's harder. | |
All right, that's good. I was worried that it was complicated to the point where it was a roadblock. Once your schedule is freed up so you can look at the webclient stuff, I hope to see that as a priority because I'm assuming it'll help with performance far more than trimming the fat would.
| |