Should SDL be used as the GUI instead of Ogre?

Programmers discuss here anything related to FreeOrion programming. Primarily for the developers to discuss.

Moderator: Committer

Message
Author
User avatar
adrian_broher
Programmer
Posts: 1156
Joined: Fri Mar 01, 2013 9:52 am
Location: Germany

Re: Should SDL be used as the GUI instead of Ogre?

#46 Post by adrian_broher »

Geoff the Medio wrote:I'm mixing in a simultaneous update of various other dependencies, as the boost update has gotten complicated.
I see this branch has some commits, that could be applied already on trunk without distrupting the compile-ability of trunk, like r7698 "removed linux-static directory". Would it be okay to cherry pick those already or do you want to keep them as it is and merge afterwards?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#47 Post by Geoff the Medio »

adrian_broher wrote:Would it be okay to cherry pick those already or do you want to keep them as it is and merge afterwards?
No preference... Linux static in particular hasn't had any attention in long enough that I think it's safe to remove.

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: Should SDL be used as the GUI instead of Ogre?

#48 Post by Mitten.O »

I finally managed to compile this branch on my linux box. I ran into some issues.

First, many files that have been removed had not been erased from CMakeLists. The patch below removes all references that gave file missing errors.

The branch failed to compile against the current default version of boost in ubuntu (1.54), even when I added BOOST_SPIRIT_USE_PHOENIX_V3 to make spirit use the same version of phoenix 1.56 uses. It is not inconceivable it could be made to work, but I decided to try boost 1.56 instead.

The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585. Then it eventually worked. To use a custom boost you need to set the environment variable BOOST_ROOT when running cmake. I also added a -DBoost_NO_BOOST_CMAKE=TRUE, but am not sure that was necessary.

There were some issues with glew and opengl definitions. I resolved them by applying the vbo adventure patch, since adrian made them behave so nicely there.

The Logger was also included with a wrong path from one file. There is a trivial patch below for that, too.

There is also patch that removes SerializePathingEngine, since pathing engine itself seems to be gone.
Attachments

[The extension patch has been deactivated and can no longer be displayed.]

[The extension patch has been deactivated and can no longer be displayed.]

[The extension patch has been deactivated and can no longer be displayed.]

Any code by me in this post is released under GPL 2.0 or later.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#49 Post by Geoff the Medio »

Mitten.O wrote:...I decided to try boost 1.56 instead.

The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585. Then it eventually worked. To use a custom boost you need to set the environment variable BOOST_ROOT when running cmake.
If "stable" boost 1.56 can't compile without building a patched version from source, it can't be the required / expected version for FreeOrion. I think Boost 1.55 has Phoenix 3... and I'm not sure why you'd even need Phoenix 3, as most of the changes required for it were within boost version check preprocessor if clauses... So what were the problems with Boost 1.54?

Mitten.O
Programmer
Posts: 255
Joined: Sun Apr 06, 2014 4:15 pm

Re: Should SDL be used as the GUI instead of Ogre?

#50 Post by Mitten.O »

Well the error messages are over 3000 lines long, but the first one is

parse/ReportParseError.h:19:50: error: ‘boost::spirit::info::nil_’ has not been declared
void operator()(boost::spirit::info::nil_) const;

Many redefinition errors like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/is_actor.hpp:41:12: error: redefinition of ‘struct boost::phoenix::is_actor<boost::phoenix::actor<BaseT0> >’
struct is_actor<actor<Expr> >

Missing things also:
parse/AlignmentsParser.cpp:1:
/usr/include/boost/spirit/home/phoenix/core/actor.hpp: In instantiation of ‘struct boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l> >’:
/usr/include/boost/phoenix/core/preprocessed/argument_predefined_10.hpp:13:147: required from here
/usr/include/boost/spirit/home/phoenix/core/actor.hpp:92:9: error: no type named ‘no_nullary’ in ‘struct boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::phoenix::argument<3> >, 0l>’
nullary_result;

Also like this:
parse/AlignmentsParser.cpp:7:
/usr/include/boost/phoenix/core/detail/preprocessed/function_eval_10.hpp:7:1574: error: wrong number of template arguments (7, should be 5)
namespace boost { namespace phoenix { namespace detail { namespace tag { struct function_eval {}; template <typename Ostream> inline Ostream &operator<<( Ostream & os , function_eval) { os << "function_eval"; return os; } } namespace expression { template < typename A0 = void , typename A1 = void , typename A2 = void , typename A3 = void , typename A4 = void , typename A5 = void , typename A6 = void , typename A7 = void , typename A8 = void , typename A9 = void , typename Dummy = void > struct function_eval; template < typename A0 , typename A1 > struct function_eval< A0 , A1 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 > {}; template < typename A0 , typename A1 , typename A2 > struct function_eval< A0 , A1 , A2 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 > struct function_eval< A0 , A1 , A2 , A3 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 > struct function_eval< A0 , A1 , A2 , A3 , A4 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 > {}; template < typename A0 , typename A1 , typename A2 , typename A3 , typename A4 , typename A5 , typename A6 , typename A7 , typename A8 , typename A9 > struct function_eval< A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > : boost::phoenix::expr< tag:: function_eval , A0 , A1 , A2 , A3 , A4 , A5 , A6 , A7 , A8 , A9 > {}; typedef proto::functional::make_expr< tag:: function_eval > make_function_eval; } namespace rule { struct function_eval : expression:: function_eval < meta_grammar , proto::vararg< meta_grammar > > {}; } } } } namespace boost { namespace phoenix { template <typename Dummy> struct meta_grammar::case_< :: boost :: phoenix :: detail :: tag:: function_eval , Dummy > : enable_rule< :: boost :: phoenix :: detail :: rule:: function_eval , Dummy > {}; } }
Any code by me in this post is released under GPL 2.0 or later.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Should SDL be used as the GUI instead of Ogre?

#51 Post by Vezzra »

Mitten.O wrote:I finally managed to compile this branch on my linux box. I ran into some issues.
Same here on OSX, with emphasis on finally - that surely was some hard work. I ran into most of the issues you encountered (unfortunately before you posted here, that would have saved me a lot of time and headache), and some more (mostly OSX specific):
The stable 1.56 serialization has a bug, which apparently is fixed in development. I fixed it manually as described here https://chaste.cs.ox.ac.uk/trac/ticket/2585.
Yep, that has been a nasty one. This one alone took me several hours to figure out, the build errors the compiler drowned me in weren't any help at all, at least for me :( Finally found the same link you posted, so on OSX too boost 1.56 only works with this patch.
There were some issues with glew and opengl definitions.
Same here, although I solved them by replacing

Code: Select all

#include <GL/glew.h>
with

Code: Select all

#ifdef __MACOSX__
#include <SDL2/SDL_opengl.h>
#include <OpenGL/glu.h>
#else
#include <GL/glew.h>
#endif
on line 35 in GG/Base.h. That probably can be done better, but I wanted to get the thing working first. I guess we want to patch something together that works for all supported platforms...
The Logger was also included with a wrong path from one file.
ShaderProgram.cpp. Fortunately, that one was easy.
There is also patch that removes SerializePathingEngine, since pathing engine itself seems to be gone.
That actually caused build errors on OSX, so I had to remove SerializePathingEngine.

Additional issues I ran into:

chmain.h has been removed, which caused build errors on OSX. @Geoff: Please restore chmain.h, it's needed by the OSX specific chmain.mm and GUIController.mm (former OgreController.mm).

What caused by far the most headache for me and took the most time to figure out was another bug in boost 1.56 that causes the boost build system to look for the OSX SDKs in the wrong location on OSX 10.9 with Xcode 5. I think that normally that would give you some meaningful error messages when trying to build boost. My system however has been upgraded from 10.6 and this specific setup resulted in a successful build of boost, but which was somehow mangled, as it produced a lot of obscure link errors when I tried to build FO. It has been luck more than anything else that I found out what was wrong and how to fix it.

Upgrading boost really is a major PITA... :(

Well, finally I've been able to build FO with the SDL branch and boost 1.56, although I had to solve some more issues before I got a build that didn't crash. But I have to say the results are worth all the trouble. With SDL the mouse pointer isn't locked into the FO window anymore, I can resize the window like any other, no need to do that by changing the options, even the standard OSX fullscreen feature works flawlessly.

One issue was that the FO app didn't completely quit when I exited the game. The FO window was closed, but the app itself didn't quit. Have been able to fix that by adding a line to GUIController.mm, but apparently GG-SDL does something different than GG-Ogre when exiting.

Finally, there is an issue I wasn't able to solve: when launching FO, the FO window is resized to a small window in the top left corner of the screen. You always have to resize the window to the desired size manually before you can play. That's of course somewhat annoying...

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Should SDL be used as the GUI instead of Ogre?

#52 Post by Vezzra »

Geoff the Medio wrote:If "stable" boost 1.56 can't compile without building a patched version from source, it can't be the required / expected version for FreeOrion.
Oh no... after I finally got the entire thing working? If we don't upgrade to 1.56, can't we stay with 1.51? At least that version has been working so far...

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#53 Post by Geoff the Medio »

Vezzra wrote:...can't we stay with 1.51?
No, but 1.55 is an option. I think it also uses (or at least has) Phoenix 3, so it should avoid most of the above issues...
Vezzra wrote:Please restore chmain.h
Feel free to add it back yourself if I haven't...

Edit: Also, please make sure you're building Boost with zlib support in iostreams. This will be necessary to be able to use compressed text/xml based serialization.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Should SDL be used as the GUI instead of Ogre?

#54 Post by Vezzra »

Geoff the Medio wrote:No, but 1.55 is an option. I think it also uses (or at least has) Phoenix 3, so it should avoid most of the above issues
I've tried building FO with boost 1.55, the only setup that worked was trunk without BOOST_SPIRIT_USE_PHOENIX_V3. This one however worked right out of the box. Just dropped the 1.55 includes and binary libs into their respective locations in the dependencies folder, build and run. No issues, no adjustments necessery, nothing. Just worked :)

Everything else failed however. Building trunk with BOOST_SPIRIT_USE_PHOENIX_V3 failed (no surprise here), but also building the SDL branch, with or without BOOST_SPIRIT_USE_PHOENIX_V3. Building the SDL branch only works with boost 1.56.

(I wanted to attach the build logs of the failed builds, but I get a "Sorry, the board attachment quota has been reached." message.)
Also, please make sure you're building Boost with zlib support in iostreams. This will be necessary to be able to use compressed text/xml based serialization.
How do I do that?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#55 Post by Geoff the Medio »

Vezzra wrote:Building the SDL branch only works with boost 1.56.
The attachment quota has been increased, so please indicate how the SDL branch fails with 1.55. If it's just the nil_ thing, remove the _ from the few places I added it to support 1.56, such as in ReportParseError.h,

Code: Select all

void operator()(boost::spirit::info::nil_) const;
...or wrap the two possibilities in #preprocessor defines similar to the result type stuff:

Code: Select all

#if BOOST_VERSION < 105600
template <typename Arg1, typename Arg2> // Phoenix v2
struct result
{ typedef void type; };
#else
typedef void result_type;
#endif 
Also, I don't know if that version should actually be < 105500, so if you're getting errors about that serialization stuff, maybe try changing that number.
Vezzra wrote:How do I do that?
Make sure you have the zlib source available. I think I then had to add some environment variables (in a batch file, so you could probly use a shell script or do it manually) to point to that so the boost build system could see it. There should be some indications while running b2 (boost jam version 2?) to build boost that it has found and is using zlib. It's probably also possible to add something to project-config.jam, as I had to do to get it to build boost python, to point to the python source directory.

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Should SDL be used as the GUI instead of Ogre?

#56 Post by Vezzra »

After I removed the _ from all nil_ occurrences and changed the boost version to 105500 in all occurrences of the preprocessor defines for the result type stuff FO built and ran successfully (with BOOST_SPIRIT_USE_PHOENIX_V3 enabled). Hooray! :D (Shall I commit these changes?)

The zlib stuff also seems to work, at least I got some indicators like "zlib: yes" on the output of the boost build process. However, I noticed that boosts iostreams library hasn't been used for FO, at least on OSX. Assuming that it will be needed if we want to make use of the zlib support, I've included iostreams now and linked it to Common, the server, the human and the AI client. That's probably overkill...?

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#57 Post by Geoff the Medio »

Vezzra wrote:I removed the _ from all nil_ occurrences...
That will break on 1.56 or later, so it should be put into a boost version #if check for version 105600 or later for nil_ and nil otherwise).
Shall I commit these changes?)
After the above addition, yes.
The zlib stuff also seems to work...
If I remember, I'll post some patches that go part way to turning on zipped xml serialization. This should add dependencies to zlib (if not already present due to using libpng), and presumably iostreams with zlib built in.

Also, it is expected that the SDL/SDK branch has broken parsing for ship parts still, so don't be surprised if that (and possibly also buidlings?) aren't parsed properly...

User avatar
Vezzra
Release Manager, Design
Posts: 6095
Joined: Wed Nov 16, 2011 12:56 pm
Location: Sol III

Re: Should SDL be used as the GUI instead of Ogre?

#58 Post by Vezzra »

Geoff the Medio wrote:
Vezzra wrote:I removed the _ from all nil_ occurrences...
That will break on 1.56 or later, so it should be put into a boost version #if check for version 105600 or later for nil_ and nil otherwise).
Done.
Shall I commit these changes?)
After the above addition, yes.
Done. I also committed the fix for UI/ShaderProgram.cpp mentioned above.

There is still this fix to a build error on OSX that needs to be committed:
Vezzra wrote:
Mitten.O wrote:There were some issues with glew and opengl definitions.
Same here, although I solved them by replacing

Code: Select all

#include <GL/glew.h>
with

Code: Select all

#ifdef __MACOSX__
#include <SDL2/SDL_opengl.h>
#include <OpenGL/glu.h>
#else
#include <GL/glew.h>
#endif
on line 35 in GG/Base.h. That probably can be done better, but I wanted to get the thing working first. I guess we want to patch something together that works for all supported platforms...
Not a final solution, but unless a more complete fix is provided I'd like to commit that as is so at least building on OSX works without having to apply this fix locally. Is that ok?
Also, it is expected that the SDL/SDK branch has broken parsing for ship parts still, so don't be surprised if that (and possibly also buidlings?) aren't parsed properly...
Yep, ship parts and buildings are broken.

User avatar
Geoff the Medio
Programming, Design, Admin
Posts: 13587
Joined: Wed Oct 08, 2003 1:33 am
Location: Munich

Re: Should SDL be used as the GUI instead of Ogre?

#59 Post by Geoff the Medio »

Vezzra wrote:

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?

User avatar
vincele
Space Dragon
Posts: 341
Joined: Sun Mar 23, 2014 6:10 pm

Re: Should SDL be used as the GUI instead of Ogre?

#60 Post by vincele »

I'm reading r7713 and am wondering if moving all those ifdeffery in a centralized header (fo_boost_compat.h ?) wouldn't be cleaner ?
All the patches I'll provide for freeorion will be released under the GPL v2 or later license.
Let's unleash the dyson forest powa!

Post Reply