Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualL. Spiro

Posted 23 November 2012 - 01:51 AM

nonsense.

My stuff was running at 333Hz back in 2001, from 333Hz to 1000Hz now.

And your “stuff” is more than a very basic 3D game or medium-sized 2D game with no physics?
These update rates are absolutely completely unacceptable. See below for why.

Run whatever physics time step you need in order to satisfy the stiffness of your physics subsystem and the requested collision fidelity.

Again, hiding the problem does not fix the problem.

The major question this brings to mind is why you seem to think you need to update logic 1,000 times per second when everyone else is fine with 30 or so.
Starsiege: Tribes is fluid and solid at 32 updates per second.
Monday Night Combat runs at either 30 or 33.3 (I forgot the specifics). So does Unreal Tournament 2003 and Gears of War.
Games using my old engine update at 33.3 times per second. Simulation Golf, Gigander X, Bakugan, etc.
All the games made by my company update at 30 times per second (60 in rare cases). Star Ocean 3, Star Ocean 4, Final Fantasy XIII-2, Final Fantasy XIII, War Corps, Valkyrie Profile, Resonance of Fate, etc.


Half of the games I listed use Bullet for physics, so there is absolutely no excuse for the original poster to be cranking his or her logical updates that high. It’s proved thoroughly that Bullet can run just fine and solid on 30 updates per second.


Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 meters-per-second (or easily 1,000,000 meters-per-second if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.
If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.
With the proper fix in place, not only can you stick with the lower and less CPU-consuming update rate, but you have actually truly solved the problem.

Please do not suggest that such an update rate has no drawbacks just because the things you have done with it weren’t enough to expose those drawbacks. You aren’t making “real” games such as Battlefield 3.
If you want to expose those drawbacks even on your small projects, set the update rate to 3,000,000 times per second. Proof that there is such a thing as an update rate that is too high.


Again and again I have to repeat: Increasing your update rate to avoid artifacts is nothing but hiding the problem. There is no problem that can’t be solved by any other means, and a higher update rate than what is absolutely needed is always a bad thing.
Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.


L. Spiro

#1L. Spiro

Posted 23 November 2012 - 01:47 AM

nonsense.

My stuff was running at 333Hz back in 2001, from 333Hz to 1000Hz now.

And your “stuff” is more than a very basic 3D game or medium-sized 2D game with no physics?
These update rates are absolutely completely unacceptable. See below for why.

Run whatever physics time step you need in order to satisfy the stiffness of your physics subsystem and the requested collision fidelity.

Again, hiding the problem does not fix the problem.

The major question this brings to mind is why you seem to think you need to update logic 1,000 times per second when everyone else is fine with 30 or so.
Starsiege: Tribes is fluid and solid at 32 updates per second.
Monday Night Combat runs at either 30 or 33.3 (I forgot the specifics). So does Unreal Tournament 2003 and Gears of War.
Games using my old engine update at 33.3 times per second. Simulation Golf, Gigander X, Bakugan, etc.
All the games made by my company update at 30 times per second (60 in rare cases). Star Ocean 3, Star Ocean 4, Final Fantasy XIII-2, Final Fantasy XIII, War Corps, Valkyrie Profile, Resonance of Fate, etc.


Half of the games I listed use Bullet for physics, so there is absolutely no excuse for the original poster to be cranking his or her logical updates that high. It’s proved thoroughly that Bullet can run just fine and solid on 30 updates per second.


Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 kilometers-per-hour (or easily 1,000,000 kilometers-per-hour if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.
If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.
With the proper fix in place, not only can you stick with the lower and less CPU-consuming update rate, but you have actually truly solved the problem.

Please do not suggest that such an update rate has no drawbacks just because the things you have done with it weren’t enough to expose those drawbacks. You aren’t making “real” games such as Battlefield 3.
If you want to expose those drawbacks even on your small projects, set the update rate to 3,000,000 times per second. Proof that there is such a thing as an update rate that is too high.


Again and again I have to repeat: Increasing your update rate to avoid artifacts is nothing but hiding the problem. There is no problem that can’t be solved by any other means, and a higher update rate than what is absolutely needed is always a bad thing.
Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.


L. Spiro

PARTNERS