OgreOde on OS X

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
marcoc
Gnoblar
Posts: 9
Joined: Fri Jan 02, 2004 10:18 am
Location: Milano, Italy

OgreOde on OS X

Post by marcoc »

Hi!
I'm trying to compile OgreOde on OS X, but I get these errors when compiling OgreOdeWorld.cpp:

Code: Select all

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h: In member function `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&, long unsigned int) const [with _Val = std::pair<dxBody* const, OgreOde::Body*>, _Key = dxBody*, _HashFcn = __gnu_cxx::hash<dxBody*>, _ExtractKey = std::_Select1st<std::pair<dxBody* const, OgreOde::Body*> >, _EqualKey = std::equal_to<dxBody*>, _Alloc = std::allocator<OgreOde::Body*>]':

OgreOdeWorld.cpp:569:   instantiated from `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&) const [with _Val = std::pair<dxBody* const, OgreOde::Body*>, _Key = dxBody*, _HashFcn = __gnu_cxx::hash<dxBody*>, _ExtractKey = std::_Select1st<std::pair<dxBody* const, OgreOde::Body*> >, _EqualKey = std::equal_to<dxBody*>, _Alloc = std::allocator<OgreOde::Body*>]'

OgreOdeWorld.cpp:509:   instantiated from `__gnu_cxx::_Hashtable_iterator<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc> __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const _Key&) [with _Val = std::pair<dxBody* const, OgreOde::Body*>, _Key = dxBody*, _HashFcn = __gnu_cxx::hash<dxBody*>, _ExtractKey = std::_Select1st<std::pair<dxBody* const, OgreOde::Body*> >, _EqualKey = std::equal_to<dxBody*>, _Alloc = std::allocator<OgreOde::Body*>]'

OgreOdeWorld.cpp:188:   instantiated from `typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFcn, _EqualKey, _Alloc>::find(typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::key_type&) [with _Key = dxBody*, _Tp = OgreOde::Body*, _HashFcn = __gnu_cxx::hash<dxBody*>, _EqualKey = std::equal_to<dxBody*>, _Alloc = std::allocator<OgreOde::Body*>]'

OgreOdeWorld.cpp:208:   instantiated from here

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxBody*>) (dxBody* const&)'

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h: In member function `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&, long unsigned int) const [with _Val = std::pair<dxJointGroup* const, OgreOde::JointGroup*>, _Key = dxJointGroup*, _HashFcn = __gnu_cxx::hash<dxJointGroup*>, _ExtractKey = std::_Select1st<std::pair<dxJointGroup* const, OgreOde::JointGroup*> >, _EqualKey = std::equal_to<dxJointGroup*>, _Alloc = std::allocator<OgreOde::JointGroup*>]':

OgreOdeWorld.cpp:569:   instantiated from `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&) const [with _Val = std::pair<dxJointGroup* const, OgreOde::JointGroup*>, _Key = dxJointGroup*, _HashFcn = __gnu_cxx::hash<dxJointGroup*>, _ExtractKey = std::_Select1st<std::pair<dxJointGroup* const, OgreOde::JointGroup*> >, _EqualKey = std::equal_to<dxJointGroup*>, _Alloc = std::allocator<OgreOde::JointGroup*>]'
/Users/silver/ogrenew/OgreOde/src/OgreOdeWorld.cpp:509:   instantiated from `__gnu_cxx::_Hashtable_iterator<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc> __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const _Key&) [with _Val = std::pair<dxJointGroup* const, OgreOde::JointGroup*>, _Key = dxJointGroup*, _HashFcn = __gnu_cxx::hash<dxJointGroup*>, _ExtractKey = std::_Select1st<std::pair<dxJointGroup* const, OgreOde::JointGroup*> >, _EqualKey = std::equal_to<dxJointGroup*>, _Alloc = std::allocator<OgreOde::JointGroup*>]'

OgreOdeWorld.cpp:188:   instantiated from `typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFcn, _EqualKey, _Alloc>::find(typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::key_type&) [with _Key = dxJointGroup*, _Tp = OgreOde::JointGroup*, _HashFcn = __gnu_cxx::hash<dxJointGroup*>, _EqualKey = std::equal_to<dxJointGroup*>, _Alloc = std::allocator<OgreOde::JointGroup*>]'

OgreOdeWorld.cpp:228:   instantiated from here

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxJointGroup*>) (dxJointGroup* const&)'

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h: In member function `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&, long unsigned int) const [with _Val = std::pair<dxJoint* const, OgreOde::Joint*>, _Key = dxJoint*, _HashFcn = __gnu_cxx::hash<dxJoint*>, _ExtractKey = std::_Select1st<std::pair<dxJoint* const, OgreOde::Joint*> >, _EqualKey = std::equal_to<dxJoint*>, _Alloc = std::allocator<OgreOde::Joint*>]':

OgreOdeWorld.cpp:569:   instantiated from `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&) const [with _Val = std::pair<dxJoint* const, OgreOde::Joint*>, _Key = dxJoint*, _HashFcn = __gnu_cxx::hash<dxJoint*>, _ExtractKey = std::_Select1st<std::pair<dxJoint* const, OgreOde::Joint*> >, _EqualKey = std::equal_to<dxJoint*>, _Alloc = std::allocator<OgreOde::Joint*>]'

OgreOdeWorld.cpp:509:   instantiated from `__gnu_cxx::_Hashtable_iterator<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc> __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const _Key&) [with _Val = std::pair<dxJoint* const, OgreOde::Joint*>, _Key = dxJoint*, _HashFcn = __gnu_cxx::hash<dxJoint*>, _ExtractKey = std::_Select1st<std::pair<dxJoint* const, OgreOde::Joint*> >, _EqualKey = std::equal_to<dxJoint*>, _Alloc = std::allocator<OgreOde::Joint*>]'

OgreOdeWorld.cpp:188:   instantiated from `typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFcn, _EqualKey, _Alloc>::find(typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::key_type&) [with _Key = dxJoint*, _Tp = OgreOde::Joint*, _HashFcn = __gnu_cxx::hash<dxJoint*>, _EqualKey = std::equal_to<dxJoint*>, _Alloc = std::allocator<OgreOde::Joint*>]'

OgreOdeWorld.cpp:248:   instantiated from here

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxJoint*>) (dxJoint* const&)'
/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h: In member function `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&, long unsigned int) const [with _Val = std::pair<dxGeom* const, OgreOde::Geometry*>, _Key = dxGeom*, _HashFcn = __gnu_cxx::hash<dxGeom*>, _ExtractKey = std::_Select1st<std::pair<dxGeom* const, OgreOde::Geometry*> >, _EqualKey = std::equal_to<dxGeom*>, _Alloc = std::allocator<OgreOde::Geometry*>]':

OgreOdeWorld.cpp:569:   instantiated from `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&) const [with _Val = std::pair<dxGeom* const, OgreOde::Geometry*>, _Key = dxGeom*, _HashFcn = __gnu_cxx::hash<dxGeom*>, _ExtractKey = std::_Select1st<std::pair<dxGeom* const, OgreOde::Geometry*> >, _EqualKey = std::equal_to<dxGeom*>, _Alloc = std::allocator<OgreOde::Geometry*>]'
/Users/silver/ogrenew/OgreOde/src/OgreOdeWorld.cpp:509:   instantiated from `__gnu_cxx::_Hashtable_iterator<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc> __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const _Key&) [with _Val = std::pair<dxGeom* const, OgreOde::Geometry*>, _Key = dxGeom*, _HashFcn = __gnu_cxx::hash<dxGeom*>, _ExtractKey = std::_Select1st<std::pair<dxGeom* const, OgreOde::Geometry*> >, _EqualKey = std::equal_to<dxGeom*>, _Alloc = std::allocator<OgreOde::Geometry*>]'

OgreOdeWorld.cpp:188:   instantiated from `typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFcn, _EqualKey, _Alloc>::find(typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::key_type&) [with _Key = dxGeom*, _Tp = OgreOde::Geometry*, _HashFcn = __gnu_cxx::hash<dxGeom*>, _EqualKey = std::equal_to<dxGeom*>, _Alloc = std::allocator<OgreOde::Geometry*>]'

OgreOdeWorld.cpp:273:   instantiated from here

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxGeom*>) (dxGeom* const&)'

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h: In member function `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&, long unsigned int) const [with _Val = std::pair<dxSpace* const, OgreOde::Space*>, _Key = dxSpace*, _HashFcn = __gnu_cxx::hash<dxSpace*>, _ExtractKey = std::_Select1st<std::pair<dxSpace* const, OgreOde::Space*> >, _EqualKey = std::equal_to<dxSpace*>, _Alloc = std::allocator<OgreOde::Space*>]':

OgreOdeWorld.cpp:569:   instantiated from `size_t __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::_M_bkt_num_key(const _Key&) const [with _Val = std::pair<dxSpace* const, OgreOde::Space*>, _Key = dxSpace*, _HashFcn = __gnu_cxx::hash<dxSpace*>, _ExtractKey = std::_Select1st<std::pair<dxSpace* const, OgreOde::Space*> >, _EqualKey = std::equal_to<dxSpace*>, _Alloc = std::allocator<OgreOde::Space*>]'

OgreOdeWorld.cpp:509:   instantiated from `__gnu_cxx::_Hashtable_iterator<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc> __gnu_cxx::hashtable<_Val, _Key, _HashFcn, _ExtractKey, _EqualKey, _Alloc>::find(const _Key&) [with _Val = std::pair<dxSpace* const, OgreOde::Space*>, _Key = dxSpace*, _HashFcn = __gnu_cxx::hash<dxSpace*>, _ExtractKey = std::_Select1st<std::pair<dxSpace* const, OgreOde::Space*> >, _EqualKey = std::equal_to<dxSpace*>, _Alloc = std::allocator<OgreOde::Space*>]'

OgreOdeWorld.cpp:188:   instantiated from `typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::iterator __gnu_cxx::hash_map<_Key, _Tp, _HashFcn, _EqualKey, _Alloc>::find(typename __gnu_cxx::hashtable<std::pair<const _Key, _Tp>, _Key, _HashFcn, std::_Select1st<std::pair<const _Key, _Tp> >, _EqualKey, _Alloc>::key_type&) [with _Key = dxSpace*, _Tp = OgreOde::Space*, _HashFcn = __gnu_cxx::hash<dxSpace*>, _EqualKey = std::equal_to<dxSpace*>, _Alloc = std::allocator<OgreOde::Space*>]'

OgreOdeWorld.cpp:293:   instantiated from here

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxSpace*>) (dxSpace* const&)'
Is that because I'm not using STLport?

Thanks in advance
User avatar
temas
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 390
Joined: Sun Oct 06, 2002 11:19 pm
Location: The Woodlands, TX

Post by temas »

You probably need to define GCC_3_1 and EXT_HASH.
marcoc
Gnoblar
Posts: 9
Joined: Fri Jan 02, 2004 10:18 am
Location: Milano, Italy

Post by marcoc »

They were already defined. I had to replace every stdext::hash_map with HashMap but then I get these errors...
Smithers
Gnoblar
Posts: 6
Joined: Mon Jul 05, 2004 10:07 pm
Location: Banbury, England

Post by Smithers »

marcoc wrote:They were already defined. I had to replace every stdext::hash_map with HashMap but then I get these errors...
Did you get this working marcoc? I'd be interested to hear how you got on since I'm running into similar problems. Thanks.
marcoc
Gnoblar
Posts: 9
Joined: Fri Jan 02, 2004 10:18 am
Location: Milano, Italy

Post by marcoc »

Actually I didn't get that really working. I believe that the problem comes from a different implementation of hash maps in g++ STL and STLport.
I simply tried to write my own hash functions.
For example if g++ tells me that there is no

Code: Select all

__gnu_cxx::hash<dxBody*>
to call, I will add

Code: Select all

namespace __gnu_cxx
{
    template <> struct hash< dxGeom* >
    {
        size_t operator()( const dxGeom* geom ) const 
        { 
            return (long)geom;
        }
    };
}
But the question is: do my own hash function implementations work?
All the tests work correctly, except from the crash test which crashes :wink: when the rockets hit the boxes. I didn't have so much time to indagate on that these days, but the problem seems to be connected with the rocket_list hash map. My knowledge about the STL is a bit poor. Maybe I will work again on that the next week.
I hope that this helps a bit...
Smithers
Gnoblar
Posts: 6
Joined: Mon Jul 05, 2004 10:07 pm
Location: Banbury, England

Post by Smithers »

Thanks for the reply marcoc, it's odd, I'm not getting any errors from the hash maps after replacing them with HashMap as you did (at least not so far).

The errors I'm seeing now are things like:

Code: Select all

OgreOdeBody.cpp:21: error: `BLANK' is not a member of type `std::basic_string<char, std::char_traits<char>, std::allocator<char> >'

and:

Code: Select all

OgreOdeDebugObject.h:20: error: `OgreOde::DebugObject::Mode' is not an aggregate type
I'm sure I'm missing something basic with these...would someone care to embarrass me?! :)

Thanks.
marcoc
Gnoblar
Posts: 9
Joined: Fri Jan 02, 2004 10:18 am
Location: Milano, Italy

Post by marcoc »

You can fix the first error by changing

Code: Select all

String::BLANK
with

Code: Select all

StringUtil::BLANK
and the second by removing the enum type name. So

Code: Select all

DebugObject::Mode::Enabled
becomes

Code: Select all

DebugObject::Enabled
I have just discovered that my xcode is not up to date, maybe I'm using old libraries...
Smithers
Gnoblar
Posts: 6
Joined: Mon Jul 05, 2004 10:07 pm
Location: Banbury, England

Post by Smithers »

Thanks again marcoc, were those just differences with gcc? I'll admit to being very rusty with C++ since I haven't coded in it for a couple of years!

Everything compiles fine now except for a few errors like:

Code: Select all

/usr/include/gcc/darwin/3.3/c++/ext/stl_hashtable.h:580: error: no match for call to `(const __gnu_cxx::hash<dxGeom*>) (dxGeom* const&)'
So apparently there are problems with the hash maps after all...damn, so close!

I'll have to read up on STL...there must be a simple solution!
marcoc wrote: I have just discovered that my xcode is not up to date, maybe I'm using old libraries...
I updated to 1.5 a few days ago, a worthwhile update but won't fix the problem!

Thanks again for your help.
User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA

Post by psiegel »

The stuff you guys have encountered pretty much exactly mirrors what I've seen trying to compile OgreOde in linux (Mandrake 10.0). I also had to clean up the enums, and then define the hashmaps as marcoc did. Everything compiles and when I load the test app I can see the empty plane just fine. However, as soon as I hit any of the F2-F5 keys, the app hangs. Pressing F1 works until I press a key to drop one of the objects, and then it freezes.

The log doesn't show anything of interest either, just the final entry of loading the appropriate mesh and texture for the new object. I'm not really sure where to go next to try and debug this, as I have no info to go on. Anyone have any ideas?

Paul
User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA

Post by psiegel »

Did some more tests, and thought I'd report in case anyone had some ideas. So, suspecting that the HashMap fixes were at fault, as it was the only major code change I made to make OgreOde compile under linux, I decided to try changing them to just std::<map> objects. Based on their usage, I saw no reason they needed to be hash_maps and not just standard maps.

Once again this compiled fine, but causes the app to hang the moment a mesh is loaded. I noticed though, that there is an error appearing at the end of the standard output:

Code: Select all

Fatal signal: Segmentation Fault (SDL Parachute Deployed)
Not entirely sure how helpful that is, but it's something.

Paul
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

I decided to try changing them to just std::<map> objects. Based on their usage, I saw no reason they needed to be hash_maps and not just standard maps.

That's probably a good idea anyway. I'll make those changes (and the enum stuff) to my code base too 'cos it should simplify this in future.

Unfortunately I don't currently have access to a Linux box, but in future I'll try and make sure that it at least compiles under mingw, which should simplify porting shouldn't it?
User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA

Post by psiegel »

I have a little more info on the crash in linux, though it's not much. I'm sort of learning to debug C++ apps in linux at the same time, so bear with me.

It appears the crash occurs in OgreOdeTest.cpp in the function createRandomObject(). Specifically, it happens when attempting to set the scale of the created node (lines 105, 116, or 129). Simply commenting out this (assuming I would get oddly sized objects) only makes the app crash on the subsequent call to body->setMass().

I wonder if this might be something more to do with the size object? I'll keep hammering away at this, but I figured I should report any progress in case monster or anyone else has any ideas on what might go wrong at this point in the code.

Paul
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

I've had some success with Ogre 0.41 and XCode 1.5 with OS 10.3+updates.

I'm not using the STLport and the samples run quite well. Also, I made some changes to the XCode project files, perhaps these have already be incorporated into the CVS? But I'm seeing some problems with the Terrain and Water demos. I can post details if anyone's interested.

Regardind OrgeODE, the fun part! I removed the non-aggregate types and changed stdext::hash_map to std::map. There seems to be some differences between the MS and GCC STL extensions. I tried compiling with STLport under WinXP and it had a lot of problems too.

However, I'm getting a linker error with ODE. I compiled up libode.a (version 0.5) and I'm getting some problems like missing _dCreateTriMesh (I hope that's correct - writing this from memory). Hope to have it fixed on the weekend.
User avatar
psiegel
Kobold
Posts: 28
Joined: Sun Aug 29, 2004 5:51 pm
Location: Boston, MA

Post by psiegel »

However, I'm getting a linker error with ODE. I compiled up libode.a (version 0.5) and I'm getting some problems like missing _dCreateTriMesh (I hope that's correct - writing this from memory). Hope to have it fixed on the weekend.
I ran into that one myself. You need to compile ODE with OPCODE enabled. In your ODE source, edit the file config/user-settings and uncomment the line that says:
OPCODE_DIRECTORY=OPCODE

You don't need to download anything, ODE 0.5 comes with the OPCODE source. Just uncomment the above config line and recompile ODE.

Paul
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

Thanks I got it working

But, the physical simulation doesn't run, it looks like the collision mesh is some way from the actual object. So, when it starts up the collision mesh is already on the floor plane, and nothing moves.

Have you seen this before?
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

Hmmmm, looks like using std::map doesn't work.
Anyone getting any other ideas?
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

Got it working. std::map was ok, I made a mistake elsewhere
Here's an image

Image
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

I fixed a bug with the apache demo, prevents it from crashing when a rocket expires. This happens if you use std:map.

How do I submit this change?
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

I fixed a bug with the apache demo, prevents it from crashing when a rocket expires. This happens if you use std:map.
Cool, thanks.
How do I submit this change?
If you let me know I'll add it to my list of things I need to change before I release another version.

Eventually OgreOde will be in Ogre addons, but I'm busy with other stuff for the next few weeks.

Thanks again for your efforts. I'll endevour to make the code a bit more portable "out of the box" in the future!
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

Just thought I'd let you know I've manged to make a version of OgreODE for OSX (and probably Linux) that uses the GCC hash_map, i.e. you don't have to change it to std::map - but there are still some changes
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia

Post by monster »

Cool, is there any difference in performance?
User avatar
thegame
Gnoblar
Posts: 23
Joined: Tue Aug 31, 2004 7:50 am

Post by thegame »

So apparently there are problems with the hash maps after all...damn, so close!

I'll have to read up on STL...there must be a simple solution!
Smithers, did you find a solution to that (since I am too lazy to read into STL :oops:) . I am compiling under linux and getting the exact same problem .

There is another error though, anyone seen this one before ??
OgreOde::Geometry' is implicitly friends with itself
Linux Rocks!!!
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

thegame wrote: So apparently there are problems with the hash maps after all...damn, so close!
Essentially you need to define the hashing functions. These are required by the GNU STL hash_map implementation. My guess is that the MS VC.NET version of hash_map provides these already in some way, perhaps through void* casting. The simplest approach is to use the pointer address as the key into the hash map. I've been working on a version of OgreOdeWorld.h that does this. At the start of the header, after #include <OrgreSingleton.h>, it looks a bit like this:

Code: Select all

// define a namespace alias 'Sgi' to be used for the approp STL Extension we've got
// if the compiler is MSVC 7.1
#if defined (_MSC_VER) && (_MSC_VER == 1310)
  #include <hash_map>
  namespace Sgi = stdext;               // MSVC 7.1
  #define EXT_NAMESPACE stdext
// if the compiler is GCC (from http://gcc.gnu.org/onlinedocs/libstdc++/faq/#5_4)
#elif __GNUC__
  #if __GNUC__ < 3
    #include <hash_map.h>
    namespace Sgi { using ::hash_map; }; // inherit globals
  #else
    #include <ext/hash_map>
    #if __GNUC_MINOR__ == 0
      namespace Sgi = std;               // GCC 3.0
      #define EXT_NAMESPACE std
    #else
      namespace Sgi = ::__gnu_cxx;       // GCC 3.1 and later
      #define EXT_NAMESPACE __gnu_cxx
    #endif
  #endif
#else
  // another compiler?
  #include <hash_map>
  namespace Sgi = std;
#endif

// define 'hash' functions - as we can't use the namespace alias here we use a macro
#if __GNUC__
namespace EXT_NAMESPACE
{
    template<> struct hash<dBodyID>
    {
        size_t operator()(const dBodyID x) const
        {
            return hash<dBodyID>()(x);
        }
    };

    template<> struct hash<dJointID>
    {
        size_t operator()(const dJointID x) const
        {
            return hash<dJointID>()(x);
        }
    };

    template<> struct hash<dJointGroupID>
    {
        size_t operator()(const dJointGroupID x) const
        {
            return hash<dJointGroupID>()(x);
        }
    };

    template<> struct hash<dGeomID>
    {
        size_t operator()(const dGeomID x) const
        {
            return hash<dGeomID>()(x);
        }
    };

    template<> struct hash<dSpaceID>
    {
        size_t operator()(const dSpaceID x) const
        {
            return hash<dSpaceID>()(x);
        }
    };
}
#endif
This creates a namespace alias called Sgi. So, you have to replace all references to stdext::X with Sgi::X.
However, in theory you should be able to define stdext instead of Sgi and you won't have to change the rest of the code. But I haven't tried this yet on GCC - seems ok in MSVC. Will give this ago under GCC soon.
OgreOde::Geometry' is implicitly friends with itself
On my OSX GCC compiler this was a warning rather than an error. You can simply remove the erroneous friend definitions, they're not needed.
User avatar
thegame
Gnoblar
Posts: 23
Joined: Tue Aug 31, 2004 7:50 am

Post by thegame »

thanks zibba, your hacks followed by a few changes finally got the lib created. OgreOdeTestApplication gave problems but _somehow_ fixed it to compile :wink: but running the test up just causes a seg fault ( not SDL). this after 3 hrs of sweat.... life is cruel :cry: , here's the grisly dump :?
Info: Freetype returned null for character 160 in font TrebuchetMSBold
GLTexture: Loading TrebuchetMSBoldTexture with 0 mipmaps from Image.
GLTexture: Loading font_matisse_itc.png with 0 mipmaps from Image.
GLTexture: Loading ogreborderUp.png with 0 mipmaps from Image.
GLTexture: Loading scr-up.png with 0 mipmaps from Image.
GLTexture: Loading scr-down.png with 0 mipmaps from Image.
GLTexture: Loading scr-thumb.png with 0 mipmaps from Image.
GLTexture: Loading scr-back.png with 0 mipmaps from Image.
GLTexture: Loading New_Ogre_Border_Break.png with 0 mipmaps from Image.
GLTexture: Loading New_Ogre_Logo.png with 0 mipmaps from Image.
Creating viewport on target 'OGRE Render Window', rendering from camera 'PlayerCam', relative dimensions L:0.00,T:0.00,W:1.00,H:1.00, Z-Order:0
Viewport for camera 'PlayerCam' - actual dimensions L:0,T:0,W:320,H:175
Creating viewport on target 'Ogre/ShadowTexture0', rendering from camera 'Ogre/ShadowTextureCam0', relative dimensions L:0.00,T:0.00,W:1.00,H:1.00, Z-Order:0
Viewport for camera 'Ogre/ShadowTextureCam0' - actual dimensions L:0,T:0,W:512,H:512
GLTexture: Loading spot_shadow_fade.png with 5 mipmaps from Image.
Render Target 'Ogre/ShadowTexture0' Average FPS: 0.000000 Best FPS: 0.000000 Worst FPS: 999.000000
Creating viewport on target 'Ogre/ShadowTexture0', rendering from camera 'Ogre/ShadowTextureCam0', relative dimensions L:0.00,T:0.00,W:1.00,H:1.00, Z-Order:0
Viewport for camera 'Ogre/ShadowTextureCam0' - actual dimensions L:0,T:0,W:512,H:512
GLTexture: Loading desert07_fr.jpg with 5 mipmaps from Image.
GLTexture: Loading desert07_bk.jpg with 5 mipmaps from Image.
GLTexture: Loading desert07_lf.jpg with 5 mipmaps from Image.
GLTexture: Loading desert07_rt.jpg with 5 mipmaps from Image.
GLTexture: Loading desert07_up.jpg with 5 mipmaps from Image.
GLTexture: Loading desert07_dn.jpg with 5 mipmaps from Image.
Segmentation fault
Linux Rocks!!!
zibba
Gnoblar
Posts: 12
Joined: Wed Sep 08, 2004 2:22 pm
Location: Melbourne, Australia

Post by zibba »

Hmmm my guess is it's crashing when the line _world = OgreOde::World(mSceneMgr) is executed in OgreOdeTestApplication.cpp (~line 114). After the desert textures are loaded it should try to load plane.mesh

This could mean that the path is wrong to the OgreOdeTest.zip which should be in Samples/Media/packs. There's a path defined for this in OgreOdeTestApplication.h (~line81)

But it's very hard to say without knowing your setup.