Laurent Defert Simonneau wrote:
You're right, the old physic engine would have been compliant with real world physics law, if the delta_t was really near to 0 (fr: la limite de delta_t tend vers 0), implying a screen refresh of an infinity of frame per seconds ... impossible even with the 70 TFlops of the Blugene supercomputer :) The problem with the new equations is that wormux is now unplayable on my computer, while physics were realistics with the old physic engine :/
Hum, why can't you play with the physical engine ?
Also, as haypo said, the physic engine can't be dependant with computer performances, because this will lead really hard issue within network games...
I don't think so. The new engine still use a "delta_t". If the refresh of the game is very fast, "delta_t" are small. If the refresh is slow, "delta_t" are big. But physical results are the same. In a network game, computation of physics and object move is a big use in a real time game. In a turn by turn game such as Wormux, I don't see were the problem comes from.
So the best thing to do would be to switch back to the old, physics system (http://cvs.gna.org/viewcvs/wormux/wormux/src/Attic/obj_physique.cpp?rev=1.13&content-type=text/vnd.viewcvs-markup) which was totally independant of the frame rate. (position of the object calculated in fonction of the position when the force was applied -> x= x0 + vx * (t-t0) + ax * (t-t0)^2 ) This system produces perfect parabolics movements, but will need differential equations to enable more complicated movement like with automatic bazooka, supertux, and other funky stuff.
I quickly read this code. This is what I was thinking to do at the begining. But as you say, you cannot do more complicated movements using this method.
As I'm not an expert in mathematic, and won't touch to differential equation, I propose the dirty solution to set a physics frame rate wich would solve the main network out of sync problem. For example, we set the physics frame rate to 100fps, in order to compute on every computer the exact same movement, independantly of the screen frame rate. What's really dirty in this is that we may compute physics many time between 2 screen frames.
Once again, I don't see the issue in a turn by turn game. Can you be more specific on problems we can encounter ? R.
