It appears that you're not linking irrBullet properly.
Re-check your linker to make sure you have it setup correctly.
As for the CExampleFramework error, did you add the CExampleFramework header and implementation files to your project so you don't get the unresolved external symbol error?
Read the FAQ for how to properly setup irrBullet for your project.
If you don't mind, report back here and let me know if you resolved your issues or if you still need help.
Hi cobra, i have still link errors after adding the CExampleFramework header and implementation files.Are there anybody integrate with msvc 2008 and show how to do that?
Did you try building irrBullet yourself using the included MSVC 2008 project file in source/msvc/2008?
Also, did you refer to section 1.12 of the FAQ for information on how to resolve the undefined references?
Since you're on MSVC, you don't link against the GCC .a lib files, but you have to build your own Bullet libraries for MSVC 2008 and use those ones.
If you'd like, I can provide you with pre-built MSVC libraries. I didn't package them with the SDK because of the size it would be then for both 2008 and 2010.
I'm going through all the physics wrappers atm to find one that fits my needs best. Right now it's time to give irrBullet a shot.
Anyway, while I compiled the lib with ease under Linux, I encountered an issue which makes GCC complain and I wanted to make you aware of:
Source: exampleframework.h
It's the unnecessary qualifier before the function name. Maybe you'd want to remove it.
Oh, and some uppercase/lowercase issues also occur. While it doesn't matter on Windows, on Linux "someheader.h" and "SomeHeader.h" are not recognized as the same include directive. See "bulletworld.h"
Thanks for giving irrBullet a try. I'd like to know how the experience is for you.
I'll fix the extra qualifier. Neither MinGW GCC nor MSVC complain about these, so I don't catch them. It happens when I copy over the function name from the implementation file to the header file and forget to remove the qualifier.
Thanks for the report.
I'll also fix the upper- and lower-case differences.
Right now I'm still fighting with some weird linking errors (linking it against the Bullet libs from Gentoo Linux' Portage) which I'll have solved soon.
From a first glance your Wrapper seems to be very handy.
Brainsaw also did a wonderful job creating the irrODE wrapper but to be honest I'm not so impressed by the overall performance of ODE. Also in some cases the physics weren't too convincing. Moreover, Bullet seems to be under heavy development, ODE's - it seems - ceased two years ago.
If there's interest I could add a build target for Linux to your C::B projects.
Hey cobra!
Atm I have a Linux build target ready for the wrapper. I wanted the wrapper to use the Bullet headers that come with the installation of the lib (usually located under /usr/include) so I had to modify the preprocessor's #include directives. This uses some #ifdefs to make sure the windows version basically stays untouched.
Just tell me if, where and when you'd wand to have it.
Great to hear you can need it. Maybe I should also adapt the other example projects first, then I could send everything tomorrow morning (CET).
I'll PM all the stuff as soon as I'm done.
Well, my current project probably isn't going to end up using bullet physics (no fault of IrrBullet, related to Bullet itself and the needs of this particular project) but before I left I wanted to mention a few suggestions (based on 0.1.7):
1. Change list to core::list, I had to do this for my Mac builds for some reason or it kept confusing it with std::list even though I couldn't find any "using namespace std;" things in my code and it compiled fine on Windows/Android. Weird. Maybe due to something in my precompiled header setup in xcode.
2. Few places where a struct is later declared a class in forward declarations, no biggie but generates warnings
Raycasting doesn't have an interface just yet, but if you look at the custom irrBullet raycaster in IRaycastVehicle.h and .cpp, you will find out how to do raycasting in pure Bullet and use it with irrBullet. It's trivial at worst.
Either that, or you could wait until irrBullet 0.1.71, which will be released in early February with some extra things.
Polylux:
Thank you. I will include this with 0.1.71. irrBullet is getting better Linux support thanks to the help of you and the team at the Open Descent Foundation.
SethRobinson:
Thank you for the suggestions. I'll be sure to consider them for the next release.
Ok there is one really bad bug in your code.
The destructor of ICollisionObject isn't virtual. which seams to be fine for windows but causes segfaults on linux. please fix that. Thats a serious crash bug.
Second thing that has to be fixed is the tamporary irr::core::stringc in collisionshape.h line 77. you can not return a temporary reference and expect it not to crash.
We're programmers. Programmers are, in their hearts, architects, and the first thing they want to do when they get to a site is to bulldoze the place flat and build something grand. We're not excited by renovation:tinkering,improving,planting flower beds.
