Hey guys, remember when I said fixing the big-icon visibility issue was going to be non-trivial? This is what that means. I've basically been chasing fallout from that change all week, with a slight detour for some webclient issues.
As expected, the new map chunk change has produced a fairly typical share of errors for a change of its magnitude. As of today's release, 510.1331, I'm hoping the worst of those are finally behind us. Most of the issues have tended to present as "weird", and for weird reasons.
Today I also learned that the changes are probably going to break something (if not now then in the future) important to at least some SS13 builds: using pixel offsets to show different objects depending on which side of an opaque wall you're on. The visibility code is moving away from basing everything on the tile that the object came from, starting with out-of-bounds objects: anything more than a certain number of pixels out of normal range, and located on a turf that's out of view. So I'll need to come up with a solution soon that can preserve some semblance of the old behavior when it's wanted.
With any luck (which is to say, not very likely at all), next week I can get back to some webclient business and some of the other items on my list that have been piling up. But I think this chunk change was worth it, even if it causes a few more headaches in the days to come.
One other change I snuck into 510.1328 was one that impacts var lookups. Specifically, the var definitions for each prototype have been "flattened", so when looking up a var's info, the routines that do that no longer have to traverse their way up the type tree. MrStonedOne has reported that some routines in tgstation have seen a 5% performance boost from that, and one has seen about 20%. Improving the getting and setting of already-set vars is still on my to-do list.
It's still a little early to get too deep in the weeds on 511's potential features, but I've been letting my mind go there from time to time. So far it's looking like 510 is a huge a game-changer not only in terms of graphical capabilities, but performance, so I'm hoping I can lock that down as stable fairly soon.
Happy gaming!
ID:2050968
 Mar 11 2016, 2:33 pm
|
|
You're the best, thanks so much!
| |
@Magic: You are with goonstation right? Have you guys noticed any significant speed improvements made by the new chunking algorithm?
I know you guys are excited about the tick completion variable, but I wonder the difference that chunking made if any. Also, thanks for telling people to donate on reddit. You the real MVP. | |
Ter13 wrote:
@Magic: You are with goonstation right? Have you guys noticed any significant speed improvements made by the new chunking algorithm? The new chunking has sadly broken LoF, there's a very strange & random? lock up that keeps occurring when people move. | |
Which version are you using? 510.1331 fixed two bugs that were still outstanding. If you're still having an issue in 1331, please report it and provide some kind of test case (even if it's a matter of simply showing me where to go in the game where the lockups seem to happen most often).
| |
Lummox JR wrote:
Which version are you using? 510.1331 fixed two bugs that were still outstanding. If you're still having an issue in 1331, please report it and provide some kind of test case (even if it's a matter of simply showing me where to go in the game where the lockups seem to happen most often). alright, I'll see what I can do. | |
Ishuri wrote:
alright, I'll see what I can do. You didn't answer my question though. Are you in fact using 510.1331 on the server? That's important for me to know. | |
Okay, good to know. It would help if you can also describe the nature of the lockup in depth. And if the server is racing, it's really, really important to get some kind of debugger break-in info to find out what part of the code is being executed when it's racing. On a few semi-recent threads I mentioned how to use WinDbg to get that info from a hanging application.
| |
Sorry, I missed these posts somehow..
Re: Ter, yes, I'm with Goonstation, but I don't know how much of the performance difference is from the map chunking, although things were definitely a little better just from updating the servers to the beta before integrating the tick_usage code. Thanks for the kind words :) As for the lockups, that's interesting. We're seeing something similar, the game isn't really locking up, it's more like a stutter. On 509 we always had regular lag spikes, probably from the game code itself, either problems with the implementation or just plain too much going on. It's difficult to pin down issues with such a massive pile of code. I thought this new symptom was our same old issues, just not as severe as before, but if a completely different game is seeing something similar that might change things. I've kinda been pulling my hair out over this because it was working great in a local stress test with 20 players but now that it's live I can't get the same results with as few as 10. Come to think of it, my earlier stress test was on 1327. Huh. We're using 510.1331 as well. I test on windows but the live servers are hosted on debian and freebsd linux. It's not a hard lockup so it might be difficult to get a good dump but I'll see what we can do. Also going to try some different beta versions and see if anything changes. | |
You definitely need to try 1332, because it fixed a couple more big bugs in the chunk stuff. (There's a client-side fix coming in 1333 that's a fairly minor one and probably won't impact anything you're working on.)
| |
I love the title of this xD
| |
Okay, we just did a few tests and so far it looks like rolling back to 1327 restored the performance we were expecting. 1332 still has the inexplicable stutter. I wish I had more useful feedback for you here, if there's anything more we can do to help you figure this out let me know.
The code we're using is available at https://github.com/goonstation/goonstation-2016/tree/ goonstation-2016-byond510 if that helps. | |
MagicMountain wrote:
Okay, we just did a few tests and so far it looks like rolling back to 1327 restored the performance we were expecting. 1332 still has the inexplicable stutter. I wish I had more useful feedback for you here, if there's anything more we can do to help you figure this out let me know. Do you have any turfs with big icons (directly or as an overlay)? Do you have a lot of objects of that sort? | |
Lummox JR wrote:
Do you have any turfs with big icons (directly or as an overlay)? Do you have a lot of objects of that sort? There are only a few turfs doing that but definitely a lot of objects. | |
MagicMountain wrote:
Lummox JR wrote: I was wondering because one of the issues that was fixed in 1332 concerned a stutter effect, when entering view of a chunk that had a lot of "interesting" turfs. The actual bug that was fixed was that none of those turfs should have been marked. I suppose if you had a lot of objects on a chunk that came into view (I'm talking more than a few hundred, most likely), that could conceivably cause the same thing. Although that effect could be magified by more players. | |
It definitely gets worse with more players, and we have large icon objects all over the place, especially when a lot of graphical effects are going off (which is pretty regularly).
By the way, if we're doing something we just shouldn't be doing I'd be happy to try and fix it on our side, too. I know you can't exactly sift through our mess and figure out what's wrong with it, but you know what I mean. | |
There's definitely a correlation between more connected clients and lag.
Do you think there's a possibility that chunks that are not within a client's view are being sent regardless? That would account for the correlation there, at least. | |
/tg/station had to also roll back sybil for this same reason, bagil is still on 1332 as its low pop enough. its still noticeable, but not by much.
the shuttering shows up in world.cpu, but not profile, so its not game code. | |
http://www.byond.com/forum/?post=2050051#comment19009047