Good news

Tobi · Post by **Tobi** » 05 Apr 2006, 15:32

$ md5sum *.bin | sort
2f358dabd6806edc90935b94dbc901fd  simple-vc-2005_lib.bin
2f358dabd6806edc90935b94dbc901fd  sse-simple-g++-3.4-32_lib.bin
2f358dabd6806edc90935b94dbc901fd  sse-simple-g++-3.4_lib.bin
2f358dabd6806edc90935b94dbc901fd  sse-simple-g++-4.0-32_lib.bin
2f358dabd6806edc90935b94dbc901fd  sse-simple-g++-4.0_lib.bin
2f358dabd6806edc90935b94dbc901fd  sse-simple-mgw-3.4_lib.bin
2f358dabd6806edc90935b94dbc901fd  x87-simple-g++-3.4-32_lib.bin
2f358dabd6806edc90935b94dbc901fd  x87-simple-g++-3.4_lib.bin
2f358dabd6806edc90935b94dbc901fd  x87-simple-g++-4.0-32_lib.bin
2f358dabd6806edc90935b94dbc901fd  x87-simple-g++-4.0_lib.bin
2f358dabd6806edc90935b94dbc901fd  x87-simple-mgw-3.4_lib.bin
af9b39f8f1af3450b54ec2931a832201  simple-vc-2005_basic.bin
af9b39f8f1af3450b54ec2931a832201  sse-simple-g++-3.4-32_basic.bin
af9b39f8f1af3450b54ec2931a832201  sse-simple-g++-3.4_basic.bin
af9b39f8f1af3450b54ec2931a832201  sse-simple-g++-4.0-32_basic.bin
af9b39f8f1af3450b54ec2931a832201  sse-simple-g++-4.0_basic.bin
af9b39f8f1af3450b54ec2931a832201  sse-simple-mgw-3.4_basic.bin
af9b39f8f1af3450b54ec2931a832201  x87-simple-g++-3.4-32_basic.bin
af9b39f8f1af3450b54ec2931a832201  x87-simple-g++-3.4_basic.bin
af9b39f8f1af3450b54ec2931a832201  x87-simple-g++-4.0-32_basic.bin
af9b39f8f1af3450b54ec2931a832201  x87-simple-g++-4.0_basic.bin
af9b39f8f1af3450b54ec2931a832201  x87-simple-mgw-3.4_basic.bin

Ok without explanation this doesn't mean anything: Last few days I've had a conversation with Nicolas Brodu (thanks Nicolas!), who has been developing some tool which requires exact floating point behaviour on all supported architectures/compilers/platforms. I've been helping him with this, as he doesn't have windows installed, and today I finally managed to get the bitwise same output of his floating point unit verification program on 32 and 64 bit linux gcc-3.4 and gcc-4.0, MinGW, and MSVC 2005, with and without SSE optimizations, as shown by the md5sums above.

What this means is that playing linux vs. windows is a freaking big step closer.

If things go the way I want, the first succesfull windows vs. linux game might even be in only a few days!!

Belmakor · Post by **Belmakor** » 05 Apr 2006, 15:51

Gotta hand it to you - that's GREAT NEWS!!!

Keep up the good work!

Michilus_nimbus · Post by **Michilus_nimbus** » 05 Apr 2006, 15:55

Wonderful. Really, this opens up loads of opportunities. If only Omni got finished...

Argh · Post by **Argh** » 05 Apr 2006, 16:42

Woot! Nice job!

Zenka · Post by **Zenka** » 05 Apr 2006, 16:45

Windows and Linux sync would be the best thing that will happen to Spring since it was first released. This really kicks up the community. And allows us to abandon windows once and for all!

(does Spring runs under FreeBSD?)

Dr.InfernO · Post by **Dr.InfernO** » 05 Apr 2006, 17:53

hell yeah a hail to linux Really wanna try redhat or SuSe

SwiftSpear · Post by **SwiftSpear** » 05 Apr 2006, 18:34

Zenka wrote:And allows us to abandon windows once and for all!

Um no...

It brings spring to a place where windows development and lunix development is the same thing, so the comunity can acctually be a whole and play together as a whole. This is awesome though, I don't think there's ever been a project of this size that was able to fully support windows and lunix players playing together.

/me steals cookies from AF to give to the spring team for breaking down e-boundries everywhere!

Zenka · Post by **Zenka** » 05 Apr 2006, 18:45

SwiftSpear wrote: This is awesome though, I don't think there's ever been a project of this size that was able to fully support windows and lunix players playing together.

Well Stratagus is for Windows and Linux. I've no reason to belive there is any problems on the muliplayer part.
http://stratagus.sourceforge.net/download.shtml

Glest is made for windows, but there is a 3rd party that compiles it for linux.
http://www.glest.org/en/index.html
http://www.stud.uni-karlsruhe.de/~uxsm/glest/

and ofcourse Cube runs on a load of Operating Systems.
http://wouter.fov120.com/cube/index.php4

But Spring is best of them all

Post by **jcnossen** » 05 Apr 2006, 19:18

I've seen the ML messages ofcourse, but good to know it is really working out... :)

Glest doesn't have multiplayer though.

AF · Post by AF » 05 Apr 2006, 20:25

hmm, I'd forgotten stratagus for a second there, if I'm recalling correctly it's AI makes use of a lua script engine, but not for long *quickly adds stratagus as a possible 4th RTS engine to the unified AI interface list*

And we've still got to get omni working before you abandon windows, though I have a big surprise in store within the next year for that....... (I cant keep quiet about these things so I just hint at them)

As for cookies only I give them out *drops an anvil on switspear*

BvDorp · Post by **BvDorp** » 05 Apr 2006, 20:35

WOOT!!!!eleven!!!one!!!!

Dudes, this r0x0rz [insert more purepwnage.com trash]

Well, will this enable for a mac port too? And how's progress??

AF · Post by AF » 05 Apr 2006, 20:37

There's been work on getting it to compile under mac OS and changes have been made to the code in places, but you'd have to read the mailing list.

Tobi · Post by **Tobi** » 05 Apr 2006, 20:39

We (Nicolas Brodu and I) haven't even looked at PowerPC yet

. The new intel macs shouldn't be too hard though

, and if the PowerPC processor is IEEE 754 compatible then it shouldn't be too hard to get it working on it too.

E: Oh and about how it's going: I'm working hard to get the code into Spring so a first test can be done.

PauloMorfeo · Post by **PauloMorfeo** » 05 Apr 2006, 21:26

Tobi wrote:...
What this means is that playing linux vs. windows is a freaking big step closer.
...

But we still need a lobby client working on Linux :\

Nemo · Post by **Nemo** » 05 Apr 2006, 22:35

Win! You guys are awesome. This is absolutely brilliant, I can't wait for this to be achieved.

Fantastic work Nicolas and Tobi, keep it up =)

monohouse · Post by **monohouse** » 06 Apr 2006, 12:27

now that we're on the subject of floating points ehehe, what kind of floating point does spring use ? and what do you do with the extra 32 bits left in the athlon64 and itanium architectures ? not to mention the extra register space.....

Tobi · Post by **Tobi** » 06 Apr 2006, 13:06

Spring used to use double precision (64 bits) and single precision (32 bits) floating point variables. It did not change the FPU precision control, so internally everything (intermediary results) was calculated in extended precision (80 bits) on linux and windows+mingw and 64 bit on windows+MSVC and stored in memory in either 32 or 64 bits.

In my branch the FPU is set to pure 32 bit operation, so the other 48 bits are unused in case of 387 math. With SSE math, the 32 bit functions are just used so in theory no bits are spilled (in practice the compiler doesn't vectorize so 1/2 to 3/4 of the 128 bit SSE registers will be spilled I think).

About 64 bit architectures I can only say something about gcc+linux: in that case spring just uses 32 bit variables almost everywhere because it has not been written with 64 bit in mind. The COB code uses 64 bit though, but the upper 32 bits can't be used because then the script wouldn't run on 32 bit PCs. Using extra register space depends on the compiler used, I've no clue about that. Go checkout gcc source and see for yourself!

monohouse · Post by **monohouse** » 07 Apr 2006, 01:48

duuude use manual ASM instruction to place data into the extra register space, don't trust compilers, use different compilations for every architecture.

Tobi · Post by **Tobi** » 07 Apr 2006, 09:51

erm, and who's going to write and maintain it?

BvDorp · Post by **BvDorp** » 07 Apr 2006, 12:08

When I'm like really old, I can tell my kids their dad was the first to play a synced game of Spring between linux and winXP.

IE: this worx!

Spring RTS Engine

Good news

Good news

Re: Good news