Page 4 of 4

Re: OpenMW 0.11.1

Posted: 30 Sep 2011, 12:46
by psi29a
OK, good to know. :)

Re: OpenMW 0.11.1

Posted: 01 Oct 2011, 22:24
by Star-Demon
Once my issues with the launcher are fixed I will cook something up to post.

Re: OpenMW 0.11.1

Posted: 02 Oct 2011, 21:46
by lgromanowski
There are some missing DLLs in openmw-0.11.1 windows package (I have an error messages on clean Windows 7 system): openal32.dll and msvcp100.dll (second one is in MS VC++ 2010 redistributable package, so probably full 4MB could be included).

Re: OpenMW 0.11.1

Posted: 03 Oct 2011, 06:43
by Zini
@BrotherBrick: Here is your list. These are the libraries I am using (note that I am fairly conservative about updates and a lot of people are using more up to date versions):

Ogre: 1.7.1: Older versions definitely do not worl; I suspect that we will have to switch to the upcoming 1.8, because it has features we will need in the editor.

Bullet 2.77: 2.78 and newer seem to have a regression that affects performance badly; especially on low-spec boxes

Boost 1.40: Many developers use newer versions. We have addressed the API changes.

Qt 4.6.2

OpenAL 1.11.753

libmpg123 1.12.1

libsndfile 1.0.21

Re: OpenMW 0.11.1

Posted: 03 Oct 2011, 08:50
by psi29a
@Zini: Great, thanks I can update the dependencies accordingly.

Ogre is interesting because Ubuntu Natty (11.04 latest stable) still uses only 1.6.4 and Oneiric (11.11) does not even carry the package. I've been forced, as a Ubuntu user, to use Andrew's PPA to get this package or use getdeb. Both of which ship 1.7.3 version. Debian is worse by still sticking with 1.6.4.

Libbullet is not shipped by Ubuntu nor Debian, the only place I found it in was in getdeb: libbullet0 (2.77)

My suggestions in order of preference:
* Provide a link to getdeb and instructions until ogre >= 1.7.1 and libbullet ships in Debian/Ubuntu
* Ship our own versions of Ogre and libbullet
* Statically link against those two packages, until provided by a distribution. (Being pragmatic here, I am willing to be "un-Linux" like if it means getting things to "just work"
* Throw my hat into the ring as a maintainer of those packages for both Debian/Ubuntu

What do you think?

The rest of the libraries you listed are good to go in most distributions. I also try to stay conservative as most distributions have quality testing cycles (or are just lazy) and only update when there is enough "need".

When I have time, I will investigate plain tar.gz as time allows. RPMs, for the moment, are not on my radar.

Re: OpenMW 0.11.1

Posted: 03 Oct 2011, 10:26
by Zini
* Provide a link to getdeb and instructions until ogre >= 1.7.1 and libbullet ships in Debian/Ubuntu
Sounds reasonable to me.

Re: OpenMW 0.11.1

Posted: 03 Oct 2011, 16:18
by psi29a
Zini wrote:
BrotherBrick wrote:* Provide a link to getdeb and instructions until ogre >= 1.7.1 and libbullet ships in Debian/Ubuntu
Sounds reasonable to me.
Good news: The reason I could not find libogremain in Ubuntu 11.10 (beta) is that it is included in the libogre 1.7.3 package that is included.

Neutral news: libbullet0 (2.77) still needs to come from getdeb. I will write up some installation instructions to reflect this.

Ugly news: libois is now version 1.3.0, which I tested and no obvious bugs in openmw after playing around.

Do we have a test suite or benchmark that hits major points of openmw?

Until 11.10 becomes stable, I will target 11.04 with the getdeb info.

For those wishing a tar.gz (or tar.bz2), they will get it but they can fend for themselves on dependencies.

For those wishing a rpm, one was made... but it is not tested yet.

Re: OpenMW 0.11.1

Posted: 03 Oct 2011, 17:04
by Ace (SWE)
lgromanowski wrote:There are some missing DLLs in openmw-0.11.1 windows package (I have an error messages on clean Windows 7 system): openal32.dll and msvcp100.dll (second one is in MS VC++ 2010 redistributable package, so probably full 4MB could be included).
I am not fully sure but I believe there's a reason you're supposed to install the full redistributables for stuff like that.
For now simple packeting the DLLs next to the program might work but later on we should at the very least link the user to the redistributables.