Spring RTS Engine

Great, it compiles now.

TLS appears not to be working. This causes the deadlock.

Boost 1.36... well, I'm not surprised they changed the atomic_count.
Some essential features were definitely missing

Gentoo linux, gcc 4.3.1 for mingw cross compiling.

I'm afraid I don't have a Linux machine, so I would need some more info to crack this one.

Just tested 6329, Spring hangs on Finalizing step, every time, every mod, every map. Drat. Are you compliling with or without multithreading (/D USE_GML)? Auswaschbar just told me it hangs with multithreading+mingw. I have not been able to test it because the linker crashes on my system (gcc-4.3.0-...

I don't know if I dare open my mouth, but maybe you can settle this argument by posting a poll here on the forum? Multiple lobby clients is going to be very confusing for the developers, and the quality of the software will degrade. Edit: It is probably best if neither AF nor satirik post this poll....

issues left to fix which I have no idea how to: rts\Rendering\UnitModels\s3oParser.cpp: In member function 'void CS3OParser::DrawSub(SS3O*)': rts\Rendering\UnitModels\s3oParser.cpp:302: error: 'GML_FUNCTION_NOT_IMPLEMENTED' was not declared in this scope rts\Rendering\GL\VertexArray.cpp: In member ...

You should be able to use older versions of GCC again, since I have removed the TLS requirement if multithreading is disabled (which it is by default). Define _GML_ to enable multithreading.

You need GCC 4.3.0 or higher to compile now because the multithreading library uses thread local storage. I'd recommend 4.3.1 since 4.3.0 seems bugged.

Edit: We need to change the mingw download instructions on this website so it points to a version that works :)

Yes, now that most (all?) GL calls seem to be removed from the sim, it would be possible to do something like that.

Some units rendered one frame ahead could make the animations a bit jerky. Not a big deal, but I'd prefer a solution that did not have this problem.

Fixed. Some compilers don't like when it's defined inline in both the header and the source file.

Kloot wrote:Fixed (again).

Sorry, I'm the guilty one... I changed it to make it compile with MSVS.

Roughly 15-20% when you have many units on screen and/or high terrain detail. It does not seem to benefit much from more than 2 cores since a single thread makes all the GL calls anyway.

The real gain would come from multithreading the Sim which is, to say the least, utterly difficult.

The reason for doing this was to make sure the single-threaded performance did not suffer even the tiniest bit. I'll see what I can do.

I just made some MSVS specific fixes related to the above and noticed that it can't find "dirent.h". This file is located in C:\dev-cpp\include. I don't want to hard-code the above include path in MSVS. I tried using things like %MINGDIR%/include etc. but MSVS does not recognize the enviro...

Please note that my library is based on the assumption that all files that require GL should include mygl.h. Including gl.h, glext.h, glu.h etc. will make the multithreading code fail to run.

Could be, but I did not include any math.h in my changes so maybe it is included somehow by boost?

Please note that for me it compiles just fine with scons/mingw/gcc4.3.0.

Now it spams lots of errors about ambigious overloaded function calls (sin, cos, sqrt etc.) Does it compile if you remove this code in lua_include.hpp ? #if (BOOST_VERSION >= 103500) #undef _CMATH_ // workaround to make it compile with MSVC + Boost 1.35 #endif I had to insert this very ugly "f...

OK... it is in trunk now.

I added a special Release+MT configuration to the visual studio project that enables the multithreading stuff.

Thanks Koshi! Patch has been applied. I'm happy to hear it compiles and even runs. However, I'm unsure about any possible performance gains on Linux, because I had to resort to using mutexes instead of volatile optimizations. I won't update the AI part of my branch because the next step is to put th...

Okay, but it does not say what the error is ?

Strange...

OK, the win32 versions of the operator++ return a long value, while the pthreads/gcc versions do not. I'm not sure what the reason for the difference is. An atomic count is pretty useless if you cannot retrieve the incremented value. Koshi, if you want to compile see below. from detail/atomic_count_...