Real-Time Physics Simulation Forum

On this machine a GenToo Linux amd64. The libraries are available as are the includes. What kind of check is used to figure out OpenCL support is present? Autocools configure tests for include files or libraries? Which libraries are you testing? These are the files configure should find on a proper ...

Got the new 2.77 version to see how the OpenCL stuff works. ATI Stream SDK with samples works on my system but Bullet does not seem to use it. Inside the OpenCL marked samples I can run a cmake and get a Makefile but running make nothing happens. Any ideas how to get OpenCL running with the Bullet 2...

There is no normed way under Linux to detect 64-bit or 32-bit systems. Your code should compile on both systems without having to detect the bit-iness. Otherwise you've got a bigger problem going. EDIT: I should be a bit more accurate. There is no direct way to test it. While compiling __WORDSIZE is...

Correct me if I'm wrong but... doesn't x86-64 (aka SSE2) have 16 128-bit registers which you can feed with two doubles per register? So why should it not be possible to do SIMD with doubles?

Double precision is usually not the problem even if you have only a 32bit system. On 64bit double is actually slightly faster than float.

This compiler version is very old. Current version is 4.5 and a common version use is 3.4 . Anything below 3.x can give troubles as some compiler instructions have been added only in 3.x or even 4.x . If possible use 4.5 .

As mentioned, it's the include library file ( the *.a file, not the *.so one ) which is missing. And yeah, i meant libc, typo. Concerning verbose output maybe something like "-v" as command line. I don't know though as I don't like CMake one bit. Caused me more trouble than anything else. ...

Looks like CMake doesn't link against libpthreads ( link flags: -lpthread ). Your CMake output doesn't contain though the actually commands invoked so it's impossible to see what goes wrong. But it's definitely symbol resolve error so CMake missed pthreads for one reason or the other. Have you insta...

No need to be sorry for that. Everybody once had been a newbie. Just don't become a "n00b" and all is fine

For the moment I like pre-packs cause they are easier to use and as I develop on Windows. Seems like there is a lack of documentation for Linux for many engines. There a few months ago, OGRE had no documentation for MinGW since 1.6.0 but got it for Visual. Gonna take a look for SCons, thanks for th...

Ah yeah, stumbled across that one once too. Is though simply a pre-pack from the files you find on the MinGW Sourceforge page as well as the MinGW64 one. I prefer installing the files myself. I distrust pre-packs a lot since they tend to force choices upon you which don't work outside normed cases (...

Against which g++ version you compiled? As default MinGW has gcc 3.4 while advanced users tend to patch up their MinGW to gcc 4.4 or 4.5 . Either of them are not compatible with libs created in gcc 3.4 unfortunately.

I don't exactly remember but I believe that Code::Blocks MinGW version doesn't compile OGRE correctly so I deleted it and download the dragon team's one (recommended by OGRE). Actually as mentioned Code::Blocks uses the installed MinGW and uses this make program. So if you can build OGRE with MinGW...

I don't compile with Code::Blocks. I execute mingw32-make via command line. I'm using tdm gcc 4.5.0. The binary is 4.5.0 directly, I didn't any upgrades. So ? I can't use bullet with my application for the moment or is there a way to work despite this ? Didn't pay attention to the name of the missi...

Looks like you did not set up properly the include path. Code::Blocks totally fails at auto-detecting include and lib path so you have to manually set them in the compiler options window. Also which MinGW are you using? Stock with gcc 3.4.x or manually upgraded to gcc 4.5? I'm using 4.5 manual upgra...