Data Mining - User OSes

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Data Mining - User OSes

Post by lgromanowski »

Lordrea wrote: Heya,

Just wondering what operating system those active are using.

While looking through the code, I see a lot of linux-only headers in the ESM/ESP parsers. I feel this to be a grave mistake, as it makes compilation on Windows more difficult - and I believe Windows developers are more common.

So, trying to get a feel, for multiple reasons, what operating systems people are planning on playing OpenMW on.

- Michael

Disclaimer: This is not an attempt at making OpenMW platform-dependent.
raevol wrote: Xubuntu. :twisted:
Vance987 wrote: When I get my new computer, I'll probably use windows 7. (Because it comes with it) But I MAY use linux or ubuntu if I end up not liking windows 7. I have been a hardcore windows user for a long time now though...
Zini wrote:
and I believe Windows developers are more common
:D
Windows 37% 37% [ 7 ]
Linux Variant 63% 63% [ 12 ] x
OSX 0% 0% [ 0 ]
This makes me happy.
Lordrea wrote:
Zini wrote:
and I believe Windows developers are more common
:D
Windows 37% 37% [ 7 ]
Linux Variant 63% 63% [ 12 ] x
OSX 0% 0% [ 0 ]
This makes me happy.
It's very interesting! Also potentially dangerous. As I mentioned in another thread, there are some Linux-only headers in some of OpenMW's files (if Google does not lie). That's bad! Windows to Linux conversion is much, much easier than Linux to Windows conversion.
tangent wrote: actually, linux stuff is more often open source and therefore more easily cross platform.. anyway, what are you worrying about? there are gonna have to be windows only and linux only pieces, i would imagine, but it's been compiling windows binaries in the past. so i voted linux, though i dual boot debian and win 7
Zini wrote:
Windows to Linux conversion is much, much easier than Linux to Windows conversion.
Not really. Why would going into one direction easier than going into the opposite direction?
As I mentioned in another thread, there are some Linux-only headers in some of OpenMW's files
Would you mind giving me a hint about what Linux-only headers we are talking? I quickly browsed through a couple of source files and couldn't find anything Linux-only.
Lordrea wrote:
tangent wrote:actually, linux stuff is more often open source and therefore more easily cross platform.. anyway, what are you worrying about? there are gonna have to be windows only and linux only pieces, i would imagine, but it's been compiling windows binaries in the past. so i voted linux, though i dual boot debian and win 7
Zini wrote:Not really. Why would going into one direction easier than going into the opposite direction?
Yeah, I plead tired insanity when I wrote that (safely ignore anything I say before 10am). Only applies to built software, not code.
Zini wrote:Would you mind giving me a hint about what Linux-only headers we are talking? I quickly browsed through a couple of source files and couldn't find anything Linux-only.
I'll take a look again, but I remember running into a couple of files that Visual Studio couldn't find. I Googled them some months back and thought I turned up something 'nix related. Probably this quote from some forum on <strings.h>: "The linux gcc compilers in our computer labs have this header file, but my windows compiler does not have this, and I cannot get to the lab to grab it."
Lordrea wrote: In an unrelated note, it looks like I'll have to reset the poll. :roll: I forgot to make it so guests couldn't vote. We've way more votes than we do active members!
Kazashi wrote: Hmmm, that's odd. string.h/cstring should be a standard C header. Would be puzzling if MSVS doesn't have such a thing, unless the compiler being used is non-standard. Unfortunately I have no experience with Windows development, I use GCC/Code::Blocks on a Linux platform, but now I'm curious so I may start up a VM.

Despite my strong anti-MS stance, I believe that the Windows version should be just as accessible for development as any other platform, even if it does result in a bunch of #ifdef WIN32 :P

Speaking of which, I am using Gentoo Linux on am64. I'm glad that OpenMW is switching to C++, because getting the D compiler set up was a right royal pain.
Zini wrote: <strings.h>, not <string.h> or <cstring> (btw. <cstring> is a C++ header, not a C header).

<strings.h> seems indeed to be a UNIX header (never heard of it before). But it would be trivially easy to write a replacement for Windoze. If that is the only portability problem, there is little to worry about.
Lordrea wrote:
Kazashi wrote:Hmmm, that's odd. string.h/cstring should be a standard C header. Would be puzzling if MSVS doesn't have such a thing, unless the compiler being used is non-standard. Unfortunately I have no experience with Windows development, I use GCC/Code::Blocks on a Linux platform, but now I'm curious so I may start up a VM.
string.h/cstring.h are both standard C headers. The file in question is strings.h - I'm not sure if it is.
Zini wrote:<strings.h>, not <string.h> or <cstring> (btw. <cstring> is a C++ header, not a C header).

<strings.h> seems indeed to be a UNIX header (never heard of it before). But it would be trivially easy to write a replacement for Windoze. If that is the only portability problem, there is little to worry about.
Trivially easy, perhaps, but it remains that it is not a standard, cross-platform header, which, if I'm right, means that OpenMW is currently a Linux-only solution (for developers) at the moment. With the majority of our user base, if not our development-interested user base or our developers, that's not good. It's the reason I mentioned the data as a potentially dangerous thing. An approach that 'hacks' the code to work on win32 with a lot of #ifs and an anti-"Windoze" mentality will only hurt our target audience.
Zini wrote:
string.h/cstring.h are both standard C headers.
<nitpicking>

There is no header named cstring.h at all. Neither in C nor in C++. It is called cstring and it is not a C header. It is C++ only (basically string.h in std namespace).

</nitpicking>
The file in question is strings.h - I'm not sure if it is.
I am pretty sure it is not. At least I can't find any mentioning of it in any standard/library documentation.

I agree with you, that ideally this header shouldn't be used in a cross-platform project. Ideally all platform-specific #ifdefs should be avoided and portable libraries should be used instead (which then can contain the ugly #ifdefs).
However if it is really only this single header, used in only a few places, my only reaction is a shrug. Pretty insignificant compared to the size of the project. Even though Windows user are indeed a large part of the target audience, it will barely affect development on that platform at all.

Can't check right now, but if gcc has strings.h, shouldn't MingW have it too? So it would still be possible to compile OpenMW on Windows (still doesn't invalidate that point about not being standard though).
an anti-"Windoze" mentality will only hurt
This is obviously somewhat subjective, but I believe, that an anti-Windows mentality will never hurt.
raevol wrote:
Zini wrote:This is obviously somewhat subjective, but I believe, that an anti-Windows mentality will never hurt.
Thumbs up. I understand people want a windows port of OpenMW, and they should have one, but they should realize that they're hindering mankind's progress. :P
sir_herrbatka wrote: should i vote if i'm not active developer?
Lordrea wrote:
Zini wrote:
string.h/cstring.h are both standard C headers.
<nitpicking>

There is no header named cstring.h at all. Neither in C nor in C++. It is called cstring and it is not a C header. It is C++ only (basically string.h in std namespace).

</nitpicking>
Ah, my bad. Thanks for clarifying.
Zini wrote:Can't check right now, but if gcc has strings.h, shouldn't MingW have it too? So it would still be possible to compile OpenMW on Windows (still doesn't invalidate that point about not being standard though).
I tried to compile with MinGW, with similar fails.
Zini wrote:This is obviously somewhat subjective, but I believe, that an anti-Windows mentality will never hurt.
raevol wrote:Thumbs up. I understand people want a windows port of OpenMW, and they should have one, but they should realize that they're hindering mankind's progress. :P
Will never hurt you - but it will drive this project firmly into insignificance. Mod makers will largely be Windows user. Curious people wanting to dabble (which is often how mods are made and why most of us love Morrowind so much), and they will be blocked if the code does not support 90+% of the Morrowind audience. The majority of these people will not be able to make their own "trivial" headers to get a UNIX-dependent program to compile, and so anything worthwhile they have to contribute will be blocked. This will not only hurt OpenMW's development, but its measured success at being an open source, cross-platform translation of the Morrowind engine. That's not some broken philosophy - that's fact. So, I implore you: ignore your bias attitude of platform/OS superiority and help the project, not your own agenda.
sir_herrbatka wrote:should i vote if i'm not active developer?
Yup.
sir_herrbatka wrote: So I voted linux. sry Lordrea ;)
Lordrea wrote:
sir_herrbatka wrote:So I voted linux. sry Lordrea ;)
O.o Don't apologize! I'm here to collect information, not parade Windows. I'm a casual Ubuntu user myself (it's on my laptop, which I rarely have the need to use, and I triple-boot Win7/Ubuntu/OSX), so it's not like I'm anti-Linux.

I am, however, anti-Apple, but that's for a different discussion thread. ;)
sir_herrbatka wrote: Sry, I'm nothing to do with programming so I surely won't clarify anything, but I may suggest one thing: let's ask nico to take a voice in discussion. He knows everything about openmw ;)
raevol wrote:
Lordrea wrote:Will never hurt you - but it will drive this project firmly into insignificance. Mod makers will largely be Windows user. Curious people wanting to dabble (which is often how mods are made and why most of us love Morrowind so much), and they will be blocked if the code does not support 90+% of the Morrowind audience. The majority of these people will not be able to make their own "trivial" headers to get a UNIX-dependent program to compile, and so anything worthwhile they have to contribute will be blocked. This will not only hurt OpenMW's development, but its measured success at being an open source, cross-platform translation of the Morrowind engine. That's not some broken philosophy - that's fact. So, I implore you: ignore your bias attitude of platform/OS superiority and help the project, not your own agenda.
No I agree. OpenMW needs windows in order to be successful. The world just doesn't need windows... I'm not trying to be contrary, I understand the average user is terrified of better operating systems, I'm just expressing my view that people need to not be so resistant to change. In the meantime, I'm all for a windows port of OpenMW.
pogzy wrote: I have Windows on one system (eeeBuntu) and windows XP on another one.

I develop mainly on Windows, even if I target Linux. I already used Cygwin X client/server to do C/gtk gui dev. I also used VirtualBox. Why not Linux as native systems, because at work I can not choose native OS as I want.

I've tested Window XP vs Linux at home to play free games, such as gl-117 and many other games or soft available on both platforms (like Stellarium a sky chart soft). I was sad to admit that Windows performs better than Linux for frame per second (up to 10 times better on OpenGL games). I don't know if it comes from drivers or the system GL layers there heavier on linux. I see that on my eeePC 701 with Celeron/Intel GPU and it should not be the same for any other hardware.

By the way, I love Linux and prefer this OS but I hope that OpenMW is targeting multi-platforms so that it will remain a long life project.
pvdk wrote: I've looked through the source and I found strings.h to be included in bsa/bsa_file.h and in tools/stringops.cpp. It is included for the strcasecmp function, which compares strings in a case-insensitive way, unlike strcmp from cstring (string.h).

Because strings.h is part of glibc it is not part of Windows or Visual Studio for that matter. There are several options for case-insensitive string comparison under Windows but the _stricmp function is considered the best option according to MSDN. (ISO C++ conformant and CRT)

A quick solution for the OP compile error would be something like this:

#ifndef WIN32
#include <strings.h>
#define _stricmp strcasecmp
#endif

And in bsa/bsa_file.h:

/// Case insensitive string comparison
struct iltstr
{
bool operator()(const char *s1, const char *s2) const
{ return _stricmp(s1,s2) < 0; }
};

I haven't tested this solution because I don't own a copy of Windows but it should compile.

Better yet would be to compare the lenght of both strings first, as different lenghts would mean different strings. This would also mean that a costly string comparison could be avoided if not necessary.

Another thing I noticed in tools/stringops.cpp: #include <string.h> means C string functions, #include <string> means C++ string class and functions. I don't know which one was meant to be included but this could be wrong.

Just my 2 cents :)
Pieter
sir_herrbatka wrote:
I've tested Window XP vs Linux at home to play free games, such as gl-117 and many other games or soft available on both platforms (like Stellarium a sky chart soft). I was sad to admit that Windows performs better than Linux for frame per second (up to 10 times better on OpenGL games). I don't know if it comes from drivers or the system GL layers there heavier on linux. I see that on my eeePC 701 with Celeron/Intel GPU and it should not be the same for any other hardware.
http://dl.dropbox.com/u/2936246/linux-h ... fs_386.deb

http://dl.dropbox.com/u/2936246/linux-i ... s_i386.deb

you can try this 3d performance oriented kernels for ubuntu netbook remix.
Kazashi wrote: Ah, I didn't actually notice the strings.h, my bad. I think I automatically processed it as string.h (yeah, I knew <cstring> was the C++ implementation, but thanks for elaborating on it :)). That particular file I had not heard of until explained by pvdk, but I agree that if it isn't included in a reasonably default installation of Windows/OSX/Linux then it may be best to avoid heavy use.

I hope I didn't fan too many flames by stating that I'm anti-MS. While I personally don't use Windows that's by no means a suggestion that OpenMW avoid it as a platform. There are simply too many people playing Morrowind already, and all of them could benefit from an enhanced engine. A cross-platform open-source project should ideally be easily accessible and configurable on a multitide of operating systems, with the potential to be ported easily beyond that (like, say, Haiku OS, 5 years from now ;)).

Having said that, there will probaby be an initial bias towards Linux users because it is an open-source and/OR cross-platform game engine. We don't see too many AAA games around.
babauka wrote: Because of switching to C++, why not have a fresh look at Qt?
I really believe you can get rid of a lot "supporting" code and no
problems in future regarding cross-platform issues.
pogzy wrote: I don't see how Qt can be of any help for this kind of project which is a FPS role playing game. Qt is really nice to do desktops apps but not very appropriate for hardcore 3D engine, a.i scripting, physics, water rendering effect etc.

I think that Ogre3D and other libs chosen are good choices. They are cross-platform capable, and row C++ to glue all that together is a good choice. So yes, Qt is great, but I don't see how it could be better or even equal for the very particular job required.
Dirk gwas-y-neidr wrote: heh I use all three OSes triboot rules!
fallenwizard wrote: I am using Arch Linux (with btrfs :) ) and Windows 7.
pvdk wrote:
babauka wrote:Because of switching to C++, why not have a fresh look at Qt
As pogzy said: Qt isn't really helpful with low-level stuff. Qt would add another layer on top of the Ogre/Bullet/whatever stuff we have already. However I've made some apps with Qt in the past and I simply fell in love with it. It could be used for the launcher app (for selecting mods) or we could use it to make our own OMWCS :)

A working Construction Set for Linux would be perfect, because now I'm forced to use Windows for making the debug cell.
fallenwizard wrote:I am using Arch Linux (with btrfs :) ) and Windows 7.
Ah another Arch user! And a brave one too! ;)
Lordrea wrote:
pvdk wrote:As pogzy said: Qt isn't really helpful with low-level stuff. Qt would add another layer on top of the Ogre/Bullet/whatever stuff we have already. However I've made some apps with Qt in the past and I simply fell in love with it. It could be used for the launcher app (for selecting mods) or we could use it to make our own OMWCS :)
Exactly.

You're not the only one who fell in love with Qt, and thought of making an OpenCS: http://openmw.org/forum/viewtopic.php?f=19&t=361 ;)
Below wrote:
Lordrea wrote:So, trying to get a feel, for multiple reasons, what operating systems people are planning on playing OpenMW on.
I am planning to run OpenMW on a FreeBSD. I've waste a couple of hours trying to build 0.6 version, already install and configure all dependencies (it wasn't so easy), but now there are some troubles with D compilation (gdc).
So I'm very glad for switching to C++ only, cause i won't able to spend more time with gdc.

Last git clone are successful compiles, but it just loading .esm and .bsa files, "setting up" ogre and nothing else. So i will just waiting for some progress.

Also I would like to help, but i'm not so skilled with c++ and games development, don't like Qt, GTK and other GUI toolkits.

----

Spent one more hour. Get 0.5 version, build with dsss and it's launched with very nice perfomance. Later remove cbrt function from monster/modules/math.d in 0.6 version and it was compiled too and :) So dsss build works on freebsd)
Locked