On Mon, Apr 5, 2010 at 2:52 AM, Guangcong Luo <za...@wz2100.net> wrote:
> Looks like the ML is back up.
> On Sat, Apr 3, 2010 at 2:27 PM, buginator <buginato...@gmail.com> wrote:
>> ...
>...
>> The network code, AFAICT, we do not have any network related crashes anymore.
>> Yes, we got sync issues, but the 2.3 series will always have them.
>> Cyp's work with newnet should fix the sync issues, but, last I looked,
>> that version will __NOT__ work with 32bit systems at this time. This
>> is both on MSVC & cross-compiled builds.
>
> What about newnet requires 64-bit support? That seem so weird...
I think (97.13% sure) that it was working on a 32-bit Linux system
with sse2, and was working on at least one mac.
If I remember right, then the only issue is it not working on w32,
even if cross-compiled with gcc. I couldn't cross-compile it myself,
and haven't seen the assembler output of fptest1() in main.c, so I
can't determine if it's a wrong-code generation, or if it's windows
messing with the floating point registers somehow. (I once had an
issue with a version of Linux failing to restore the floating point
state correctly, so something like that wouldn't surprise me too
much.)
The assembler output must contain sse instructions, not x87 fpu
instructions. And no fused-madd instructions.
As far as I understand, -msse -mfpmath=sse -mno-fused-madd should fix
32-bit floats - fptest1(), and -msse2 -mfpmath=sse -mno-fused-madd
should fix 64-bit floats - fptest2(). Since there aren't many doubles
used, it probably doesn't matter if fptest2() fails.
So, as far as I know, the status is:
Linux x86_32: works
Linux x86_64: works
Linux ARM/MIPS/Alpha/PPC/sparc/ia64/...: unknown
Mac Intel: works
Mac PPC: unknown
Windows x86_32: fails
Windows x86_64: unknown
3 possible solutions:
1. Get windows to do floating point correctly.
2. Convert everything to C++, and typedef float Float; on Linux/Mac,
and class Float { ... }; on windows.
3. Use integers only. (Fixed point, that is.)
> I think the bMultiMessages change I committed may have made the sync
> worse, so I guess it should be reverted once again. This is really
> frustrating, because it really does fix seven different bugs relating
> to bMultiPlayer having an unexpected value.
>
> (Background: Much of the code assumes bMultiPlayer is TRUE if in a
> multiplayer/skirmish game, and FALSE in campaign. However,
> bMultiPlayer can be FALSE in a multiplayer game because
> turnOffMultiMsg messes with it. I thought my code was the most
> reliable way to fix the problem, but apparently it was unsuccessful.)
For 2.3, I'm indifferent. Reverting that in trunk would probably cause
a few hundred merge conflicts with newnet.
No objections to Qt and newnet being merged as soon as possible.
I don't have any spare time at the moment. If squeezing a merge in, I
would at most be able to test if it compiles, not whether it runs.
(Should one expect 60fps via ssh X forwarding over a very unstable
network, or would it just be the usual 30fps as when running native?)
_______________________________________________
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev
