Isometric Map FPS

Page: 1 2 3 4
ID:2251912
 
May 28 2017, 10:51 am (Edited on May 28 2017, 11:12 am)
BYOND Version:511
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 57.0.2987.133
Applies to:Dream Seeker
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
This is a very odd bug, but I've reproduced it a dozen times under my current project and I'm fairly confident in reporting it despite how odd it might sound. From what I can tell, tiles towards the top side of the isometric map cause DreamSeeker to stutter and perform poorly.

As shown.


Moving around anywhere near the top of the map will create this problem. Everything client side will begin to slow down, as witnessed in animate() calls stuttering, pixel movement dragging and generalized slowness.

Numbered Steps to Reproduce Problem:
Moving any area of the game, no matter how many tiles or objects therein to the top side of the map will cause significant performance loss. Moving them to the bottom half of the map, ie on the opposite side, eliminates the issue completely.

I've played around trying to reproduce it in a test project independent of our branch with no luck. That being said, this odd behavior must be some strange interaction, as even a small, 8x8 patch of barren turf at the top of the map performs poorly when compared to the same patch placed at the bottom.

May 28 2017, 8:42 pm
That's a very interesting result. By "top" are you referring to anything along the north or west edges, or strictly the north (upper right) edge?
May 28 2017, 8:49 pm (Edited on May 28 2017, 9:08 pm)
In response to Lummox JR
It's anything past the middle of the map, towards the north and west edges.

In our current setup, most of the areas where the white tiles are are suffering from poor performance, despite being identical to every other tile, save for visuals, under the hood. If flipped, so that it's green tiles in the northern corners, the same performance issues are present.




EDIT: On further investigation, I think it has something to do directly with map size. At higher sizes, the issues become drastically worse. I scaled the map from 200x200 to 400x400 and it is unplayable.
May 28 2017, 9:21 pm
Map size really shouldn't come into play; it's only view size that really matters. I'll look into this some on Tuesday.
May 28 2017, 9:24 pm
In response to Lummox JR
We run with a view size of 7. I've played around with the map size and shrunk it down to 100x100 and the performance issues aren't nearly as bad. That being said though, they still exist however slight and seem to rear their head as the player approaches the origin.
Jun 1 2017, 9:59 am
Any luck with looking into this?
Jun 1 2017, 10:13 am
I haven't actually gotten to it yet as planned. Too much else has been in my way yet, but it's on my list to look at.
Jun 6 2017, 8:00 pm (Edited on Jun 12 2017, 4:16 pm)
If necessary I can package together the current version of the source code.
Jun 6 2017, 8:10 pm
Actually if you have source that would be a big help. I'm looking into some webclient foo at the moment but your isometric stuff is next on my list.
Jun 6 2017, 8:12 pm
Absolutely. I'll page you a packaged version.
Jun 17 2017, 8:39 am
Any news on this?
Jun 17 2017, 10:17 am
Shoot, I may have overlooked your file. I'll take another look.

I got this mixed up in my head with Kidpaddle's issue.
Jun 17 2017, 1:53 pm
No problem!
Jun 19 2017, 1:44 pm
From what I'm seeing so far, the excess of tall icons is contributing to the problem; a lot of turfs are being treated as "extra", and I suspect some of them may be repeats. Sorting does not appear to be a significant issue.

The breakdown I have is that most of the time is spent in FillPanes(), of which about 1/6 of that is SetVisBits() (and basically all of that is getting params like opacity, luminosity, etc. from everything in view) and the rest is in another routine called FillPanes() that does things at a tile level. (There are legacy reasons for that, which I'd like to eventually get rid of.) Within the second FillPanes(), we have FillIconList() called for each of the main tiles in view, and FillExIcons() called for each "extra" turf which may or may not be a repeat of a known turf. There's also a call to fill the HUD, but that's really negligible here. FillExIcons() is taking roughly 60% of this routine's time, and FillIconList() is taking roughly 40%. Now if there's a lot of overlap, then in theory one of these routines can be made to take a lot less time and FillPanes() might be made to take as much as 40% less total--which in practice wouldn't be quite as good a savings as that.

Dealing with any potential overlap between those is a bit of a thorny problem. It may take some time to come up with good answers there.

One thing I can't figure out is why I'm seeing a huge lag spike when moving north and south at the northwest corner of the map. There's a spot there on the western edge and about 6-7 tiles from the northern edge where moving back and forth causes that spike, but profiling unfortunately choked there and I was unable to get clean results.

Another huge contributing factor is the crazy FPS. 100 is simply too high for isometric at this time, and 60 on the server side is also excessive. (Plus, it makes no sense to go with 60 rather than a nicer number like 50 or 25, because the server and client will both try to time by milliseconds anyway and 60 does not divide evenly into 1000.)
Jun 19 2017, 7:08 pm
I'll see how the performance handles at lower FPS and report back. Thanks for the lengthy investigation into things, it's appreciated
Jun 21 2017, 9:41 am
Under lower FPS the issues are still present. Understandably they're lessened to some extent, but the game is still in a state where it's difficult to have uniform performance.
Jun 21 2017, 9:50 am
Makes sense. I wasn't able to diagnose the major pause in that one spot. Maybe I'll try lowering the FPS and see if I can find more info.
Jul 8 2017, 11:29 am
Any leads on this?
Jul 23 2017, 9:11 pm
Bump
Jul 24 2017, 9:44 am
No leads yet, but I haven't forgotten it. The problem is testing this was insanely difficult due to the fact that the pause I was trying to catch basically didn't show up properly in the profiler, probably because that's exactly where it totally froze up.
Page: 1 2 3 4