About configuration: -------------------- Ogre3D 1.9.0 happilly assembles its configuration files for the current system it is built on. This is quite new, in previous versions this had to be done by hand. Unfortunately the official ebuild stows those files away into /usr/share/doc/ogre-1.9.0/examples - But those aren't examples any more. Of course those configuration files have the build (CMAKE_BUILD_DIR) paths and some wrong subdirectories in them, but those are easily fixable. I have updated the ebuild (fetchable from my overlay 'seden' as ogre-1.9.0-r1) to substitute the paths and install the files into /etc/OGRE and /usr/share/OGRE. The former path is the classic configuration path, so plugins.cfg and resources.cfg go in there. The latter is the default path where Ogre looks for its configs, so quakemap.cfg and samples.cfg go in there. All four files are cross-symlinked. I find this more convenient as a developer. I can edit in /etc and Ogre finds the file where it expects them. SampleBrowser now works right after the merge. About missing features: ----------------------- Ogre3D 1.9 has new (experimental) support for OpenGL 3+ as a new RenderSystem plugin, and can enable OpenGL ES 3.0 support (experimental) in its OpenGL ES 2.0 RenderSystem plugin. Further it can have an openGL ES 1.0 RenderSystem plugin. I have added the USE flags 'gles1', 'gles3' and 'gl3plus' to reflect them. OpenGL 3+ and any GL ES systems are mutually exclusive, and GL ES 3.0 needs GL ES 2.0 of course. I have added these USE flag constraints to REQUIRED_USE. An ebuild patch will follow. Reproducible: Always Steps to Reproduce: 1. Emerge dev-games/ogre-1.9.0 2. Start SampleBrowser Actual Results: SampleBrowser can not find any plugins or samples due to missing configuration. Expected Results: SampleBrowser works out of the box.
Created attachment 373736 [details, diff] add missing features and install configuration The patch changes the current ebuild to the one from my overlay.
Suggestion for metadata.xml USE flag descriptions: <flag name="gl3plus">build OpenGL 3+ RenderSystem (EXPERIMENTAL)</flag> <flag name="gles1">build OpenGL ES 1.x RenderSystem</flag> <flag name="gles3">add ES 3.0 support in the OpenGL ES 2.x RenderSystem (EXPERIMENTAL)</flag> And one "tiny" request: I have no idea which versions of media-libs/mesa are really required for the distinct features. Those depends should be reviewed. All I can say is, that I have mesa-10.1.0 installed and am offered both OpenGL 3+ and GL ES 3.0 support with intel HD graphics (on Haswell Mobile). However, the OpenGL 3+ RenderSystem does not work on my laptop, because 'glXCreateContextAttribsARB' is missing. The glXCreateContextAttribsARB API requires GLX 1.4, and at least OpenGL 3.0 (but really 3.2). And the intel driver only implements up to 3.0 currently. :-( ( Could someone with an nvidia card possibly test? That shoudl support up to 3.3.
last time I tested gles1 it was broken
regarding all the config files seds: - I don't like so many variables in global scope - it would probably make sense to have a separate cmake variable for these config values that have the old values as fallback. We could then upstream that patch instead of keeping sed hackery
(In reply to Julian Ospald (hasufell) from comment #3) > last time I tested gles1 it was broken Maybe. I have only tested GLES2 on Radeon Venus XT, and it worked. However, both GLES1 and GLES2 are no longer marked as "[EXPERIMENTAL]" in CMakeLists.txt... (In reply to Julian Ospald (hasufell) from comment #4) > regarding all the config files seds: > - I don't like so many variables in global scope Me neither. > - it would probably make sense to have a separate cmake variable for these > config values that have the old values as fallback. We could then upstream > that patch instead of keeping sed hackery Yes, and I bet it is already possible. Unfortunately I have not much knowledge about cmake, as I do not use it anywhere. It could take a while to figure that one out. Basically I do this by reading the resulting Makefiles. But since then, a chain of sed calls is better than configuration files that have the portage work directory prefixed everywhere leaving an inoperable state.
Any progress here? openmw-0.33 depends on ogre-1.9 -- Looking for OGRE_RTShaderSystem... -- Found OGRE_RTShaderSystem: optimized;/usr/lib64/libOgreRTShaderSystem.so;debug;/usr/lib64/libOgreRTShaderSystem.so CMake Error at CMakeLists.txt:225 (message): OpenMW requires Ogre 1.9 or later, please install the latest stable version from http://ogre3d.org
(In reply to Attila Stehr from comment #6) > Any progress here? openmw-0.33 depends on ogre-1.9 > Does it work with dev-games/ogre-1.9.0-r1 from my overlay "seden" (via layman) ?
(In reply to Attila Stehr from comment #6) > Any progress here? openmw-0.33 depends on ogre-1.9 > Last time I tried openmw, it didn't compile anyway. There seems to be very little QA on that side.
(In reply to Sven Eden from comment #5) > (In reply to Julian Ospald (hasufell) from comment #3) > > last time I tested gles1 it was broken > > Maybe. I have only tested GLES2 on Radeon Venus XT, and it worked. However, > both GLES1 and GLES2 are no longer marked as "[EXPERIMENTAL]" in > CMakeLists.txt... > Too vague and I usually don't trust any upstream. This should be figured out. > (In reply to Julian Ospald (hasufell) from comment #4) > > regarding all the config files seds: > > - I don't like so many variables in global scope > > Me neither. > This should be fixed then. > > - it would probably make sense to have a separate cmake variable for these > > config values that have the old values as fallback. We could then upstream > > that patch instead of keeping sed hackery > > Yes, and I bet it is already possible. Unfortunately I have not much > knowledge about cmake, as I do not use it anywhere. It could take a while to > figure that one out. Basically I do this by reading the resulting Makefiles. > If you can come up with a basic patch people will be able to help.
(In reply to Sven Eden from comment #7) > (In reply to Attila Stehr from comment #6) > > Any progress here? openmw-0.33 depends on ogre-1.9 > > > > Does it work with dev-games/ogre-1.9.0-r1 from my overlay "seden" (via > layman) ? Ogre and openmw-9999 are emerged w/o any problem. [ebuild R #] games-engines/openmw-9999::eroen USE="launcher -minimal opencs -profile {-test} tr1" 0 KiB >>> Emerging (1 of 1) games-engines/openmw-9999::eroen >>> Installing (1 of 1) games-engines/openmw-9999::eroen >>> Jobs: 1 of 1 complete But I get the following error when I run omwlauncher. "Could not find settings-default.cfg The problem may be due to an incomplete installation of OpenMW. Reinstalling OpenMW may resolve the problem." (It does not!) ## config files are still put into /etc $ ll /etc/openmw/ total 28 -rw-r----- 1 root games 0 Oct 29 10:24 opencs.ini -rw-r----- 1 root games 202 Oct 29 10:31 openmw.cfg -rw-r----- 1 root games 5007 Oct 29 10:24 settings-default.cfg -rw-r----- 1 root games 12904 Oct 29 10:24 transparency-overrides.cfg ## but openmw excpects settings-default.cfg in /usr/games/etc/openmw $ strace -e trace=all omwlauncher 2>&1 | grep settings-default.cfg lstat("settings-default.cfg", 0x7fffc81a1520) = -1 ENOENT (No such file or directory) lstat("/usr/games/etc/openmw/settings-default.cfg", 0x7fffc81a1520) = -1 ENOENT (No such file or directory) ## /usr/games/etc does not exist $ ll /usr/games/ total 8 drwxr-x--- 2 root games 4096 Oct 29 10:31 bin drwxr-x--- 2 root games 4096 Oct 29 10:31 lib ## my workaround: mkdir /usr/games/etc ln -s /etc/openmw /usr/games/etc/openmw chown :games /usr/games/etc/openmw
(In reply to Julian Ospald (hasufell) from comment #9) > (In reply to Sven Eden from comment #5) > > (In reply to Julian Ospald (hasufell) from comment #3) > > > last time I tested gles1 it was broken > > > > Maybe. I have only tested GLES2 on Radeon Venus XT, and it worked. However, > > both GLES1 and GLES2 are no longer marked as "[EXPERIMENTAL]" in > > CMakeLists.txt... > > > > Too vague and I usually don't trust any upstream. This should be figured out. I no longer have the VenusXT card, the AMD hybrids do not really work with multiple monitor setups and I switched to an nvidia Quadro K2100M. Here I tested (using 'primusrun') the SampleBrowser with: - OpenGL Rendering Subsystem - OpenGL 3+ Rendering Subsystem (EXPERIMENTAL) For GLES[123] I have to re-install, as GL3+ and GLES* are mutually exclusive. - GLES1 seems to be broken indeed. It won't compile with that USE Flag on. As GLES1 is a bit old (if not deprecated?) I am currently thinking about removing that USE flag. - GLES2 with and without GLES3 support causes the SampleBrowser to crash. No idea why, it worked before. (In reply to Julian Ospald (hasufell) from comment #9) > > > - I don't like so many variables in global scope > If you can come up with a basic patch people will be able to help. Let's see what I can find out.
Hmmm... I let the SampleBrowser core dump with GLES2 enabled, and I can not see anything implying my system in the backtrace. But GLES2 worked before, with and without GLES3 support enabled, so this is a bit of a riddle to me right now. I recently switched to gcc-4.9.1, but did not recompile my whole system. Could this be a problem? For reference, here is the backtrace, if anybody can see more than me. -------- #0 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00007f7e04c886cb in Ogre::GLES2HardwareVertexBuffer::lockImpl (this=0x7f7e07febf58, offset=0, length=9248, options=<optimized out>) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/RenderSystems/GLES2/src/OgreGLES2HardwareVertexBuffer.cpp:131 #2 0x00007f7e04c8663d in Ogre::HardwareBuffer::lock (this=0x7f7e07febf58, offset=0, length=9248, options=<optimized out>) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/include/OgreHardwareBuffer.h:208 #3 0x00007f7e0d62718f in lock () at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/include/OgreHardwareBuffer.h:222 #4 Ogre::PrefabFactory::createSphere(Ogre::Mesh*) (mesh=mesh@entry=0x7f7e08f37fd8) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgrePrefabFactory.cpp:309 #5 0x00007f7e0d62772a in Ogre::PrefabFactory::createPrefab(Ogre::Mesh*) (mesh=mesh@entry=0x7f7e08f37fd8) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgrePrefabFactory.cpp:53 #6 0x00007f7e0d73b94b in Ogre::MeshManager::loadResource (this=0x7f7e08f2ef78, res=0x7f7e08f37fd8) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreMeshManager.cpp:401 #7 0x00007f7e0d609c97 in Ogre::Resource::load(bool) (this=0x7f7e08f37fd8, background=<optimized out>) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreResource.cpp:208 #8 0x00007f7e0d73bec5 in Ogre::MeshManager::createPrefabSphere (this=0x7f7e08f2ef78) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreMeshManager.cpp:383 #9 0x00007f7e0d644d3a in Ogre::MeshManager::_initialise (this=<optimized out>) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreMeshManager.cpp:84 #10 0x00007f7e0d5ef1b8 in Ogre::Root::oneTimePostWindowInit (this=0x7f7e08f265f8) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreRoot.cpp:1388 #11 0x00007f7e0d5f19cb in Ogre::Root::initialise (this=0x7f7e08f265f8, autoCreateWindow=autoCreateWindow@entry=true, windowTitle=..., customCapabilitiesConfig=...) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/OgreMain/src/OgreRoot.cpp:695 #12 0x000000000041cc52 in createWindow (this=0x7fff43bd9980) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/Samples/Browser/include/SampleBrowser.h:1263 #13 OgreBites::SampleBrowser::setup() (this=0x7fff43bd9980) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/Samples/Browser/include/SampleBrowser.h:1062 #14 0x0000000000417877 in initApp (initialSample=0x0, this=0x7fff43bd9980) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/Samples/Common/include/SampleContext.h:266 #15 OgreBites::SampleContext::go(OgreBites::Sample*) (this=this@entry=0x7fff43bd9980, initialSample=initialSample@entry=0x0) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/Samples/Common/include/SampleContext.h:323 #16 0x00000000004075f2 in main (argc=<optimized out>, argv=0x7fff43bd9c88) at /home/portage/dev-games/ogre-1.9.0-r1/work/ogre-1.9.0/Samples/Browser/src/SampleBrowser.cpp:116 -------- btw.: The backtraces are the same whether I use primusrun or the intel HD chipset.
Created attachment 387724 [details, diff] Update ogre-1.9.0-r1.ebuild to ogre-1.9.0-r2.ebuild Okay, I have uploaded a new dev-games/ogre-1.9.0-r2.ebuild to my overlay (seden) which has the following changes: - USE flag "GLES1" is gone - The new USE flag "source" can be used to install the examples sources - The sed'ing is gone, I found the two blocks in CMake/InstallResources.cmake that where causing the wrong paths in the configuration files. - The global variables are gone, as they are no longer needed without the sed'ing. Please have a look. :-) The changes are rather big, but as some prefer a patch... ;-)
Created attachment 387726 [details, diff] first path fix change from build dir to install dir
Created attachment 387728 [details, diff] second path fix change from build dir to install dir
I have reported the configuration path problem upstream: https://ogre3d.atlassian.net/browse/OGRE-445
(In reply to Sven Eden from comment #13) > Okay, I have uploaded a new dev-games/ogre-1.9.0-r2.ebuild to my overlay > (seden) which has the following changes: if relevant: works well here
* REQUIRED_USE is a bit overcomplicated, we could probably make use of: ?? ( gl3plus ( || ( gles2 gles3 ) ) ) * I don't understand the purpose of TESTDIR at all. It isn't used, it isn't installed. * name the patches ${P}-foo.patch * source USE flag is unintuitive, just install the source under the examples use flag * MY_PV and versionator usage looks obsolete * quote variables, unless it's a variable assignment * both patches should just remove the lines instead of commenting them
+*ogre-1.9.0-r1 (05 Nov 2014) + + 05 Nov 2014; Julian Ospald <hasufell@gentoo.org> +ogre-1.9.0-r1.ebuild, + +files/ogre-1.9.0-remove_media_path_to_bindir.patch, + +files/ogre-1.9.0-remove_resource_path_to_bindir.patch, metadata.xml: + fix bug #506058, thanks to Sven Eden whether those path issues are actually fixed, I cannot tell, but it's masked anyway, so if it's wrong, people will complain I guess
(In reply to Julian Ospald (hasufell) from comment #18) > * REQUIRED_USE is a bit overcomplicated, we could probably make use of: > ?? ( gl3plus ( || ( gles2 gles3 ) ) ) I haven't seen the "??" variant anywhere, yet. That's just great! > * I don't understand the purpose of TESTDIR at all. It isn't used, it isn't > installed. Ooops... orphaned and forgotten, then. > * name the patches ${P}-foo.patch I'll do, thanks. > * source USE flag is unintuitive, just install the source under the examples > use flag Yes. Yes, this should be in order. I added the line <flag name="source">Install the examples sources</flag> to metadata.xml, though. You know, for when someone wants the SampleBrowser working but doesn't care about the sources. > * MY_PV and versionator usage looks obsolete What would be the better? This is all I know to handle version reduction. (I'll look into the new ebuild in the tree) > * quote variables, unless it's a variable assignment Even if it is guaranteed that it can not have any white space? > * both patches should just remove the lines instead of commenting them Yes, you are right, sorry. Thank you very much for your feedback! This is invaluable information for me!
