Short answer on step(time) - it looked better. Longer answer - I don't know and it's one of the things I have on the list to work out. It seems like to me that the time step in a simulation effects the acceleration, and the only reference point we have for acceleration is gravity. Since my units are pixels (not scaled in anyway) then gravity is 10 down on the y-axis in pixels - which looks a bit slow. Running at 4 times the speed makes gravity look normal - I suppose upping the gravity would have the same effect.

The abstract demo is more just a test bed to check things don't break.

The adaptive timing loop was developed for the 4k contest - you'd have to ask Master Onyx for the linky.

It takes the averaged time of the last 10 frames (rolling average) and uses that for changing the number of yields proportionally... and there is some damping on top for keeping it smooth.

It over/understeers a little if the changes from one frame to the next are very extreme, but other than that it behaves very well. Even if the timer resolution is as bad as 250msec (win9x has the worst one with 50-55msec).

If you want to see how well it behaves print the yield value and the fps (but dont use frameAverage for that it isnt all that accurate (but its good enough as an input value )).

edit: With "print" I dont mean System.out.print... of course. Doing that each frame will lag the loop a lot.

Many thanks for explaining those 2 things. I'm just trying to figure out why a non-fixed step causes problems. I will try using a regular game loop time with System.nanoTime() & only one World.step(float timeElapsedSinceLastStep) per frame & report back if its fixed.

Maybe the combination of a slightly inaccurate time compounded by 4 updates per frame gives the weird behaviour.

PS: why do you count on yield taking a fixed amount of time? There is no guarantee that it will effectively 'sleep' the same amount with each call, is there? Especially on windows where there's a stack of other processes/threads waiting to execute - Thread.yield() may let them have a go, which could take any amount of time, will it not?

For reference I haven't had an issues using a variable time step - except that the simulation isn't predictable since the collision in this engine isn't swept and different amount of penetration occurs if you use different time steps.

* Hardness factors for elastic collisions [EDIT: This doesn't seem to be working well, extra energy creeping into the pool simulation]* Refactored code - now supports pluggable joints, broad collision strategies* QuadSpace collision strategy for more optimal body2body collisions detection* New collision shape: Line - not 100% on this one yet but seems reasonably. Useful only for static elements.

EDIT : Just 2 small questions : is the collision library separated from the core ? And : can I use your lib in a strategy game with 2D-movement ? actually I use my own detection thingy but it's naive On2 cost so I saw you implemented quadTree so it's interesting

@CommandKeith - thanks for the code - I'll use it locally but for personal reasons (GCJ) I need the project to stick to 1.4 right now (this might change if it just gets too plain annoying )

@Magic - currently you could use the collision system with getting response or doing the physics computations by subclassing World. However, if this is a possible usecase I'll refactor the world so it can do this without effort.

I'm not intending to add a Fluid layer but if it just sphere then yes it's fine. However, not something I've ever thought of so if it's useful

To Do in no particular order:

- Fix hardness/elastic collisions- Refactor collision so it can easily be used seperately - Test line collisions further and expand to line/line- Add polys (either by using multiple lines - or some other neat system)- Fixed Joints - joints which don't allow rotation so we can bind bodies together in one lump- Body collision control - define bodies that don't collide against each other (useful for a bunch of situations)- Body collision feedback and control - registering a listener against the world to be notified of collisions and determine whether response should be computed.- Performance/Memory - Static Body detection(These issues are recorded here: http://code.google.com/p/phys2d/issues/list)

If anyone has things to add to the list or wants to get involved with the source (I'm not sure how this works with the google code system yet) then let me know here.

I'd be glad to help with the source, but I'm still getting my head around it. If you could explain how the box-box collison works or put a couple more comments in I can try to use the ideas for polygons.

Thats a really good question - I don't really understand box/box collisions - I ported it straight from C. While porting I picked up some of it - but code line for code line I don't get.

Essentially it projects one box onto the other box's face axis. It determines if these projected points are on the same side of the face as the centre of the other box. It then clips the points to the segments that actually build up the face. Then some mojo (read: this is the bit I don't get) cuts if the projected points arn't on the faces to detect whether its a corner hit. If the points are on the same side as the centre they're determined as collision points.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org