Eureka bullet 64 bit on windows builed

Well i finally succeded in building the binding.



→ current bullet was used(2.80)

→ precompiled mingw64 project was used

→ Forcing 64 bit compile

Code:
C:workspacebullet_svn>cmake . -DBUILD_SHARED_LIBS=OFF -DBUILD_DEMOS:BOOL=OFF - DBUILD_EXTRAS:BOOL=OFF -DCMAKE_BUILD_TYPE=Release . -G "MinGW Makefiles" -DCMAKE _C_FLAGS=-m64 -DCMAKE_CXX_FLAGS=-m64
-> Fixing multiple popping up errors with precision loss, by replacing lines like
Code:
wuInput.m_pairArrayPtr = reinterpret_cast<uint64_t>(pairArrayPtr); with wuInput.m_pairArrayPtr = reinterpret_cast<uintptr_t>(pairArrayPtr);
According to a random internet post, tahts the right datatype to use whyever.

-> After 3or4 of those modifications static build of bullet in 64 succeded
-> Rest as usuall with the build script,
-> Needed to comment linkerarg value="-Wl" , for some reason the 64bit mingw is unable to use it.

-> Fired up a jdk7 with 64 bit loaded the created dll and everything fine.


(while I would like to post the dll, it should be noted, that I use physic only serverside, and use a double precision jme scengraph and custom physic binding branch for that (SPace games just needs 64 bit for great solarsystems ^^). However the difficult part was to bring bullet to compile in 64 bits.
Code:
Creating AssetManager/LoaderThread Mai 07, 2012 3:37:55 AM com.jme3.asset.DesktopAssetManager <init> INFO: DesktopAssetManager created. Creating PhysicsSpace Running on Windows 7 on amd64 Bullet-Native: Initializing java classes Vector3dStart initialize Vector3dVector3dVector3d_toArrayVector3d_xVector3d_yVector3d_zDone initialize Vector3dQuaternionLoading Terrain8x8 Loading terrain terrains/developer_island/ Terraintile 0,0 Mai 07, 2012 3:37:55 AM com.jme3.texture.Texture read SEVERE: Cannot locate texture /terrains/developer_island/mesh_TX.png (Flipped) (Mipmapped) Mai 07, 2012 3:37:55 AM com.jme3.material.MaterialDef <init> INFO: Loaded material definition: Phong Lighting Mai 07, 2012 3:37:55 AM com.jme3.bullet.collision.shapes.MeshCollisionShape createShape INFO: Created MeshCollision Mesh 3d70f0 Mai 07, 2012 3:37:55 AM com.jme3.bullet.collision.shapes.MeshCollisionShape createShape INFO: Created MeshCollision Shape 3d7200 Mai 07, 2012 3:37:55 AM com.jme3.bullet.objects.infos.RigidBodyMotionState <init> INFO: Created MotionState 100d59a0 Mai 07, 2012 3:37:55 AM com.jme3.bullet.PhysicsSpace finalize INFO: Finalizing PhysicsSpace 40ff80 Mai 07, 2012 3:37:55 AM com.jme3.bullet.objects.PhysicsRigidBody rebuildRigidBody INFO: Created RigidBody 100d5ae0 ....

So far no sideffects (just better performance)
5 Likes

Awesome. When can we expect an dll for testing?

As said its a double precision dll, wich wont work with jme out of the box, but this thread should help the ones that are already succeding in building 32 bit themselves in making the 64 bit version available for everyone.

I’ll see how I can integrate this into the build, could you post a diff for bullet that I can integrate? Btw I think theres some defines for these types that also get switched when changing 32/64bit, maybe we should use these instead… (I guess thats the problem in the first place)

You probably want to undo the doulb eprecision defin in btScalar first.



This should be the stuff.

Code:
Index: src/LinearMath/btScalar.h =================================================================== --- src/LinearMath/btScalar.h (revision 2537) +++ src/LinearMath/btScalar.h (working copy) @@ -16,6 +16,8 @@

#ifndef BT_SCALAR_H
#define BT_SCALAR_H
+#define BT_USE_DOUBLE_PRECISION
+

#ifdef BT_MANAGED_CODE
//Aligned data types not supported in managed code
Index: src/BulletMultiThreaded/SpuCollisionTaskProcess.cpp

— src/BulletMultiThreaded/SpuCollisionTaskProcess.cpp (revision 2537)
+++ src/BulletMultiThreaded/SpuCollisionTaskProcess.cpp (working copy)
@@ -132,7 +132,7 @@
// no error checking here…
// but, currently, event queue can be no larger than NUM_WORKUNIT_TASKS.

  •   taskDesc.m_inPairPtr = reinterpret_cast&lt;uint64_t&gt;(MIDPHASE_TASK_PTR(m_currentTask));
    
  •   taskDesc.m_inPairPtr = reinterpret_cast&lt;uintptr_t&gt;(MIDPHASE_TASK_PTR(m_currentTask));
    
      taskDesc.taskId = m_currentTask;
      taskDesc.numPages = m_currentPage+1;
    

@@ -234,7 +234,7 @@
(reinterpret_cast<SpuGatherAndProcessWorkUnitInput>
(MIDPHASE_ENTRY_PTR(m_currentTask, m_currentPage, m_currentPageEntry)));

  •   wuInput.m_pairArrayPtr = reinterpret_cast&lt;uint64_t&gt;(pairArrayPtr);
    
  •   wuInput.m_pairArrayPtr = reinterpret_cast&lt;uintptr_t&gt;(pairArrayPtr);
      wuInput.m_startIndex = startIndex;
      wuInput.m_endIndex = endIndex;
    

Index: src/BulletMultiThreaded/SpuSampleTaskProcess.cpp

— src/BulletMultiThreaded/SpuSampleTaskProcess.cpp (revision 2537)
+++ src/BulletMultiThreaded/SpuSampleTaskProcess.cpp (working copy)
@@ -121,7 +121,7 @@
// no error checking here…
// but, currently, event queue can be no larger than NUM_WORKUNIT_TASKS.

  •   taskDesc.m_mainMemoryPtr = reinterpret_cast&lt;uint64_t&gt;(sampleMainMemPtr);
    
  •   taskDesc.m_mainMemoryPtr = reinterpret_cast&lt;uintptr_t&gt;(sampleMainMemPtr);
      taskDesc.m_sampleValue = sampleValue;
      taskDesc.m_sampleCommand = sampleCommand;
    

Index: src/MiniCL/MiniCL.cpp

— src/MiniCL/MiniCL.cpp (revision 2537)
+++ src/MiniCL/MiniCL.cpp (working copy)
@@ -478,7 +478,7 @@
if((sLocalBufUsed + size16) > LOCAL_BUF_SIZE)
{ // reset
spLocalBufCurr = sLocalMemBuf;

  •   while((unsigned long)spLocalBufCurr &amp; 0x0F) spLocalBufCurr++; // align to 16 bytes
    
  •   while((uintptr_t)spLocalBufCurr &amp; 0x0F) spLocalBufCurr++; // align to 16 bytes
      sLocalBufUsed = 0;
    
    }
    void* ret = spLocalBufCurr;
1 Like

Cool, zjamls

Edit: lol, zjamls?? I mean “thanks” ^^

1 Like