Chipmunk and pointers (revisited)

This topic contains 6 replies, has 2 voices, and was last updated by peterigz 1 year, 6 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)

Author

Posts

September 23, 2017 at 6:14 pm #10749

Participant

I posted earlier on this year about the best way to pass pointer of the class in a chipmunk query and ended up using a “Me” field which worked well:

Class SpaceCraft Extends Window

    Field Me:SpaceCraft

   ..

   Method RenderSpace()	
      Local spacefilter:=cpShapeFilterNew( ULong(0), Players|MapTiles|Rocks,  Players|MapTiles|Rocks)
      cpSpaceBBQuery(Space, cpBBNew(0, 0, Width, Height), spacefilter, DrawSpaceCallBack, Varptr Me)
   End

End

Class SpaceCraft Extends Window

Field Me:SpaceCraft

Method RenderSpace()

Local spacefilter:=cpShapeFilterNew( ULong(0), Players|MapTiles|Rocks, Players|MapTiles|Rocks)

cpSpaceBBQuery(Space, cpBBNew(0, 0, Width, Height), spacefilter, DrawSpaceCallBack, Varptr Me)

End

Now that doesn’t work, I get an error in C++ when it compiles:

Monkey/MonkeyTuts/Spacecraft/Part-2/SpaceCraft.buildv1.1.08/windows_release/src/SpaceCraft_SpaceCraft.cpp:139:184: error: lvalue required as unary '&' operand

   cpSpaceBBQuery(this->m_Space,cpBBNew(0.0,0.0,bbDouble(this->m_Width()),bbDouble(this->m_Height())),l_spacefilter,g_spacecraft_SpaceCraft_DrawSpaceCallBack,((void*)((&this->m_Me.get()))));

Monkey/MonkeyTuts/Spacecraft/Part-2/SpaceCraft.buildv1.1.08/windows_release/src/SpaceCraft_SpaceCraft.cpp:139:184: error: lvalue required as unary '&' operand

cpSpaceBBQuery(this->m_Space,cpBBNew(0.0,0.0,bbDouble(this->m_Width()),bbDouble(this->m_Height())),l_spacefilter,g_spacecraft_SpaceCraft_DrawSpaceCallBack,((void*)((&this->m_Me.get()))));

I didn’t expect it to always work as Mark mentioned he’d run into similar issues with mojo3d and bullet physics and come up with a way of doing things better. So the question is now, what’s the best way to pass a monkey object pointer?

Example code can be found here if it helps: https://github.com/peterigz/Monkey2Tutorials/tree/master/Spacecraft/Part-2

Thanks!

September 23, 2017 at 10:04 pm #10754

Mark Sibly

Keymaster

I’ve thought about this a bit and I reckon the best thing to do is to just allow (explicit) object->void ptr->object casting.

This is basically what I did in mojo3d-physics. There’s some native code in there that casts to/from ptr via object_to_handle and handle_to_object functions.

You have to be careful of course. It’s up to you to keep the underlying object ‘alive’, and if you fail to do so and it gets GC’d you’re toast.

I handle this in mojo3d-physics by setting native user data to monkey2 object only when monkey2 object is added to world, and setting userdata back to 0 when it’s removed, eg:

Class World

	...

	Method Add( body:RigidBody )
		
		_bodies.Add( body )

		body.btBody.setUserPointer( object_to_handle( body ) )
		
		_btworld.addRigidBody( body.btBody,body.CollisionGroup,body.CollisionMask )
	End
	
	Method Remove( body:RigidBody )
		
		_btworld.removeRigidBody( body.btBody )

		body.btBody.setUserPointer( Null )

		_bodies.Remove( body )
	End

	Field _bodies:=New Stack<RigidBody>

	...

End

Class World

...

Method Add( body:RigidBody )

_bodies.Add( body )

body.btBody.setUserPointer( object_to_handle( body ) )

_btworld.addRigidBody( body.btBody,body.CollisionGroup,body.CollisionMask )

End

Method Remove( body:RigidBody )

_btworld.removeRigidBody( body.btBody )

body.btBody.setUserPointer( Null )

_bodies.Remove( body )

End

Field _bodies:=New Stack<RigidBody>

...

End

This way, btBody userdata is only non null if RigidBody is safely being kept alive in the World _bodies stack.

I was in fact thinking of adding a safer GCLock()/GCUnlock() system or similar and may yet still do so, but this is clearly a popular feature request so lets go nuts!