Windows / Visual Studio

Support for running, installing or compiling OpenMW
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Windows / Visual Studio

Post by lgromanowski »

pogzy wrote: Hi,

I've followed the steps as proposed to compile OpenMW.exe and it works but there are some little things that are confusing me.

Does anybody can confirm that CMake generates the OpenMW.sln?

In the solution generated, there are 3 projects ALL_BUILD which is the startep one, openmw project and ZERO_CHECK.

Does sb can explain me what are ALL_BUILD & ZERO_CHECK projects?

As you can see in the image:
<!-- ia0 -->OpenMW.sln.png<!-- ia0 -->
forget Visual Studio language (it's French), there is only cpp files in the solution. I think that whatever the OS/system, the project dir should remane the same, so there should be hpp files, test projects, and the appropriate directory structure.

Does someone could update the sln creation to include hpp files, include the directory structure or may I update manually the .sln and submit it here?

It could be fine to use CppUnit to manage all tests to create a complete test project/solution that can be run on any OS. So makefile will include tests projects. http://cppunit.sourceforge.net/doc/last ... kbook.html

What do you think of replacing the current tests directory structure by a single test dir with subdirs (bsa, esm, nif etc.) and include the use of CppUnit included in an appropriiate CMake target in place of shell scripts (which is Linux only)?

Do we continue to post tech stuff in the forum in Support section, was it the exoected type of posts? Does a tecnical section would be more appropriate?
Zini wrote: Very quick and very dirty replacement CMakeLists.txt:

Code: Select all

project(OpenMW)

# We probably support older versions than this.
cmake_minimum_required(VERSION 2.6)

# Add path for CMake scripts
set(CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/)

# Local files
set(BSA bsa/bsa_archive.cpp bsa/bsa_file.cpp)
set(NIF nif/nif_file.cpp nifogre/ogre_nif_loader.cpp)
set(TOOLS tools/stringops.cpp)
set(MANGLE_VFS mangle/vfs/servers/ogre_vfs.cpp)
set(GAME game/main.cpp game/esm_store/store.cpp game/cell_store.cpp game/setup.cpp)

# Local header files
set(BSA_HEADER bsa/bsa_archive.h bsa/bsa_file.h)
set(TOOLS_HEADER tools/stringops.h tools/slice_array.h)
set(GAME_HEADER game/esm_store/store.hpp game/esm_store/reclists.hpp game/cell_store.hpp)
file(GLOB ESM_HEADER "esm/*.hpp")

# Platform specific
if (WIN32)
set(PLATFORM_INCLUDE_DIR "platform")
else (WIN32)
set(PLATFORM_INCLUDE_DIR "")
endif (WIN32)

# Dependencies
find_package(OGRE REQUIRED)
include_directories("." ${OGRE_INCLUDE_DIR} ${PLATFORM_INCLUDE_DIR})
link_directories(${OGRE_LIB_DIR})

# Main executable
add_executable(openmw ${BSA} ${TOOLS} ${GAME} ${BSA_HEADER} ${TOOLS_HEADER} ${GAME_HEADER} ${ESM_HEADER})
target_link_libraries(openmw ${OGRE_LIBRARIES})
Also totally untested with MSVC projects. Works nicely with Code::Blocks though.

Does not include mangle and I might be missing some other components.
pogzy wrote: Hi,

I found very annoying that sources files in Visual Studio are all within the same dir, one for the headers and one for the sources.

Is it the same way for other IDE. Can every who is compiling telling which IDE he(she) is using, on which OS, and with which compiler. Does it look like this way on other IDE.

Is it possible to update the CMake stuff so that the sources within the EDI are at the same place they are in the directory?

I've done all the steps on Windows / Visual Studio 2008 from scratch at home to update the wiki page. After the Cmake generation step, the Visual studio sln is missing one Ogre include dir :
<ogre include path install>\include\OGRE is missing and should be add by hand.

in nifogre\ogre_nif_loader.cpp at line 251, there is errors

Code: Select all

      RGBA colorsRGB[numVerts];
numVert is not a const, my local copy semms to be up to date with the GIT repo? any help.
Zini wrote: Works with Code::Blocks (on Linux). It should look the same on Windows. I don't think there is anything that can be done about the cmake settings.

However Code::Blocks has an option to display the source tree with or without directory structure and an option to display the source tree sorted by header/source or not, so this is completely configurable. Maybe there is something similar in MSCV too?
athile wrote:
I found very annoying that sources files in Visual Studio are all within the same dir, one for the headers and one for the sources.
There's a CMake command called source_group(<GroupName> FILES <list of files...>) that can be used to add Visual Studio file groupings.
pvdk wrote: I can confirm CMake generates a .sln for Visual Studio 2010. I had to manually add the Boost and Ogre library and include dirs for caelum and openmw. I also had to add these lines to CMakeLists.txt get CMake to find my Boost libs:

Code: Select all

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON) 
Nobody seems to be able to tell me if this is the right procedure or that I should compile Boost with different flags. I'm willing to write a wiki with compilation instructions for Visual C++ Express 2008.

Greetings,
pvdk
athile wrote: pvdk, that seems reasonable to me. I've had to rename my libs manually from, for example, "libboost_filesystem-vc90-mt-gd-1_42.lib" to "boost_filesystem.lib" and then manually set BOOST_LIBRARYDIR in order for CMake to find them. Your approach seems much cleaner.
pvdk wrote:
athile wrote:Your approach seems much cleaner.
Heh, tell me about it. I got so frustrated with CMake I removed the findpackage(...) completely and added my libraries to CMakeCache.txt manually. Found the solution after putting CMake in debug mode.

It compiles for me with setting OGRE_HOME and BOOST_ROOT (and running, vcvars32.bat if using VS express). No further changes are needed to CMakeLists.txt.
Sslaxx wrote:
pvdk wrote:I can confirm CMake generates a .sln for Visual Studio 2010. I had to manually add the Boost and Ogre library and include dirs for caelum and openmw. I also had to add these lines to CMakeLists.txt get CMake to find my Boost libs:

Code: Select all

set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON) 
Nobody seems to be able to tell me if this is the right procedure or that I should compile Boost with different flags. I'm willing to write a wiki with compilation instructions for Visual C++ Express 2008.

Greetings,
pvdk
Go for it. Going to be giving Express 2010 a try some point rather soon (tomorrow!), so I'll see if this works for me there.
nicolay wrote: BTW if someone gets this to work in VS (preferably without breaking everything else ;) ) then post a patch and I'll include it in the main repo.
pvdk wrote:
nicolay wrote:BTW if someone gets this to work in VS...
What do you mean? Is it acceptable users have to add include/library directories or do you want CMake to handle that?
nicolay wrote: I'm not quite sure what I mean :). I'm totally unfamiliar with VS so I'm not able to follow this discussion entirely. But basically all I'm saying is that if there's any changes we can make (in CMake files or elsewhere) that will automate the process for others then we should include it in the main branch eventually.

Eg. if the USE_STATIC_LIBS is necessary for most users then we might as well include it as default on Windows, but I need someone to send me it as a working patch or GitHub commit since I'm not able to test things on Windows myself.
pogzy wrote: Hi,

I've tried to compiled following the wiki page on Windows/Visual Studio and I did have an errors.
--
CMake Error at cmake/FindIconv.cmake:56 (MESSAGE):
Could not find Iconv
Call Stack (most recent call first):
CMakeLists.txt:112 (find_package)
--

I download & install iconv setup for windows, retried, same error.

Is there somebody that did compile the source on Windows can give the steps to follow so that I could update the wiki page.
ape wrote:
pogzy wrote:Hi,
--
CMake Error at cmake/FindIconv.cmake:56 (MESSAGE):
Could not find Iconv
Call Stack (most recent call first):
CMakeLists.txt:112 (find_package)
--
Yeah, thats my fault, i've not updated the CMakeFile and i likely have to write a workaround because of the different windows api of iconv.

I tried to compile openmw on windows but got an error with mygui at linking.

I'll take a look later or sometime this weekend.
pogzy wrote: Thanks, it coud be fine if I can compile it and update the wiki page.

What version (url) of iconv to install, is there any post install actions to do for the CMake file to find iconv?

Bye
ape wrote: checkout my fork: [url=git://github.com/apreiml/openmw.git]git://github.com/apreiml/openmw.git[/url]

I disabled the character encoding for windows, but you'll need to set the iconv lib. Maybe you won't need that feature in win32.

Simply set the environment variables:

ICONV_INCLUDE_DIR to <install_path>\include
ICONV_INCLUDE_DIR to <install_path>\lib

I couldn't test it because on my machine openmw failed to link with following error message: http://gist.github.com/513747.
Did i forget to configure something, i'm not that experienced with VS2008.

If i get openmw to compile, i'll investigate further in this task.
Toccata wrote: Hey all,

I've crept around here for a little while and finally found the time to try doing a build, but I've hit a roadblock.

Code: Select all

1>------ Build started: Project: openmw, Configuration: Debug Win32 ------
LINK : fatal error LNK1104: cannot open file '..\..\extern\mygui_3.0.1\OgrePlatform\Debug\MyGUI.OgrePlatform.lib'
2>------ Skipped Build: Project: ALL_BUILD, Configuration: Debug Win32 ------
2>Project not selected to build for this solution configuration 
========== Build: 0 succeeded, 1 failed, 5 up-to-date, 1 skipped ==========
My specs:
WinXP Home 32-bit
OgreSDK v1.7.1
Visual Studio C++ 2010 Express

The strange part is that this file really doesn't exist... there's only MyGUI.lib and mygui.ogreplatform.pdb in that folder. From what I can tell it seems like MyGUI built fine, though (except for the mysterious missing file). I followed the wiki entry as best I could - did I miss anything critical?

I'm not extremely familiar with the inner workings of ogre or any of these other libraries, so any help on this matter would be fantastic.

Thanks!
athile wrote: I tried to get a Windows build working. I got past a few stumbling blocks, but had to give up when I ran out of time.

Here were the problems I ran into with the current code:

FIX_UNUSED needs to follow the declarations in update_arg() in esmtool_cmd.c. VS2010 treats the .c file as plain C source, so the declarations need to come before anything else - even the dummy statement.

std::back_inserter is defined in #include <iterator>; this apparently is implicitly included by one of the other std headers with gcc, but is not in VC. reclists.hpp needs to include iterator.

In esm_reader.hpp, __WIN32__ is not defined on my Windows build. Should the define WIN32 be used instead (that's the "standard" one as far as I know)?

ESMS::ESMStore mixes struct and class between the declaration and definition. It's just a warning, but it'd be nice to be consistent.

Note: I'm currently not on a very good development machine (i.e. a netbook), so I don't have fixes available to push up to github. I'd appreciate it if someone else could.


Lastly, as an aside, the amount of setup necessary to get a Windows build is daunting. It's certainly enough to scare off any would-be casual contributors on the Windows side. I've built OpenMW in the past and, after being away for only 3 or 4 weeks, it still took me several hours to get the latest source to build. It would be nice if there were some dev script file to grab all the dependencies (using wget or something), unzip them to a known location (maybe within the extern folder and add the necessary folders to the .gitignore file?), and set then necessary environment variables to those folders so that CMake will find them automatically.

Development on a netbook is quite agonizing, so I need to work on finding a better machine before I can offer to do anything like the above :)
Star-Demon wrote:
athile wrote:I tried to get a Windows build working. I got past a few stumbling blocks, but had to give up when I ran out of time.

Here were the problems I ran into with the current code:

FIX_UNUSED needs to follow the declarations in update_arg() in esmtool_cmd.c. VS2010 treats the .c file as plain C source, so the declarations need to come before anything else - even the dummy statement.

std::back_inserter is defined in #include <iterator>; this apparently is implicitly included by one of the other std headers with gcc, but is not in VC. reclists.hpp needs to include iterator.

In esm_reader.hpp, __WIN32__ is not defined on my Windows build. Should the define WIN32 be used instead (that's the "standard" one as far as I know)?

ESMS::ESMStore mixes struct and class between the declaration and definition. It's just a warning, but it'd be nice to be consistent.

Note: I'm currently not on a very good development machine (i.e. a netbook), so I don't have fixes available to push up to github. I'd appreciate it if someone else could.


Lastly, as an aside, the amount of setup necessary to get a Windows build is daunting. It's certainly enough to scare off any would-be casual contributors on the Windows side. I've built OpenMW in the past and, after being away for only 3 or 4 weeks, it still took me several hours to get the latest source to build. It would be nice if there were some dev script file to grab all the dependencies (using wget or something), unzip them to a known location (maybe within the extern folder and add the necessary folders to the .gitignore file?), and set then necessary environment variables to those folders so that CMake will find them automatically.

Development on a netbook is quite agonizing, so I need to work on finding a better machine before I can offer to do anything like the above :)
Windows, here, too. Yeah, I hear something about VS2010 being more picky with headers and inclusions.

I have to agree - I hate setup and wish a little as possible upon people. It's one of the reasons I haven't gotten much of my own projects done. We're asking potential contributors to get a lot of moving parts onto their windows machine and configure them correctly, all before they do any actual work. If there's any way to make it easier we'll have served the project very well by making it easy to get into.
nicolay wrote: I agree fully. I don't have a windows partition at all right now, but I'll do what I can on my end to help out. I'll look into all the points you listed above athile.
nicolay wrote: Thanks for the list athile. I think I've fixed them all now. I could only find one declaration of ESMStore as class (in mechanicsmanager.hpp), and the __WIN32__ in esm_reader had already been removed along with iconv.
pogzy wrote: Hi,

I've tried again to build the project but it fails

Code: Select all

CMake Error at C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE):
  Could NOT find Freetype (missing: FREETYPE_LIBRARY FREETYPE_INCLUDE_DIRS)
Call Stack (most recent call first):
  C:/Program Files/CMake 2.8/share/cmake-2.8/Modules/FindFreetype.cmake:92 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  extern/mygui_3.0.1/CMakeLists.txt:7 (find_package)
I've installed freetype2 as said on the wiki,
SET FREETYPE_DIR="C:\Program Files\GnuWin32"

I've tried several settings of environment variables manualy like
FREETYPE_LIBRARY & FREETYPE_INCLUDE_DIRS to the directories that seems ok for me but it fails.

If somebody could help me, I'd be grateful (and I shall complete the wiki if needed)
athile wrote: Still struggling with the OpenMW build on Windows...a few more notes:

First, mangle's openal_out.cpp uses "AL/al.h". The FindOpenAL.cmake file indicates that apparently simply "al.h" is the correct way to include OpenAL headers...given that the Windows SDK provided by Creative does not put al.h under an AL subdirectory. In other words, "AL/al.h" is unfortunately not cross-platform.

Second, in order for the freetype headers to be found on my system for the MyGUI sub-project to build properly, I seem to need add "include_directories( ${FREETYPE_INCLUDE_DIRS}/freetype2 )" to the CMakeLists.txt for the mygui project. If others on the Windows side are seeing this too, maybe this could be added to the WIN32 section of the main CMakeFile.txt.

Sorry for the lack of definitive suggestions or a complete set of fixes on GitHub for the Windows build, but I still haven't managed a fully successful build myself.
nicolay wrote: Ok, forgive me but I've somewhat lost track of the current status on the Windows build. My questions are basically:

- what's the current status? (what works, what doesn't work, what's needed?)
- where are the instructions for the process currently written up (if anywhere?)
- what can I (or anybody) do to help?

Some general comments: I don't think putting binaries in the repos is a good idea, because of their size. However, packaging it in an external zip seems like a very good idea. We did something like that for pre-C++ versions, with the openmw-DLL-pack (see http://sourceforge.net/projects/openmw/files/ - in fact a couple of those DLLs might still be usable.)

I also think we should do what we can to cut down the number of steps required. For example, it shouldn't really be required to run CMake on Windows if we can just include the VC++ project files directly (these are pretty small.) Also, a script that auto-downloads dependencies (like someone suggested) could be nice too, but that's optional.

Any other ideas?

I don't have dev-access to a Windows machine but I should be able to borrow one for long enough to test the end result when it's done.
athile wrote: Summary as far as I know it (apologies in advance if this is incomplete or incorrect):

1. I managed a successful build, but it still crashed at shutdown. Star-Demon is the only other one that *I* am aware of that is attempting a Windows build on the recent source. There aren't a heck of a lot of platform-specific issues beyond the fact that dependencies are just always a pain on Windows.

2. I've posted a 7z file that contains all the Windows dependencies that, if extracted under a "prebuilt" directory under the OMW root, should "just work" on VS 2010 with the latest CMake changes. Once someone else confirms this, the wiki could likely afford to be updated. Also, posting the 7z file on openmw.org might be a good idea. (I can't post it to the wiki directly since it's over 10 MB.) My changes do *not* work for VS 2008 or for release builds of any sort; that still needs to be done. See this post: http://openmw.org/forum/viewtopic.php?f=13&t=54

3. I can help more when my newly convinced-myself-I-can-afford laptop arrives (next week hopefully?) so I don't have to punish my netbook with more compiling and debugging :) Also, it's tough to do anything useful when OpenMW runs at < 0.5 fps on your machine...


Lastly: I agree binaries in the repo is bad. Binaries in a zip on openmw.org, a lesser evil. I do disagree about avoiding CMake on Windows - I think CMake is far better, especially given that VS 2008 and VS2010 use different project file formats (.vcproj, .vcxproj). In my experience Visual Studio projects always end up being a pain eventually for one reason or another...I much prefer CMake, even if I don't think it's a perfect tool.


EDIT: My opinion, but I wouldn't hold up the 0.08 release for a Windows build unless someone can crank one out quickly. It's still real early (0.08) and the code seems in pretty solid shape in terms of remaining cross-platform.
Star-Demon wrote: If we are hurting on space we might want to look into hosting these extra files on TESNEXUS. That way if more things are required or would seem like a good but extra thing, there's already a home for it.

My only concern is if we're allowed to distribute these files in that way. Apparently if we can zip it we can. I say TESNexus is something worth looking into if we are hurting on space. It doesn't have to be public. It also draws publicity when people see that super project still updating.

I definitely think that, if we can standardize and generalize (the magic words) all of that as Nicolay says, then yeah, we can say, "Use the OGRE Deal that's HERE" and "use the blah blah That's here" And then we can have a VC project for everyone (by version) and then that lifts an entire load off the chest of all contributors - current and future. I'm behind that 100% if it means making it easier to access. (making it work, as well.)

Athile - It may be ogre. Ogre sample application likes to crash on shutdown me when I started learning it again shortly before joining. Then again, every Bethsoft game likes to crash at shutdown. Let's not inherit that legacy. :P

I'm really busy with the new semester's business, and I know this convo is taking place in three threads, but I will definitely be able to have more to and do once I update my junk this weekend, including the wiki.

A lot's been talked about in a day or so, huh? Good progress.

Let's see: This weekend I should (not ordered but should be):

- DL the package athile made
- Delete my build contents,
- update my fork and submodules.
- Restore my build folder
- Build all
- If it works, try to paste my morrowind backup into a Good to Go OpenMW.
- Update wiki pages to reflect new master build and changes.

Anything else you folks want me to try out?
nicolay wrote:
athile wrote:Also, posting the 7z file on openmw.org might be a good idea. (I can't post it to the wiki directly since it's over 10 MB.)
Thanks for the update. Hosting the file isn't a problem, that's what sourceforge is for. I'll upload it there once we have a confirmed working final version.
Also, it's tough to do anything useful when OpenMW runs at < 0.5 fps on your machine...
Yeah, we should do something about that ;) Do you have any clues why it's so slow? Eg. would it help using the release build of Ogre, or other rendering parameters (directx vs. opengl etc)? Also, if you have the time, you could try downloading the old binary + DLL pack (from v0.6, here: http://sourceforge.net/projects/openmw/files/ ) and see if that is slow too. Might help pinpoint the problem.
EDIT: My opinion, but I wouldn't hold up the 0.08 release for a Windows build unless someone can crank one out quickly. It's still real early (0.08) and the code seems in pretty solid shape in terms of remaining cross-platform.
No prob. That's pretty much up to you and SD to decide, since we depend on you for windows builds right now.
nicolay wrote:
Star-Demon wrote:I definitely think that, if we can standardize and generalize (the magic words) all of that as Nicolay says, then yeah, we can say, "Use the OGRE Deal that's HERE" and "use the blah blah That's here" And then we can have a VC project for everyone (by version) and then that lifts an entire load off the chest of all contributors - current and future. I'm behind that 100% if it means making it easier to access. (making it work, as well.)
I agree fully. One dependency less is always a good thing. I not sure if it is possible to generalize it enough though (I don't know enough about how VC projects work), but we'll figure this out in time, there's no rush. The CMake files would always be there of course, as an option for those who want to use them.
Let's see: This weekend I should (not ordered but should be):

- DL the package athile made
- Delete my build contents,
- update my fork and submodules.
- Restore my build folder
- Build all
- If it works, try to paste my morrowind backup into a Good to Go OpenMW.
- Update wiki pages to reflect new master build and changes.

Anything else you folks want me to try out?
That sounds good. If you get it to work, then it would be interesting to know if you get the same issues as athile (fps and crash), and if not, why not.
amos wrote: I also struggled a bit to get it compiled for windows.
After a couple of attempts I finally got it compiled with Visual Studio 2008.

I used the boost pro installer for getting the required boost libraries as my previous attempts at putting them in the Ogre directory did not work well.
I used the 1.42.0 installer found here: http://www.boostpro.com/download/

The environment variables I had to set was:

Code: Select all

set OGRE_HOME=..\OgreSDK
set BOOST_ROOT=C:\Program Files\boost\boost_1_42
set FREETYPE_DIR=C:\Program Files\GnuWin32
set AUDIERE_DIR=..\audiere-1.9.4-win32
As you see Ogre and Audiere was unzipped relative to the build dir while I used the installer for Freetype and OpenAL (and Boost).

I had to patch cmake/FindAudiere.cmake to let it look for audiere via the AUDIERE_DIR environment variable.

Code: Select all

diff --git a/cmake/FindAudiere.cmake b/cmake/FindAudiere.cmake
index 4cc1fb2..7942730 100644
--- a/cmake/FindAudiere.cmake
+++ b/cmake/FindAudiere.cmake
@@ -24,7 +24,9 @@
 
 FIND_PATH(AUDIERE_INCLUDE_DIR audiere.h
   HINTS
+  PATH_SUFFIXES include
   PATHS
+  $ENV{AUDIERE_DIR}
   ~/Library/Frameworks
   /Library/Frameworks
   /usr/local
@@ -40,6 +42,7 @@ FIND_LIBRARY(AUDIERE_LIBRARY
   HINTS
   PATH_SUFFIXES lib64 lib libs64 libs libs/Win32 libs/Win64
   PATHS
+  $ENV{AUDIERE_DIR}
   ~/Library/Frameworks
   /Library/Frameworks
   /usr/local
After this I ran cmake with some variables set (for boost and audiere):

Code: Select all

cmake -G "Visual Studio 9 2008" -D Boost_USE_STATIC_LIBS:BOOL=ON -D USE_AUDIERE:BOOL=ON -D USE_FFMPEG:BOOL=OFF -D USE_MPG123:BOOL=OFF ..\openmw
With the latest fixes by athile I was able to compile most of the code. The stdint.h include does not work as I'm using VS 2008, it is only included in 2010 and up. More info here: http://en.wikipedia.org/wiki/Stdint.h
My fix for this was to use boost/cstdint.h, and patch some code to accomodate this change.

After this I was able to compile it and run it as well, seems to be working quite well, no crashes on the cells I tried.

I have to agree that it should be much easier to get this up and working on a windows machine.

Perhaps Audiere should be the default sound engine on windows?
It could also look for Ogre and Audiere relative from the build dir.

In addition perhaps Cmake itself should get some patches, to make it a bit smarter when it comes to finding Boost and Freetype.

Anyway I'm at least ready now to help out with OpenMW development :). I've been eager to help out after I discovered this project on reddit.com. Quite a coincidence as I was considering starting a similar project as Morrowind is too unstable with several of the mods I was using.
Zini wrote: Welcome then!

Have you already decided what you want to work on?

On the roadmap for the next version at least the following tasks are up for grabs:
- Implement more GUI windows
- Find a better GUI font (not really a coder task)
- Music player

I am not so sure Terrain Rendering. I think Nico might want to take that, but I could be wrong here.

Besides the roadmap, there are a few other tasks, that are still open:
- the missing parts of the NIF implementation (NPC rendering, animations)
- the file name problem outside of BSA files (issue #5)

If there is something else, you want to work on, we can talk about it.
amos wrote: Thanks.

I haven't decided on anything yet, think I will read up on the morrowind-specific files/formats and look around in the codebase first. At first glance the GUI windows seems like a small enough task to start with, I'll let you know if I decide on anything.
Star-Demon wrote:
amos wrote:I have to agree that it should be much easier to get this up and working on a windows machine.
That's what I like to hear!

So, is it taken care of and part of the master fork, or do I need to do all the things you did and also switch to 2008?
nicolay wrote: @amos: Great work on the windows build. I've included the cmake changes you listed in the main repo. If/when you get running on github then let me know so I can include and test the rest of your changes as well. Hopefully we'll get all the other details of your post into the appropriate wiki pages as well.

And I agree that audiere would be the best default choice on Windows. It's stable, easily available precompiled and seems to just work.
amos wrote: I've forked the project and its submodules and commited my fixes.

The stdint.h fix:
http://github.com/am0s/mangle/commit/7f ... 87ea012827

I also did a fix for the openmw.cfg as it was reset each time cmake was run. Now its possible to set a path in the cmake config and have that placed in the config file, "data" is still the default.
http://github.com/am0s/openmw/commit/0f ... dc1e475633
amos wrote: Btw, I started working on the GUI windows. I've implemented the basic inventory window structure now, will work on the remaining windows this weekend.
Zini wrote: Inventory isn't exactly high on our priority list, though having it is good anyway. But actually we were more looking for the character creation windows and after that the dialogue window.
amos wrote:
Star-Demon wrote:So, is it taken care of and part of the master fork, or do I need to do all the things you did and also switch to 2008?
My VS 2008 fixes are not in the master fork yet, but if you have VS 2010 it should work without them. If you use the boost pro installer and follow my steps it should work, but you'll need to use the 1.44 version of the installer to get support for VS 2010.
Alternatively you can use the prebuilt binaries that athile made, that should be even easier.
nicolay wrote: Thanks for the fixes, I've pulled in your changes.
Star-Demon wrote:
amos wrote:
Star-Demon wrote:So, is it taken care of and part of the master fork, or do I need to do all the things you did and also switch to 2008?
My VS 2008 fixes are not in the master fork yet, but if you have VS 2010 it should work without them. If you use the boost pro installer and follow my steps it should work, but you'll need to use the 1.44 version of the installer to get support for VS 2010.
Alternatively you can use the prebuilt binaries that athile made, that should be even easier.
Okay, well I've done all that already. I think the only problem building on my system is the audio library (or lack of since I need a library or build my own).

But if we are going to throw in libraries, I don't have to deal with any of that anymore, right? Wasn't the idea for it to all be in there?

Wow. I'm beginning to see that forums are a bad way to communicate when it comes to some things...there's got to be a better way to do this...

Anyways, glad you're stepping up, amos - I feel bad not being experienced enough to having the time to crank things out to expectation, but as long as I can stay updated and look at stuff I can make sense out of it for everyone so they can crank stuff out.
athile wrote: For the record, both audiere and OpenAL are very easy to build from the source on Windows. They both built with no problems for me with VS2010.

Audiere source is downloadable here: http://audiere.sourceforge.net/download.php

For OpenAL don't use the annoying SDK. Grab the OpenAL source from SVN (http://connect.creativelabs.com/openal/ ... 0Code.aspx) and build the software implementation in the OpenAL-Soft subdirectory (it's CMake based so it more or less "just works").
Star-Demon wrote:
athile wrote:For the record, both audiere and OpenAL are very easy to build from the source on Windows. They both built with no problems for me with VS2010.

Audiere source is downloadable here: http://audiere.sourceforge.net/download.php

For OpenAL don't use the annoying SDK. Grab the OpenAL source from SVN (http://connect.creativelabs.com/openal/ ... 0Code.aspx) and build the software implementation in the OpenAL-Soft subdirectory (it's CMake based so it more or less "just works").
Cool stuff - I'll give that a try this weekend.
Locked