- Download OSG 3.2.1 source from http://trac.openscenegraph.org/download ... -3.2.1.zip
- Donwload OSG dependencies from http://download.osgvisual.org/3rdParty_ ... V9_full.7z
- Unzip OpenSceneGraph-3.2.1.zip. Copy the unzipped files to OpenSceneGraph-3.2.1/OpenScenegraph. i.e. CMakeLists.txt is in OpenSceneGraph-3.2.1/OpenScenegraph.
- Unzip 3rdParty_VS2013_v120_x86_x64_V9_full.7z. Copy the contents of the x86 folder (I'm doing 32 bit builds) to OpenSceneGraph-3.2.1/OpenScenegraph/3rdParty
- Throw away the boost files from OpenSceneGraph-3.2.1/OpenScenegraph/3rdParty (it's 1.55, and I've got 1.57 installed.)
- Run cmake against OpenSceneGraph-3.2.1/OpenScenegraph, with settings suggested by scrawl.
- Get the following errors/warnings which I ignore. (I'm concerned about the QT warnings, osgQT is not created as a project to build.)
- Spoiler: Show
- Build the OSG project in MSVC. Some minor warnings, nothing to worry about.
- Now run CMAKE against OpenMW. Get the following errors. (I suspect I need to configure an environmental variable to say where OSG is, but I'm not sure.)
- Spoiler: Show
(not) building OpenMW + OSG on Windows.
(not) building OpenMW + OSG on Windows.
Steps
Re: (not) building OpenMW + OSG on Windows.
I'd recommend setting CMAKE_INSTALL_PATH for your OpenSceneGraph build and then building the INSTALL project, that will give you an OSG SDK folder that you can specify through the OSG_SDK CMake variable.
For OSG Qt, you might have to patch the Qt paths. As when you build Qt, the install paths for it are hardcoded into qmake. I know that my own Qt binaries came with a binary patcher for that.
For OSG Qt, you might have to patch the Qt paths. As when you build Qt, the install paths for it are hardcoded into qmake. I know that my own Qt binaries came with a binary patcher for that.
Re: (not) building OpenMW + OSG on Windows.
@Ace, thanks for the help.
Rebuilding QT and adding the QT to the PATH environmental variable fixed the issue with building osgQT.
And I manually added the QT libraries to the OpenMW cmake variables.
(Did you perhaps mean "CMAKE_INSTALL_PREFIX", not "CMAKE_INSTALL_PATH")
It now builds.
And it starts to run on Windows.
However, it crashes when:
Rebuilding QT and adding the QT to the PATH environmental variable fixed the issue with building osgQT.
And I manually added the QT libraries to the OpenMW cmake variables.
(Did you perhaps mean "CMAKE_INSTALL_PREFIX", not "CMAKE_INSTALL_PATH")
It now builds.
And it starts to run on Windows.
However, it crashes when:
- I click on the "Load Game" option at the start.
- Immediately when I exit the ship when I start a new game.
Some points to note:MyGUI EXCEPTION: texture pointer is not valie, texture name ''
in MyGUI at \MyGUIEngine\scr\MyGUI_RenderItem.cpp (line 83)
- "Options" from the start menu works.
- The dialog to give your name at the start works.
- I did rebuild MyGUI using Scrawl's changed cmake settings, and dropped the new DLL into the debug directory.
- The various splash sceens you get at the start do appear.
- Spoiler: Show
Re: (not) building OpenMW + OSG on Windows.
Looks like you are the first to test MyGUI in debug mode. Try this:
Code: Select all
diff --git a/components/myguiplatform/myguirendermanager.cpp b/components/myguiplatform/myguirendermanager.cpp
index 773c58a..3ba5783 100644
--- a/components/myguiplatform/myguirendermanager.cpp
+++ b/components/myguiplatform/myguirendermanager.cpp
@@ -521,12 +521,8 @@ void RenderManager::destroyAllResources()
bool RenderManager::checkTexture(MyGUI::ITexture* _texture)
{
- for (MapTexture::const_iterator item = mTextures.begin(); item != mTextures.end(); ++item)
- {
- if (item->second == _texture)
- return true;
- }
- return false;
+ // We support external textures that aren't registered via this manager, so can't implement this method sensibly.
+ return true;
}
}
Re: (not) building OpenMW + OSG on Windows.
Thanks Scrawl.
I have good news and bad news.
The good news, "Load" screen now appears, and I'm able to load some save games.
The bad news:
When start game, leaving boat fails in new place.
When click on the "Hatch to Seyda Neen", the "Loading Area" dialog appears with a progress bar that starts, then there's an invalid pointer error.
I get the same failure when I try to load a save game which has "Seyda Neen" as the cell.
Note, I have no problem loading the Balmora City cell, nor "Belmora, South Wall CornerClub".
Details:
> osg100-osgd.dll!osg::BufferObject::getOrCreateGLBufferObject(unsigned int contextID) Line 590 C++
At this point, _glBufferObjects is an empty array. (contextID is 0)
I have good news and bad news.
The good news, "Load" screen now appears, and I'm able to load some save games.
The bad news:
When start game, leaving boat fails in new place.
When click on the "Hatch to Seyda Neen", the "Loading Area" dialog appears with a progress bar that starts, then there's an invalid pointer error.
I get the same failure when I try to load a save game which has "Seyda Neen" as the cell.
Note, I have no problem loading the Balmora City cell, nor "Belmora, South Wall CornerClub".
Details:
stack trace:Unhandled exception at 0x534FB3B1 (osg100-osgd.dll) in openmw.exe: 0xC0000005: Access violation writing location 0xABABABAB.
- Spoiler: Show
> osg100-osgd.dll!osg::BufferObject::getOrCreateGLBufferObject(unsigned int contextID) Line 590 C++
Code: Select all
GLBufferObject* getOrCreateGLBufferObject(unsigned int contextID) const
{
if (!_glBufferObjects[contextID]) _glBufferObjects[contextID] = GLBufferObject::createGLBufferObject(contextID, this);
return _glBufferObjects[contextID].get();
}
Re: (not) building OpenMW + OSG on Windows.
Do you have the stack trace for all threads?
Re: (not) building OpenMW + OSG on Windows.
Regretably, no.scrawl wrote:Do you have the stack trace for all threads?
I assume you're suspecting a race condition?
If so, you could be right. Problem is now not showing itself.
But I swear, I was able to reproduce multiple times.
Next time I catch it, I should be able to get you a full set of stack traces.
Re: (not) building OpenMW + OSG on Windows.
That isn't a problem. The operator[] automatically resizes the array to the required size on access.At this point, _glBufferObjects is an empty array. (contextID is 0)
Yes. The same problem was reported here, but we haven't had any luck reproducing it.I assume you're suspecting a race condition?
Re: (not) building OpenMW + OSG on Windows.
I think you're mistaken. (But I'd be happy to be proven wrong.)scrawl wrote:That isn't a problem. The operator[] automatically resizes the array to the required size on access.At this point, _glBufferObjects is an empty array. (contextID is 0)
http://www.cplusplus.com/reference/vector/vector/
(see the operator[]) entry.)
When _glBufferObjects is empty, doing this (even with a contextID = 0)Portable programs should never call this function with an argument n that is out of range, since this causes undefined behavior.
Code: Select all
if (!_glBufferObjects[contextID])
Re: (not) building OpenMW + OSG on Windows.
_glBufferObjects is a GLBufferObjects, aka osg::buffered_object<osg::ref_ptr<GLBufferObject>>. An osg::buffered_object automatically resizes with operator[].dteviot wrote:I think you're mistaken. (But I'd be happy to be proven wrong.)
http://www.cplusplus.com/reference/vector/vector/
(see the operator[]) entry.)