dm6 bridge to rail :D

quote:Original post by Anonymous Poster
It sounds like an ugly hack - why would you tie the physics/movement/etc to the framerate? I thought we''d have gotten past this by now.

This is not a hack but the way to go,

Like said before,
the physics is not tied to the framerate :
on PC typically you expect variable framerate and the same
will happen on Doom 3, some machine will only render at 40 fps max, some at variations between 10 and 60 fps depending on the resolution, the charge of the screen etc..

Imagine that you have a physic engine that run at a fixed granularity. You do that for many different reason. The first one and strongest one is consistency. Fixed granularity is quite opposed to a attaching physics to framerate. (attaching physics to framerate would create a lot of inconsistencies).

Now you have to decide a delay for this granularity. You cannot set it too high else slower machines might have difficulties to catch up and the game will simply not run at default detail.
I suspect that Carmack made it 60 update per seconds because it is the number that comes the most when you think of a comfortable framerate.

Of course you can render more than 60 frames per second. His engine won''t be blocked and might run at 100 fps for example. But simply, either you run these 100 fps in accelerated time (a replay for a benchmark for example) or if you run at normal speed then you end up drawing a frame twice (the aspect on screen simply doesn''t change).

You could imagine that animation might not be entirely tied to physics calculation, but interpolation could be the cause of some strange visual artefacts.

LeGreg

There was a discussion about this on the game algorithms list a year or two ago. It was gernerally thought that 10-20 Hz is all the physics system needs to remain stable. So you would have to have a way to schedule which frames need to calculate the physics frame or run physics in a thread of its own. That and you would need to interpolate for the other frames.

With 10 Hz you would need to delay rendering for 100 msecs to be able to interpolate.

quote:Original post by Max_Payne
...it seems that Quake 3 uses integers instead of floats for all vectors. In my opinion, thats just gay. Not only is it a dramatic loss of precision, but it also makes things harder to program...

while integeral calculations lose quite a bit of precision compared to floating point calculations, they are considerably faster. the native cpu is designed for integers; it''s only with a coprocessor that it can handle decimal numbers. of course, as technology increases (mmx, 3dnow, sse) this difference is minimized. but if you really care about speed and can stand to lose a small amount of precision by using integral values, switching from floats will make your code faster.

and if you are programming in a low-level language (i.e. assembler), integer calculations are *much* easier to code.

quote:Original post by Yann L
You are starting to get seriously annoying. You might find it funny to throw around mindless insults on the technical forums, but I don''t.

Probation. One more insult I see from you on this forum, and well, I think you can guess what comes next.

To everyone else: please, let''s keep this thread focused on the (interesting) topic of fixed vs. variable update rate for physics. Everything flame-ish will be deleted. Thanks.

Sorry. It won''t happen again.

I just thought it was epitome of hilarity to watch pre-teens(and mental pre-teens) argue over their favourite game developer/graphics card/programming language.