I dug into the official Chipmunk source, and apparently all the Destroy()s "implement me"
should be noops on the Go port, since the purpose of it was to clear from memory in ObjC, but
Go's GC takes care of it.

The Destroy() instances:

This is not a Destroy, but seems to be unused internally:

Or maybe the Destroy() method can be removed from the ShapeClass interface, since it's never used internally. What do you think?

I'll create a PR. Please let me know if there's a use case I'm missing.

It falls apart more easily than the chipmunk demo does.

As a optional function, obviously. It would have its uses in quite a few different cases, most notably where you need more than 32 possible collisions.

It should stand until touched.

Going to https://goreportcard.com/report/github.com/jakecoffman/cp reveals a few minor issues that should be easy to fix, probably the most significant being that line 115 of space.go should be on a pointer receiver instead of a struct itself.

Hi, i am having trouble using the applyImpulse function because I observe unexpected behavior.

I have a circle body to which I apply an impulse (local point = zero).
Right before and after the apply, I log the velocity of the body.
Why is it that a positive X component (here 49) is causing a new velocity in the opposite direction?

7:48AM DBG sprites/moveable_sprite.go:44 pre apply impulse vx=-0.2918252140476518 vy=24.166954594470702 fx=49 fy=-3
7:48AM DBG sprites/moveable_sprite.go:46 post apply impulse vx=-37.113445811790115 vy=-8.301002787475994

When apply an impulse on a zero-velocity situation then the resulting movement is as expected.

Hi! Awesome library. I have a couple specific use case that would work perfect for the shape query api that is in the C implementation but I can't seem to find it in this port? https://chipmunk-physics.net/release/ChipmunkLatest-Docs/#Queries-ShapeQueries

However I could probably work around this by adding a shape to bodies in the scene that are in the scene that don't move and add a sensor shape. This isn't ideal for many of my use cases, but I could probably make it work.

I noticed that chipmunk seems to have its own, non-atomic(?) locking system. Are any query functions (such as BBQuery) safe for concurrent access as long as it is not updating simultaneously?

CP has UserData, very needed, and EachShape appears missing.

Place a box on the scale, let it deactivate. The weight goes up when it deactivates.

• LogoSmash,//A
• PyramidStack,//B
• Plink,//C
• BouncyHexagons,//D
• Tumble,//E
• PyramidTopple,//F
• Planet,//G
• Springies,//H
• Pump,//I
• TheoJansen,//J
• Query,//K
• OneWay,//L
• Joints,//M
• Tank,//N
• Chains,//O
• Crane,//P
• ContactGraph,//Q
• Buoyancy,//R
• Player,//S
• Slice,//T
• Convex,//U
• Unicycle,//V
• Sticky,//W
• Shatter,//X

For example, just putting v0.1.0 would be happy to everyone who uses go modules.

I was using another version of Chipmunk for go (vova616's version ) and it had a method on the Body called AddVelocity that was very useful. I added it to your Body and it works great maybe you should add it ?

func (body *Body) AddVelocity(x, y float64) {
	body.v.X += float64(x)
	body.v.Y += float64(y)
}  

Hello again :) I've been using your awesome port for a bit and ran into this issue.
When using space SegmentQuery and the space is setup to use a spatial hash the engine will crash due to:

github.com/jakecoffman/cp.(*SpaceHash).SegmentQuery(0x3f91111111111101?, {0x97a100?, 0xc000694690?}, {0x4077700000000000?, 0x3ff0000000000000?}, {0x3fb999999999999a?, 0x0?}, 0x9?, 0x0?, {0x0?, ...})
        C:/Users/beebl/go/pkg/mod/github.com/jakecoffman/[email protected]/spacehash.go:239 +0x5d1
github.com/jakecoffman/cp.(*Space).SegmentQuery(0xc0006ac000, {0x3f91111111111111?, 0x7dcf65?}, {0x1ddec26e158?, 0x40?}, 0x4014000000000000, {0x0?, 0x8?, 0x1ddec210a20?}, 0x9d73f0, ...)
        C:/Users/beebl/go/pkg/mod/github.com/jakecoffman/[email protected]/space.go:1046 +0x216

This is because SpaceHash::SegmentQuery is expecting the obj interface to be an instance of Shape and not SegmentQueryContext which is passed into it by shape::SegmentQuery.

I suspect this is broken with the other query functions as well, but I haven't had time to check.

The workaround is to not configure a spatial hash.

I'm not sure if I need to use a spacial hash or not, but I need to support a few thousand collision objects in my project. I'll not use the spatial hash for now.

Here is a small example of the problem and you may comment out the line that sets up the spatial hash to see segment query does work in that case:

https://gist.github.com/steampoweredtaco/ecf8aa13ba26d4cad7e54962bc1453d7

This should detect, but does not:

Can

func (space *Space) BBQuery(bb BB, filter ShapeFilter, f SpaceBBQueryFunc, data interface{}) {
	context := BBQueryContext{bb, filter, f}
	space.Lock()

	space.staticShapes.class.Query(&context, bb, space.bbQuery, data)
	space.dynamicShapes.class.Query(&context, bb, space.bbQuery, data)

	space.Unlock(true)
}

be optimized to :

func (space *Space) BBQuery(bb BB, filter ShapeFilter, f SpaceBBQueryFunc, data interface{}) {
	context := BBQueryContext{bb, filter, f}

	space.staticShapes.class.Query(&context, bb, space.bbQuery, data)
	
	space.Lock()
	space.dynamicShapes.class.Query(&context, bb, space.bbQuery, data)
	space.Unlock(true)
}

If the vector is zero, Normalize() returns NaN. For example, If the player velocity vector is zero, an error is received. To fix it replace math.SmallestNonzeroFloat64 -> 1e-15

zeroVector := cp.Vector{0, 0}
// Normalize Vector
fmt.Println(zeroVector.Mult(1.0 / (zeroVector.Length() + math.SmallestNonzeroFloat64)))
fmt.Println(zeroVector.Mult(1.0 / (zeroVector.Length() + 1e-15)))
// NaN,NaN
// 0.000000,0.000000

#As far as I can tell, Space does not expose any mechanism to query for shapes/bodies in an area (cpSpaceBBQuery in the C version). Is it possible to access the BBTree for a Space (even if it is read-only) for calculating things like field-of-view for a game, or could a BBQuery function be added?