Should SDL be used as the GUI instead of Ogre?

[Geoff the Medio]

...moving all those ifdeffery in a centralized header (fo_boost_compat.h ?)...

Feel free to make a patch to find out...

[Geoff the Medio]

...I'll post some patches that go part way to turning on zipped xml serialization. This should add dependencies to zlib...

Here's what I was working on before realizing I'd be adding dependencies the old SDKs wouldn't meet. Probably won't immediately apply or compile...

[Mitten.O]

I managed to compile the branch against boost1.54, which is the default on the current ubuntu.

I used -DBOOST_SPIRIT_USE_PHOENIX_V3 and modified some #if conditions to fit that (made it use the new code in specific cases if the macro was defined). I'll see if I can figure out which of the things I did were actually necessary.

[Vezzra]

Code: Select all

#include <GL/glew.h>

This issue probably isn't new to the recent changes, as OpenGL has been in use prior to this. What does trunk do for equivalent includes?

Well, in that specific location (GG/Base.h starting at line 34), the code in trunk looks like this:

Code: Select all

// include OpenGL headers
#if defined(__APPLE__) && defined(__MACH__)
# include <OpenGL/gl.h>
# include <OpenGL/glu.h>
#else
# include <GL/gl.h>
# include <GL/glu.h>
#endif
#include <GG/glext.h>

In the SDL branch this code section has been replaced with:

Code: Select all

// GL headers
#include <GL/glew.h>

Which does not work on OSX, as glew.h apparently is Windows specific, at least everywhere else in the code where it's included it's done like this:

Code: Select all

#ifdef FREEORION_WIN32
#include <GL/glew.h>
#endif

Just doing that in GG/Base.h isn't sufficient however, to get the thing to build on OSX I need to include SLD2/SLD_opengl.h and OpenGL/glu.h. So, I suggest to change this code section to something along these lines:

Code: Select all

// GL headers
#if defined(_WIN32)
#include <GL/glew.h>
#elif defined(__APPLE__) && defined(__MACH__)
#include <SDL2/SDL_opengl.h>
#include <OpenGL/glu.h>
#else
// TODO: What to do on Linux...?
#endif

And replace the TODO with what needs to be included on Linux to get things working (Marcel? Dilvish?).

[adrian_broher]

And replace the TODO with what needs to be included on Linux to get things working (Marcel? Dilvish?).

#include GL/glew.h

Also add GLEW as a dependency for MacOSX. It's easier to have one extension loader on all platforms instead of this #ifdef nonsense.

http://glew.sourceforge.net/

[Vezzra]

Also add GLEW as a dependency for MacOSX. It's easier to have one extension loader on all platforms instead of this #ifdef nonsense.

Sorry, no luck. Using glew.h and linking with libGLEW.a lets me successfully build FO, but when I try to run a game FO crashes after universe generation, before the first turn, when calling the ShaderProgram ctor. Backtrace attached.

[adrian_broher]

You need to call glewInit before using any glCalls. This is done for the window client only now http://sourceforge.net/p/freeorion/code ... entApp.cpp line 239. It should work you you remove the ifdef

[Vezzra]

You need to call glewInit before using any glCalls. This is done for the window client only now http://sourceforge.net/p/freeorion/code ... entApp.cpp line 239. It should work you you remove the ifdef

Yay! Victory at last! Thanks for the hint

To be able to build FO on OSX with glew I also removed all the other #ifdefs that caused glew.h to be only included on Windows in ShaderProgram.cpp, HumanClientApp.cpp, GLClientAndServerBuffer.cpp, MapWnd.cpp and SidePanel.cpp. Otherwise I get build errors that gl.h, glu.h etc. have been included before glew.h. Actually the only two that won't build in that case are ShaderProgram.cpp and GLClientAndServerBuffer.cpp, but I thought it's probably better to be thorough and remove those #ifdefs everywhere.

@Geoff: Can I commit these changes?

[Geoff the Medio]

Can I commit these changes?

Why are you asking?

[Vezzra]

Why are you asking?

Probably because it has been a bit late yesterday, my brain wasn't working right anymore, and I wasn't sure if there might be reasons not to make these changes

Anyway, I guess a got my answer. Committed.

[Vezzra]

I've uploaded an experimental new version of the OSX SDK (to FreeOrionSDK/Test on sourceforge) that should work with the SDL branch. The necessary updates to the Xcode project have been committed. So if anyone feels like experimenting...

[Chriss]

I kinda got lost now - how far along is the boost 1.56 support in trunk?

[Vezzra]

I kinda got lost now - how far along is the boost 1.56 support in trunk?

In trunk? None. Switching to SDL and upgrade of dependencies is done in the SDL branch. And we're most likely not going to upgrade to boost 1.56, but 1.55, due to a bug in 1.56 that would require us to patch boost to be able to use it.

[Mitten.O]

Still no cleanup of CMakeLists in this branch?

Here is some. Removes references to removed files from CMakeLists and removes SerializePathingEngine, since pathing engine is gone. Pretty much the same as earlier, maybe cleaner.

[Chriss]

I kinda got lost now - how far along is the boost 1.56 support in trunk?

In trunk? None. Switching to SDL and upgrade of dependencies is done in the SDL branch. And we're most likely not going to upgrade to boost 1.56, but 1.55, due to a bug in 1.56 that would require us to patch boost to be able to use it.

Let's say arch adds the missing includes for serialization to work. What are the chances of me being able to compile a FO branch with 1.56 in the near future? I am not sure if I can stay on 1.55 for months... It's not really a supported constellation in Arch. Boost versions seem to take a couple of months at least.