PureBasic Forum

You've done a great work here, idle! The "spatial map" idea is really interesting.

A hint for optimization:
I found that (on my PC, with PB 4.51; it may differ with other configs...) lists embedded in structure are slower than other solutions.
I have tested 3 solutions :
- embedded list: structure xxx:... List pointmass.pointmass_struct() ... endstructure
- embedded array: structure xxx:... pointmass.pointmass_struct[maxNbPoints] ... endstructure
- pointer to a memory zone where you store the objects' pointers: structure xxx:... *ptrPointList ... endstructure
=> with drawing disabled and the "F9" scenario, the latter is faster (but harder to implement/read) with 207 FPS, the second isn't far behind with 196 FPS, and the first (even if it's more elegant and easier to read) is significatively slower with 123 FPS.

That's why I originally used the pointers in my code, despite the fact they are a little harder to manipulate.

Made some improvements to the spatial map, it appears to run marginally faster when the objects aren't clumped together, though it still takes a performance hit when the objects are clumped together. (may still be something to fix)

Added a quick sprite test on F1

should we be including texture coordinates into a body and if so how to transform them?

http://www.idlearts.com/verlet.zip

Use the MP3D Engine. It is much faster s the native DirectX9 solution.

Thanks I'll have a look.
I was just thinking aloud about how to go about supporting the mapping of textures, If you only wanted to use PB sprites for rendering objects you need to store texture coordinates in the engine and update them in the verlet integration as they are separate to the bodies vertices if the object isn't rectangular, but if you used opengl for instance, you may not need the additional data all of the time.

MP3D is very interesting... if no can use maybe some of the ideas can eb salvaged into verlet?

Gave up on the Spatial map couldn't get it to perform better than the original structure.
Fixed some bugs in the verlet.
Have started adding support for PB textures and changed the drawing routines to create n sided convex polygons

There's still some bugs with alignment, seems to be the odd numbered sided shapes and the mapping is currently only symmetric.

Added Attractor and Repel forces, will generalize it later to provide multiple sinks and repels with a variety of force functions
it may be possible to use them to create paths instead of interpolating a spline.



Shape tests keys 3,4,5,6,8,9

http://www.idlearts.com/verlet.zip

Generalized Attractors and Repellers so they can be bound to objects

hi, Kelebrindae and idle,

Very nice, I love your work,
thanks for sharing it with us...

Marc,

Thanks marc

I've added a Pin body and a Join body routine, the join body needs a bit more thought.
There is also an issue in the friction calculations in the collision response that needs to be addressed. When objects are colliding in free fall they loose momentum against gravity which isn't the right response.
I noticed it when I had joined bodies together and flung them around, so they're now given a GroupID which is ok as long as you add a single object to an existing group.

The new tests F3 and F4

http://www.idlearts.com/verlet.zip

Converted code to run on linux and windows under opengl subsystem.
Added a dirty hull routine to Generate a body template from an image, this should be changed to compute a proper convex hull.
There are also issues to resolve generating constraints which may lead to some bodies being unstable.

Added Body Templates
It makes it easier to manage objects as you can simply refer to them by name
So you generate a body template from an image and then invoke the body from the template

Added a couple of mini game demos (incomplete)
Asteroid osmosis (become the biggest) left click to move
Pool Table (can't be arsed to finish it but the target coords are in the data section)

http://www.idlearts.com/verlet.tar.gz

Looks interresting. But there seems to be a small bug in line 136 of verlet2D.pbi so the tgz does not work in windows.

CompilerIf #PB_OS_Linux Or #PB_OS_MacOS ; is always true

CompilerIf #PB_Compiler_OS & (#PB_OS_Linux|#PB_OS_MacOS) ; should work

Greetigns,
auser

thanks
probably should be



I'll update it later

....why not just rename the structure and eliminate the CompilerIf?

this would be better

Soo... hypotethically, if I wanted to actually use this in a game, how do I make the simulation speed independent of framerate?