FreeOrion

Hi,

I am an RPM packager and I finally got GiGi 0.8.0 and freeorion 0.4 to compile and be packaged properly.
My OS is openSUSE 12.1 x86_64.

However, after installing the package, the game fails to start up: It just pauses and never goes anywhere; I then have to kill the process. Would anyone have a guess at why this would happen? (I suspect OGRE.)

Another thing I noticed is that the 'freeorion' binary is not linked against libGiGiSDL.so or libGiGiOgrePlugin_OIS.so (but is against libGiGi.so and libGiGiOgre.so.) Is this correct behavior?

Here are the package contents:

package 'freeorion':
http://pastie.org/4016464

package 'freeorion-data':
http://pastebin.com/D4QnjWY0

Thanks for any assistance!

OK, I found the problem which I missed: the libOgreMain.so on my system was compiled with libboost_thread 1.46.1. After rebuilding Ogre to the newer libboost_thread (1.49.0,) the game started OK.

What about the non-linked GiGi libraries? Are they even needed?

FreeOrion doesn't use SDL, so the SDL-related library shouldn't be linked against.

The OIS library is a plugin, which is loaded dynamically at runtime, so I think it should be fine to not explicitly link against it. This should work the same as the OctreeSceneManager, ParticleFX and RenderSystemGL plugins that OGRE uses.

Ah. Dynamically loaded. OK, that makes sense.

Well, in that case, I have successfully built 0.4 as openSUSE RPMs (for Factory only, the boost requirement was too high for other versions.) The game starts up OK. I haven't tested too thoroughly, though.

If anyone wants to take a look, I used the OBS (Open Build Service:)
GiGi: https://build.opensuse.org/package/show ... me%3Adbuck
FreeOrion: https://build.opensuse.org/package/show ... me%3Adbuck

It is an easy hop to build for most common RPM distros with the OBS. DEB-based would require a little more work.

You might want to check if the AIs do anything. Python issues occur frequently, and could result in no AI activity.

Yep. AI works fine. Looks like all systems go; except the main binary seems to be using on average 95% of one CPU (on a Core i7)

Always, or just between turns? If always, go into the options screen, galaxy map tab, and turn off background stars and galaxy gas. Also in the video tab, turn on limit FPS and set it to 30 or so.

I am talking about constant usage. After playing around with the options, I have found the following:

- Default CPU usage (Core i7 M 620 @2.67 GHz): 95-100% on one core
- Reducing the FPS to 30 from 60, no change.
- Turning off the galaxy gas reduced CPU usage to about 65%
- No change with removing background starfield
- Turning off music raised CPU to about 75% after galaxy gas was turned off (weird)
- No real change with any other toggle-able option I could find

So, some oddities... but my computer runs slightly cooler with the gas disabled.

Try updating your video drivers, if possible?

Reinstalling the stock kernel for my distro, and the appropriate NVIDIA module for it, did reduce constant CPU usage to about 40%. Turning on the galaxy gas brought it back to 100%

After a couple patches, I got 0.4.1 to build for openSUSE 12.1. x86_64 RPMs have completed; x86 is taking a while - probably because of the monstrous compilation unit sizes created with such widespread usage of boost::.

Also the performance is much improved, even with rendering the galaxy gas!

If anyone is interested in packaging for other distros, you can see the patches I applied here:

https://build.opensuse.org/package/file ... me%3Adbuck

What does that mean for users? Have you submitted it to a repository for the distro, or is there a download link they'd need to use? Is it something that can / should be put on sourceforge?

I wouldn't put the RPMs on sourceforge, although a handy source archive (with all the .svn garbage stripped out) might be helpful for packagers - I had to make my own from SVN.

In the Linux world every distribution has their own platform for building the packages specific to it, as well as how to serve up those packages. I happen to be familiar with openSUSE, so people who use that distribution may now download the RPMs from my project (links above).

What my work does do is serve as a template of sorts for other packagers who wish to bundle FO for their distributions. Being RPM-based means that it would probably easily port to Fedora and any other RPM-based distribution; but even differently packaged distributions like Debian+derivatives, Arch, Slackware, etc. can take a look at my patch set and control file (RPM SPEC) and base their packages on it.

What's wrong with the tarball links available from sourceforge?
Can you provide a specific link for a specific distro? Your links don't take me to a page with a downloadable file on it.

Well... because I'm blind and didn't see them before?
Neat.


Ah yes, sorry. For openSUSE 12.1 my home repository is located here:
http://download.opensuse.org/repositori ... SUSE_12.1/

Note that FO has two RPMs: 'freeorion' (the binary) and 'freeorion-data' (shared data), one found under the directory 'x86_64' and the other under 'noarch'. There's also a source RPM under the 'src' directory.

Note that it is uncommon now for any Linux distribution to have you download packages directly - they just have you hook into the repository through a central package management system. This system then figures out all your dependencies for you automatically and knows which RPMs you'll need to download.

I should probably work on getting FO out of my home repository into the official openSUSE games repository though...

For comparison, I found freeorion 0.4 at Arch:
https://www.archlinux.org/packages/comm ... freeorion/

I think I've seen 0.3.x versions for various Debian derivatives