pvdk wrote: Hey guys,
After many hours of struggling I've got OpenMW to compile on Windows. I used Ogre 1.7.1 and Boost 1.4.2. The compiler I used is MSVC 2010 (the free edition you can download from MS).
The roadmap states that compiling and packaging a Windows release for 0.07 is assigned to Pogzy. Can Pogzy or anyone else tell me if he succeeded in compiling OMW himself? If not then I'm willing to compile and package 0.07.
Here's some proof:
athile wrote: pvdk, that's great! It's good to see a fellow Windows developer compiling the code. I've only been working with Debug builds so far, so speaking only for myself, it'd be great if you could package up the Windows release.
Note: I don't know how familiar you are with CMake, but I'm assuming the CMake install command could be used to largely automate the release packaging.
EDIT: if you're using the free edition of Visual Studio, that means it only comes with the non-optimizing version of the compiler. It'd be great to see if you could set up the necessary CMake changes to build an install, but someone with the full version of Visual Studio will likely need to create the final release package - so that OpenMW doesn't appear unnecessarily slow on Windows
Greendogo wrote: Awesome! It would be great to get the windows binaries so I can go bug-hunting!
pvdk wrote:I have the complete MSVC laying around somewhere. Takes a long time to install but I'll see what I can do. See, I'm running Windows on a virtual machine, so it's not that fastathile wrote:EDIT: if you're using the free edition of Visual Studio, that means it only comes with the non-optimizing version of the compiler. It'd be great to see if you could set up the necessary CMake changes to build an install, but someone with the full version of Visual Studio will likely need to create the final release package - so that OpenMW doesn't appear unnecessarily slow on Windows
Just for the record: the final release package needs to be compiled as release instead of debug?
As for CMake: I wasn't that familiar with it but I had to modify the CMake files quite a bit to get OpenMW to compile so I think I'm able to pull off the CMake Install stuff. But first I want to find out why CMake doesn't find my Boost libraries. (Anyone else having that problem?)
Maybe later I'll write a how-to for the wiki, as soon as compiling on Windows is more trivial than "Comment this out, add that, pray."
nicolay wrote: pvdk, feel free to take over the packaging task! There hasn't been much movement on the current windows build task so far, so the more who try the better. I'll put you up as the new assignee on the roadmap if that's ok with you (hope you don't mind Pogzy!)
A how-to on the wiki summarizing your steps would also be highly appreciated! If you have to change the source or build files to get it to work then I'd be happy to include those changes in the main repository as well.
pvdk wrote:The only changes I made were commenting stuff out and adding machine-specific paths and stuff. I will try to find out what's wrong with the CMake files and I'll send you a diff if I do.nicolay wrote: If you have to change the source or build files to get it to work then I'd be happy to include those changes in the main repository as well.
I tried out my OpenMW Debug cell in OpenMW, here's the result:
Latest Git, Linux 64-bit:
Latest Git, Windows XP 32-bit:
The bugs you see are not platform-specific: the stuff looks the same on both platforms.
I get an warning regarding alpha settings in a texture:
Code: Select all
WARNING (NIF:meshes\pk\flora_mooncap_1.NIF): Unhandled alpha setting for texture textures\ndib_flora_mooncap_water.dds
pvdk wrote: I've got Visual Studio 2010 all set up and CMake is now detecting Boost.
I had to make some adjustments to CMakeLists.txt, but that is because I compiled Boost as multi-threaded and static. (The name of static libs begins with lib... in MSVC world.)
Question remains: do the Boost libraries need to be compiled dynamic and single-threaded? If so, then CMakeLists.txt is good as it is. Else these lines need to be added before find_package(Boost... :
Code: Select all
set(Boost_USE_STATIC_LIBS ON) set(Boost_USE_MULTITHREADED ON)
Will see tomorrow if it is Windows-specific or not.
I could compile a release version of OpenMW now but what version do I use: Git tag 0.07 or a little later, including the PrtScr function and lighting fix?
Zini wrote: A little later and call it 0.07b ? If we weren't working with this archaic x.yy format, we could call it 0.7.1.0 or something, but I guess 0.07b will do.
Greendogo wrote:Why not use the 0.07.1 or 0.07.1.0 format? It would make more sense if there was a way to distinguish between many large releases, bugfixes, tweaks, etc. As it is now, with each large release (0.xx) there are only twenty six names for sub-releases. It would also seem more professional to do it this way.Zini wrote:A little later and call it 0.07b ? If we weren't working with this archaic x.yy format, we could call it 0.7.1.0 or something, but I guess 0.07b will do.
If the releases were numbered like this: 0.X.Y.Z, then:
-The X could indicate which Major Releases it is and at what milestone it is towards full functionality.
-The Y could indicate the number of Minor Releases since the last major release. Incremented each time an essential piece of functionality is added that is required for the next X increase.
-The Z could be the Revision number or any change made to the code.
The Y and Z would be reset to 0 at each Major Release. I know I shouldn't have had to explain this system. But the current one is not elegant and doesn't allow for the successful organization of a large number of Minor Releases and Revisions between Major Releases.