Dec 5 2017, 2:43 pm
|
|
Lummox JR
  |
I've been looking into this some more, and the profiling has actually revealed a couple of places where I can cut down on some times. I think the gains might be small yet, but they're worthwhile and they appear to be capable of impacting client performance across the board, not just in isometric.
|
Further update: It looks like the test project is still running a bit slow, but I think there's more going on here because it was actually performing better earlier today.
My profiling results are a bit strange and hard to interpret because a number of measurements have changed way more than I expected them to, but the routines I just worked on optimizing are showing results consistent with--and indeed much better than--what I expected. So I need to look into this deeper, but it looks like the optimizations took. There's still something gumming things up a bit but things are at least moving in a positive direction. | |
This is great news!
| |
Your game is still slower than I can properly account for, though.
Looking at the code, I've seen a few things that might help. The Snow Trees icon for example is broken up into tiles, when it would be much more logical to use a single tile. One of the forest tree icons you have has a base and a top, when they could very easily be a single icon. Anywhere you can switch to using a single icon instead of several will be a benefit, plus anywhere you can switch from an obj on a turf to an overlay on a turf will show an improvement too. Scenery appears to be chewing clock for your game. I was surprised in the profiling the first time around (the second time didn't show this so much, which I think is more of the inconsistency I mentioned) that the number of calls to GetObjItileList() was almost as high as the number of calls to GetTurfItileList(), and it took longer. Switching to 50 FPS is likely to help you a lot too. 60 is not a friendly speed for BYOND because it does not divide evenly into 1000. At 50 FPS, it's easier to keep ticks on track since they're supposed to be 20 ms. The game will still have higher-speed graphics and movement than a vanilla project, but it will be 20% more responsive and there's less likely to be any tick hiccups from trying to keep on track. 40 FPS, which also divides evenly into 1000, would of course be even better with a 50% responsiveness bump. | |
Thanks for this feedback, I'll incorporate these changes and see where that leads us.
| |
We changed our big atom snow trees to a single icon, but a width beyond our world icon_size of 64x64 creates rendering irregularities. Turfs disappear, underlays show over their parent turfs..etc.
This is documented in the reference on isometric, but it still does present a problem. | |
Additionally, there's another documented, but roadblocking problem. With tiles & pixel_z being expensive to render, isometric is difficult to get looking right and since we use it in abundance, it looks like it is one of the main cause of our slowdowns.
In a test today I completely removed our use of pixel_z, and we gained significant performance. Is there any hope of this being optimized to be more useful in isometric, or are there any suggestable work arounds for it? Would using matrices solve the issue? | |
I don't understand what you mean about pixel_z being expensive to render. The pixel_z value has no impact whatsoever on sort order or on any calculation of an object's logical bounds. Same with pixel_w.
| |
It's my understanding that pixel offsets on atoms will mark them as extra and cost a bit more to render. In isometric, using up and down offsets is the generally accepted style, since the advantages of isometric is having that height map.
Unfortunately using these in abundance leads to some pretty big slowdowns. I've switched everything to instead translate their transform for the same effect, but I'm unsure if these operate similarly internally. | |
Well, pixel_z will impact the visual bounds the server is aware of and therefore could potentially mark the object as out-of-bounds, but that's generally not going to be an issue for you. Translation would have the same effect anyway.
| |
Right, okay.
| |
While we're on the topic of FPS, I've found that after a multitude of tests that having a World and Client FPS of 80 drastically preforms better than any FPS I've tested in 2D mode. I'm wondering if there is a reason for this. It is view-ably more smooth than setting them both at 100. And I get strange stuttering at 75. I wasn't sure if it was to suffice as a new report because I don't really have any info on what could be causing it, I can only offer the project I'm working on as an example because it seems to be less impactful on a world with less different kinds of objects in it. Using windows 10 pro 64 bit with latest BYOND version (non-beta) . If lummox could provide his email I'll send it over with instructions on launching the game.
| |
I'm kind of surprised 80 works so well for you, because it doesn't divide smoothly into 1000. I'm rather less surprised 75 has more problems, because it divides even worse.
| |
To be honest, I'm less inclined to believe "feel" reports from people that are running garbage hardware until which time we actually get some client-side profiling tools.
#sorrynotsorry | |
Ter13 wrote:
To be honest, I'm less inclined to believe "feel" reports from people that are running garbage hardware You must have missed my numerous posts in the discord of my new rig, ter-sama :) https://pcpartpicker.com/list/ysR67h | |
Client profiling was actually quite high on my list for 512, but I ran into a weird issue at one point where I discovered there's really no good way to profile anything. The routine I was relying on as a high-precision timer is in fact way more unreliable than I thought, as I discovered at one point while trying to profile the drawing stage.
| |
Any news on this for the new year?
| |
Just a bump as this is still an issue. The performance improvements this year helped significantly but we still suffer from pretty serious performance spikes.
| |