getting gcc and msvc to sync?

[hughperkins]

There has been lots of noise in the AI group this year about various interface redesigns that have failed or are being attempted.

The root cause is in part a desire to be able to develop using Visual Studio.

What would it take to get gcc and msvc to sync?

Off the top of my head there are two ways:
* carefully study every little detail that causes desync between these -> sounds difficult and tedious; Tobi has already tried this I'm sure; if he can't do it, I think we can assume it is impossible for all intents and purposes
* use some kind of resyncing mechanism where the different nodes in the game grid agree to resync to each other -> this sound like a generic solution that doesnt rely on everything being perfectly synced all of the time

You can see that the second solution is the one that I'm playing with in my head. I kindof think that there are probably standard ways of implementing it that exist already? I suspect there is one of those payoff curves between levels of trust and performance? and one selects an appropriate position on it.

One easy way to do it could be to make the host the master, the reference version of the game. Of course, that means the host can cheat, you can't have everything.

One would most likely need to place restrictions on numbers of units in order to reduce the bandwidth required (maybe that is why Warcraft III has tight restrictions on units?).

Just throwing the idea around really.

[hughperkins]

Did a quick google and found a presentation on syncing, that is mostly about fps, but does actually mention warcraft iii:

http://www.slideshare.net/weitsang/cs43 ... esentation

[hughperkins]

Looking around, cant find any particularly standard way of doing what I'm thinking about. Whilst it may or may not work, it looks like it would be very experimental/cutting-edge, so probably not suited to direct implementation in a production game.

[Kloot]

*sigh*

AI's can be developed in VS, Spring CAN be built with VS. Resync would
only help if the gcc/msvc desyncs were occasional and small in number,
not so much if they are very systematic due to innate compiler diffs (at
which point the bandwidth requirements become so great you might as
well switch the whole network model in the first place). Do you intend to
keep bringing this up every month?

PS. sorry for the tone, but just accept that it's unrealistic and simply not
going to happen, also the development advantages of the mingw setup
(automated cross-compiled builds, nearly guaranteed sync, etc) should
outweigh any personal desires TBH.

[very_bad_soldier]

Fixing general desync problems between gcc and MSVC by implementing a resync sounds indeed quite "hackish".
But besides personal desires, if MSVC really gives a performance boost up to 40% (someone said) this would be quite a good reason.

[AF]

We could seperate out the simulation into a library, that way as long as the simulation library is built with the same compiler we can rebuild the rest in visual studio and drop it in. This way non simulation code would gain from the superior optimizing compiler.

[imbaczek]

that would be a LOT of hassle, with C-C++ wrappers all over the place... very error-prone in development IMHO.

[hughperkins]

you might as
well switch the whole network model in the first place

That is what I'm proposing; however I was hoping that I wasnt proposing something radical, although having done a brief Google it seems that it would be.