Horde3D
http://www.horde3d.org/forums/

MacOS X
http://www.horde3d.org/forums/viewtopic.php?f=8&t=288
Page 1 of 2

Author:  Vurlix [ 17.04.2008, 13:39 ]
Post subject:  MacOS X

I will keep this thread updated with links to MacOS X builds of the SDK.

Horde3D-1.0.0-beta1-osx

Known issues:
Chicago and Knight samples render incorrectly on NVidia 8800 GTS (and possibly others). Issue appears to be related to the AMBIENT shader contexts of skinning.shader.xml and parallax.shader.xml.

Author:  Vurlix [ 24.06.2008, 16:43 ]
Post subject:  Re: MacOS X

I've been having a lot of trouble running Horde on my system ever since the 0.1.15. With 1.0 betas, it's gotten worse. I've tried (unsuccessfully) figuring it out.. When I try to run any of the samples (as of svn r34), they crash at startup:

Code:
(gdb) bt
#0  0x93af755e in glgConvertTo_32<GLGConverter_RGB8_ARGB8, (GLGMemory)2> ()
#1  0x93af4eb3 in glgProcessPixelsWithProcessor ()
#2  0x13fa582a in gldAllocVertexBuffer ()
#3  0x13fa65ce in gldGetTextureLevel ()
#4  0x0073bd14 in gleGenMipmaps ()
#5  0x006147c1 in glTexImage2D_Exec ()
#6  0x943b09cb in glTexImage2D ()
#7  0x001e282b in RendererBase::uploadTextureCube (this=0x87a800, pixels=0xbffff45c, width=4, height=4, comps=24, hdr=false, cubeFace=5, allowCompression=false, mipmaps=true, filtering=true, texId=4) at Horde3D/Source/Horde3DEngine/egRendererBase.cpp:268
#8  0x001f8502 in TextureCubeResource::initializationFunc () at Horde3D/Source/Horde3DEngine/egTextures.cpp:333
#9  0x001e4b4a in ResourceManager::registerType (this=0x481970, type=8, typeString=@0xbffff550, inf=0x1f8358 <TextureCubeResource::initializationFunc()>, rf=0x1f8514 <TextureCubeResource::releaseFunc()>, ff=0x1abb22 <TextureCubeResource::factoryFunc(std::string const&, int)>) at Horde3D/Source/Horde3DEngine/egResource.cpp:168
#10 0x001a9dc5 in init () at Horde3D/Source/Horde3DEngine/egMain.cpp:104
#11 0x000035c1 in Application::init (this=0x873600) at Horde3D/Samples/Chicago/app.cpp:47
#12 0x00005ad3 in main (argc=1, argv=0xbffff6f8) at Horde3D/Samples/Chicago/main.cpp:163


From what I could gather from debugging, all the pointers seem valid and everything should work but... Obviously something is wrong. When commenting out the TextureCube resource type registration, like so:
Code:
      /* Modules::resMan().registerType( ResourceTypes::TextureCube, "TextureCube", TextureCubeResource::initializationFunc,
         TextureCubeResource::releaseFunc, TextureCubeResource::factoryFunc ); */


The samples run but the cubemapping doesn't work. Terrain sample works fine without cubemapping, though. This is on top of the previous issues I've already been having..

Author:  swiftcoder [ 24.06.2008, 16:54 ]
Post subject:  Re: MacOS X

Vurlix wrote:
I've been having a lot of trouble running Horde on my system ever since the 0.1.15. With 1.0 betas, it's gotten worse. I've tried (unsuccessfully) figuring it out.. When I try to run any of the samples (as of svn r34), they crash at startup...
Looks like you have driver issues with cubemaps - is this also affecting any commercial games? They are all running perfectly on my ATI card (although I haven't tried the latest from SVN.

Author:  Vurlix [ 24.06.2008, 17:27 ]
Post subject:  Re: MacOS X

Only 3d game I have on the mac side is quake3, and it works fine.

Author:  kal [ 24.06.2008, 18:41 ]
Post subject:  Re: MacOS X

I do not think q3 uses cubemaps.
edit: http://svn.icculus.org/quake3/trunk/cod ... iew=markup no cubemaps

Author:  swiftcoder [ 24.06.2008, 18:56 ]
Post subject:  Re: MacOS X

Vurlix wrote:
Only 3d game I have on the mac side is quake3, and it works fine.

Grab the Unreal Tournament 2004 Demo. Pretty sure they use cubemaps for all the environments.

Author:  Vurlix [ 25.06.2008, 15:28 ]
Post subject:  Re: MacOS X

This thread on the OGRE forums seems to be relevant: http://www.ogre3d.org/phpBB2/viewtopic.php?p=290454

Author:  swiftcoder [ 25.06.2008, 17:48 ]
Post subject:  Re: MacOS X

Vurlix wrote:
This thread on the OGRE forums seems to be relevant: http://www.ogre3d.org/phpBB2/viewtopic.php?p=290454
Sharp eyes there! Ja, looks as though we need a fallback to software mipmap generation as well.

Author:  Vurlix [ 25.06.2008, 20:30 ]
Post subject:  Re: MacOS X

Seems so. Horde *does* work with mipmaps disabled.


Or Nvidia could just fix their broken drivers! :twisted:

Author:  swiftcoder [ 25.06.2008, 21:16 ]
Post subject:  Re: MacOS X

Vurlix wrote:
Or Nvidia could just fix their broken drivers! :twisted:
Ja, fat chance of that - especially if they haven't fixed the problem on Windows yet :D

Author:  Vurlix [ 26.06.2008, 20:10 ]
Post subject:  Re: MacOS X

Anyway, here's a small patch to make horde svn r35 build on OSX. This should go into the main source tree.

Code:
diff -r 86da40d3823b -r 5d9af7f740e5 Horde3D/Dependencies/Source/glfw/macosx/platform.h
--- a/Horde3D/Dependencies/Source/glfw/macosx/platform.h   Tue Jun 24 10:24:01 2008 -0400
+++ b/Horde3D/Dependencies/Source/glfw/macosx/platform.h   Thu Jun 26 15:02:05 2008 -0400
@@ -43,7 +43,7 @@
 #include <sched.h>
 #include <pthread.h>
 #include <sys/sysctl.h>
-#include "../../Include/glfw.h"
+#include "../../../Include/glfw.h"
 
 
 //========================================================================
diff -r 86da40d3823b -r 5d9af7f740e5 Horde3D/Source/Horde3DEngine/utImage.cpp
--- a/Horde3D/Source/Horde3DEngine/utImage.cpp   Tue Jun 24 10:24:01 2008 -0400
+++ b/Horde3D/Source/Horde3DEngine/utImage.cpp   Thu Jun 26 15:02:05 2008 -0400
@@ -94,7 +94,9 @@
 #include <memory.h>
 #include <assert.h>
 #include <stdarg.h>
+#if defined(__i386__) || defined(__x86_64__)
 #include <emmintrin.h>
+#endif
 
 #ifndef _MSC_VER
 #define __forceinline
diff -r 86da40d3823b -r 5d9af7f740e5 Horde3D/Source/Horde3DUtils/main.cpp
--- a/Horde3D/Source/Horde3DUtils/main.cpp   Tue Jun 24 10:24:01 2008 -0400
+++ b/Horde3D/Source/Horde3DUtils/main.cpp   Thu Jun 26 15:02:05 2008 -0400
@@ -30,7 +30,9 @@
 #   define WIN32_LEAN_AND_MEAN 1
 #   include <windows.h>
 #endif
+#ifndef PLATFORM_MAC
 #include <GL/gl.h>
+#endif
 #include <cstdlib>
 #include <cstring>
 #include <string>

Author:  Volker [ 27.06.2008, 13:19 ]
Post subject:  Re: MacOS X

Thanks for that, I commited it with some slight adjustments.

Author:  swiftcoder [ 05.07.2008, 18:12 ]
Post subject:  Re: MacOS X

Ok, I just got the SVN head building on Mac. No real troubles, except for troubles with GLFW and paths - I will get a patch together soon.
Ignore the patch previously in this message, it was over complex.

Author:  swiftcoder [ 07.07.2008, 00:52 ]
Post subject:  Re: MacOS X

Here is a correct patch for the generatePath() function in the main.cpp of each sample. This does not require a patched GLFW, and can be applied directly to the SVN head.
Code:
string generatePath(char p[], const string& file) {
#ifdef __APPLE__
   string s(p);
   for (int i = 0; i < 4; i++)
      s = s.substr(0, s.rfind("/"));   
   return s + "/" + file;
#else
    const string s( p );
    if ( s.find("/") != string::npos) {
        return s.substr( 0, s.rfind( "/" ) ) + "/" + file;
    } else if ( s.find("\\") != string::npos ) {
        return s.substr( 0, s.rfind( "\\" ) ) + "\\" + file;
    } else {
        return file;
    }
#endif
}


Rationale: Mac argv[0] looks like this '/Applications/Knight.app/Contents/MacOS/Knight', so we have to strip off 4 slashes to get the actuall parent directory. This is because Mac applications are actually directories disguised as files.

Author:  Volker [ 09.07.2008, 07:40 ]
Post subject:  Re: MacOS X

Thanks for the patch. I integrated it into the SVN.

Page 1 of 2 All times are UTC + 1 hour
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/