Mac lag and timing/sync problems

[apparition]

I can't find a utility to control the AMD graphics card other than gfxcardstatus (the dynamic switching can also kind of be controlled in Apple Preferences btw), but turning VSync on in 0.3.0 didn't help. Nor did Finish. However, playing plugged in helps a lot, which always seems to be the solution But like I said before, it didn't happen on my old MacBook ever. And knowing others have the same problem complicates things.

Timers suck.

[Z-Man]

On a Mac you could use mach_absolute_time.

Thanks! And apparently, GetTickCount() on Windows would be better than ftime (it's also monotonic), which we're using now if the HPC is unavailable or broken. Hrm. Docs say it typically has 10ms to 16ms accuracy, not 1ms, which sucks, but I suppose the same accuracy would be passed on to ftime anyway and we're smoothing the result out, assuming consistent rendering speed. All one can do, really.

[Phytotron]

Last night I was playing a bit in Mud Puddle, and I saw first dlh, then later noob_saibot doing the prediction-looking jumping (again, in my case it was throughout the rounds). The latter also lost his lagometer, completely disappeared, making it look even more like prediction.

Noob_saibot mentioned he just got a Macbook Pro. Dlh mentione dhis modem was dropping out—what computer were you using?

[Z-Man]

All three new timer functions are now used on Trunk and the new cross-round time sync code is also there. Problems of this type should disappear over time.

[Z-Man]

0.2.8.3.2?

No. That's for critical fixes only. The Mac and Linux basic timer code may be backported to the 0.2.8 branch, but they would hardly be useful; the good Linux function is indeed quite new and while my local manpage tells me about it, it doesn't actually exist yet. On Windows, GetTickCount doesn't exist on Win9x, which we're still supporting for 0.2.8 and won't drop it just for timer improvements affecting a tiny minority. And the sync code uses protobuf and exploits our protocol's internal redundant information culling, on 0.2.8 we'd have to manually do something on 0.2.8 and protocol additions there are very tricky. When we switched to protobuf on Trunk and built the backward compatibility layer, it was under the assumption the 0.2.8 protocol would be frozen. Of course, we can extend the protocol on 0.2.8 and pretend it always was that way and it'll work; we'll probably lose compatibility between new 0.2.8 and intermediate trunk versions in doing so.
(The immediate fix for the original problem reported here is in 0.2.8, though. Just not 0.2.8.2.)

tl;dr: No. Too much effort, too much lost, too little effect.

[dlh]

Mac experimental releases

[apparition]

I am most grateful and I'm happy to provide feedback in any way you need.

[Vitty]

Since trunk revision 1039 I'm experiencing this problem on linux, however it doesn't sort itself out over time. At the start of a fortress match, all the cycles are driving head on against the wall behind the enemy zone... the cycle's eventually disappear and the minimap updates every second or so of where everybody is, but the camera stays in the same position.

[Z-Man]

Are you past r1045 now? That reverts one bad decision of r1039.

[Vitty]

The problem still exists in 1054. 1039 is just the earliest revision which contains it.

[Z-Man]

When you say 'a fortress match', do you mean the pickup server in particular? That one is actually on Trunk and is sending the new syncs. I observed some strange stuff there myself, tracked it down to the timer drift detection being a little overeager to get samples. Fixed that. It's still not perfect, I'm a bit surprised that a timer drift of 0.01% apparently is normal, and the current code has some difficulties. Working on that.

[Jip]

I can do server side recordings from the pickup server for the next few matches if needed.

[Z-Man]

Nah, the data the server sends is perfect as far as I can tell.

[Vitty]

I haven't actually tested to see if the problem exists when on a trunk server. I'll do that next time I see a pickup match going on. I first noticed the problem on MB53's fortress server. I just connected to your ladle server, z-man, and the problem was there aswell.

EDIT: Just watched a few rounds on the pickup server and there was no problem there.

[apparition]

Since trunk revision 1039 I'm experiencing this problem on linux, however it doesn't sort itself out over time. At the start of a fortress match, all the cycles are driving head on against the wall behind the enemy zone... the cycle's eventually disappear and the minimap updates every second or so of where everybody is, but the camera stays in the same position.

I experience this with the latest 0.3.0 experimental release for Mac.