Go back to Visual Studio builds on Windows?

[hughperkins]

Hi,

A year ago, we started an experiment to use mingw to create builds on Windows.

We went with the flow, because, we're a community, you have to go with the flow.

But... I cant help thinking... is now a time to look around, take stock, and do a post-mortem on the relative advantages/ disadvantages of using mingw for the Windows build?

Hugh

[Kloot]

Does "sync with Linux builds" count as a relative advantage?

[hughperkins]

Does "sync with Linux builds" count as a relative advantage?

Yes, I suppose it does

[AF]

Nobody has ran sufficient tests on visual studio lately to determine if that is indeed an advantage of mingw or just something thats not been contested. A lot of fixes regarding sync have occured since we switched to mingw.

This would also give windows users a large performance boost The Visual studio compilers have much better optimizations, as can be seen by anyone who runs mingw and visual studio builds alongside eachother. In my personal experience mingw builds gave a 40% reduction in framerates on my old machine.

[hughperkins]

Nobody has ran sufficient tests on visual studio lately to determine if that is indeed an advantage of mingw or just something thats not been contested. A lot of fixes regarding sync have occured since we switched to mingw.

I get the feeling that the sync needs quite a lot of hacks to work between different systems; I have a hard time imagining it will work spontaneously without effort.

That said, do you have a moment to check this? I guess we can make a VS build, and one of us runs it on our box, and the other one runs a mingw build, and we see if it works ok? (Or is it harder than this to check?)

[Kloot]

From a recent crash report ( http://spring.clan-sy.com/mantis/view.php?id=879 ):

Yeah I realized that after my MSVC build loses sync after some minutes

But if you are unconvinced and have the time, setup an exhaustive
sync-matrix experiment like the one Tobi did (which would not even
need to be as large, all gcc's >= 4.0 vs. msvc8 and 9), or just drop
it.

[LordMatt]

Isn't another advantage that many (most?) of the developers use Linux, and hence are able to compile builds for windows where they would not be if you had to be running windows to compile? Also stuff like buildbots wouldn't work on windows probably.

[hughperkins]

Isn't another advantage that many (most?) of the developers use Linux, and hence are able to compile builds for windows where they would not be if you had to be running windows to compile? Also stuff like buildbots wouldn't work on windows probably.

That is the key advantage. That's why it is mingw today.

[imbaczek]

I'm pretty sure that if somebody could fix desyncs between gcc and vc++ and setup a buildbot, we'd choose the VS build. I'm afraid it's not going to happen anytime soon, though.

[Tobi]

Yep, at least I'd choose MSVC build anytime over GCC build for Windows, but unfortunately I don't think it will sync.

Maybe it's solvable but it requires someone dedicated to it for quite some time, I wouldn't be suprised if it is as hard or harder as getting GCC on multiple platforms to sync.

[AF]

There're probably more sync bugs out there its just that rather than a mistake occuring and the client desyncing, because the compilers are all the same, its mor elikely that all the players desync at once, as a result nobody notices it and no desync actually occurs. Whereas a Visual studio build would make a different mistake and end up dropping out

[Tobi]

Desyncing all at once is impossible, definition of desync (IMO) is that state of client differs. When all desync in same way at same time the state doesn't differ. (IOW, there's no truely correct result of the simulation that each compiler can be independently compared with)

I get your point tho and yes that is the problem; because both compilers generate different code (slight) differences between clients can occur (and then grow, snowball effect blahblah)