Forums

cologne:
Change line 9 of game.h to
and recompile. The F1-02 is simulated much better at 1000 Hz!

Fast, faster,.....1000hz .-)

I don´t compile. I am using vdrift_20070327 Release, Mac PPC. -(

Ah, ok. :-) Well, to anyone else who races the F1-02 and compiles from source, give it a shot.

Well I can compare svn r1936 with r1942 modified with
#define FRAME_TIME 0.001
in line 9 of game.h.

The difference is amazing (maybe vamos changes also help), that's not the same game, F1 is much more drivable, it looks much much realistic.
I'll try to compile 1942 unmodified to see real FRAME_TIME difference.

So the question is, should we lower the frame time for the next release? It has benefits, particularly better physics calculation, but it has some drawbacks too, like slower performance. Another benefit is that it fixes some weird bugs like this one: http://code.google.com/p/vdrift/issues/detail?id=46

thelusiv Wrote:So the question is, should we lower the frame time for the next release?

the lower frame rate really kills performance on my laptop to the point where i can't play any more. i can always change it back to the old (current) value. the thing is if i increase it to 0.01 then the game behaves very, very strangely so something kind of depends on the current value but i am not sure exactly what.

--alex--

With framerate at 0001, I must close nearly all my windows to make it work (firefox, nautilus, ...).
Another point is that it exits badly when I press "quit" instead of "leave game" then "quit".
Processus is still alive with 300 Mo of memory used.

Except all these problems, the game becomes much better with this framerate.

Maybe we can try framerate at 0002 ?

framerate is a variable at runtime?

• Make framerate a parameter in config
  Make framerate a user defineable parameter
  Make framerate a software-cpu-test set parameter

[/list][/list]

I thought about making the physics framerate user-configurable but that introduces usability problems. Users don't know what to set this value at, nor do they know the consequences of it. Also, what value do we let them adjust, do we allow them to specify the number of physics ticks per second? Or should we give them a "physics quality" setting like Low (250/sec == 0.004), Medium (500/sec == 0.002), High (1000/sec == 0.001)? Again I foresee people setting their physics quality to "Low" on slow machines, and then posting bugs that are side effects of this, or just thinking that our physics simulation sucks and dumping the game. Then again, maybe that's better than just having to release it with this setting hard-coded at "Low".

thelusiv Wrote:I thought about making the physics framerate user-configurable but that introduces usability problems.

ideally one would want to tie in the physics framerate to the graphics framerate (within some limits of course). no point in doing 1000 physics frames a second if the graphics get updated only at 1 frame a second (or worse). not sure if this would be doable or not.

--alex--

Alex, there is a certain threshold, which, if crossed, will make the physics system really wonky. It is best we don't make it variable or in any way tied to graphics performance, as this could cause unexpected problems. Besides, graphics performance is mostly dependent on the video card, while physics performance is mostly dependent on the CPU. So tying one to the other really doesn't make much sense.

thelusiv Wrote:Alex, there is a certain threshold, which, if crossed, will make the physics system really wonky.

as i've discovered. looks like we are pretty much at the lower limit of the physics simulation. anything higher than 0.004 for FRAME_TIME makes the game behave really strangely. looks like we are at the "low" threshold. the idea of having a configurable FRAME_TIME parameter makes sense though and we should pursue it.

--alex--

I decided to split this into a new topic instead of continue in the F1 tuning thread.

I guess having a setting that the user can change is probably the best route, it gives the user the ability to control how good the simulation is or how CPU-intensive it will be.

I'll try to focus on improving performance. It'd be nice if we could run the physics tick at 1000 Hz but get the same performance as today. BTW, you don't want the physics tick to be matched to the graphics update rate because it really kills any kind of physics stability.

Okay, I've sup'd up the collision code. Can you run at higher framerates now on your laptop with R1946+? If so, how high can you go to get equivalent performance to the older revisions?