Not for me, it works sweet. I love the stack with the shooting boxes… amazing.
Hm. Put the +0.05f thing back in. Right now you get massive over/understeer effects if it ran flat (yield pretty much 0) for a while. (So, there was a reason that I put it there… haha… my bad :))
And it also might knock out into the other direction as soon as yield hits Integer.MAX_VALUE. Heh. That might be a problem in 10 years 
There is no dependency on vecmath.jar any more - you’ve got a caching issue somewhere.
Kev
Kev,
Your stacking boxes works great! I looked into my code and It was
using fixed timesteps, so I have something wrong.
Just continue coding. I did this only to play a little, and since it didn’t work
well, I didn’t continue.
Rafael.-
Ok, the source is currently available here:
http://www.cokeandcode.com/phys2d/source/
And the demo is still at
http://www.cokeandcode.com/phys2d/phys2d.jnlp
It now shows contact points as the bodies collide - I think this will be useful for checking collision shape implementations.
I’ve just refactored out the collision routines so I can add circles next. Please bare in mind it’s very much a work in progress and I’m still trying to get my head round the maths involved. I’m still developing so it might be tricky if anyone wants to start adding stuff right now - if theres any real interest I’ll start some java.net or code.google.com (coogle?) projects to hold the source.
The source thats available right now is just a snap shot of what I’m working on - so there are still plenty of holes 
Right now thought I’m just enjoying playing with the demo way too much.
Kev
PS. I’ve tried to stick 1.4 compatible for personal project reasons.
Just added circles to the mix - seems the collision refactoring works ok. The demo has been updated with a few scenarions including circles rolling around.
I’ve been focusing on making it work rather than fast/light. There is work that needs to be done pulling the maths apart and making it optimal for speed and garbage. There’s also some stuff that would be nice to do for detecting static bodies and ignoring them.
Kev
Go show!
Waaa neato!
& thanks for the source ! So when is a billiards game coming out!?
Wow, this looks great kev ;D
Can we use this in our own games as long as we give you credit?
I slapped a BSD license on it - so you can use it as long as you credit the people mentioned in the license header (currently thats most importantly Erin Catto, and then Me).
However, I’m still toying with making this a community project if anyone else would be likely to contribute. What I don’t want to do is make it into a project that promptly dies.
I’m still actively developing it so I guess we can where it goes?
Kev
Would be a good project for the community. And an opportunity to try out Google Code (Subversion is cool)
Wow, this is awesome. 
Although,
java.lang.NullPointerException
at net.phys2d.raw.World.step(World.java:199)
at net.phys2d.raw.test.AbstractDemo.start(AbstractDemo.java:204)
at net.phys2d.raw.test.DemoBox.main(DemoBox.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.continueLaunch(Unknown Source)
at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
error in BodyList.java:
/**
* Remove a body from the list
*
* @param body The body to remove from the list
*/
void remove(Body body) {
elements.add(body);
}
Also it might get that nullpointer error when there are too many objects on the screen?
Already fixed. Problem with having the source not in an open repository.
I’m going to start a google project later this week. Havinng a bunch of issues with bounce not being configurable. Maybe a topic for somewhere else.
Kev
In AbstractDemo’s start() method, why is World.step(time) called four times with every iteration of the game loop? How come not just once?
And is there a thread that discusses the interesting ‘adaptive timing loop’ you’re using which you attribute to Master Onyx?
Thanks,
Keith
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.
Kev
http://www.java-gaming.org/forums/index.php?topic=11640.msg93602#msg93602
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?
I’m referring to this, from AbstractDemo:
// adaptive timing loop from Master Onyx
long timeNow = System.currentTimeMillis();
frameAverage = (frameAverage * 10 + (timeNow - lastFrame)) / 11;
lastFrame = timeNow;
yield+=yield*((target/frameAverage)-1)*damping+0.05f;
for(int i=0;i<yield;i++) {
Thread.yield();
}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.
Kev