Page 11 of 31

Posted: Fri Jan 21, 2011 3:55 am
by cobra
Hi nuc_lear.

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. :)

- Josiah

Posted: Fri Jan 21, 2011 4:08 pm
by nuc_lear
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?

cobra thanks for interest ;)

Posted: Fri Jan 21, 2011 4:51 pm
by cobra
Hi nuc_lear.

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.

Posted: Sun Jan 23, 2011 1:19 am
by polylux
Heyhey!

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:

Code: Select all

irr::scene::IParticleSystemSceneNode* const CExampleFramework::createParticleSystem(...)
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"

Maybe this is of any interest. :)

Cheers,
p.

Posted: Sun Jan 23, 2011 4:29 am
by cobra
Hi polylux.

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.

- Josiah

Posted: Sun Jan 23, 2011 3:53 pm
by polylux
Thank you cobra!

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.

p.

Posted: Sun Jan 23, 2011 5:16 pm
by cobra
Hi Polylux.

Thanks for the comments, and I hope you get your linker errors sorted out soon.

It'd be nice if you could give me your C::B projects so I can add the Linux build targets. Thank you for the offer.

- Josiah

Posted: Mon Jan 24, 2011 9:50 am
by polylux
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. ;)

p.

EDIT: Raycast Tank also has a Linux target now.

Posted: Mon Jan 24, 2011 3:51 pm
by cobra
Hi Polylux.

I appreciate what you've done. Maybe you could send them to me via PM as soon as you can, and I can include them with the next irrBullet release.

Thanks.

- Josiah

Posted: Mon Jan 24, 2011 11:59 pm
by polylux
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.

Cheers,
p.

Posted: Tue Jan 25, 2011 11:04 pm
by SethRobinson
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

Posted: Tue Jan 25, 2011 11:20 pm
by polylux
Got it all packed, check your PM cobra! :)

Posted: Wed Jan 26, 2011 3:01 pm
by ent1ty
uhm ohm.... raycasting is still not implemented, right?

Posted: Thu Jan 27, 2011 3:57 am
by cobra
Entity:

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.

- Josiah

Posted: Fri Jan 28, 2011 12:05 pm
by sudi
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.