rec.autos.simulators

Yep.  The timing error generally tracks the fps you're getting vs the intended
36.

Nope.  If your fps is a bit quicker than it was, that's not an issue.  If
anything it should be a bit tougher to lap well sped-up.  The concern among
hotlappers is over those with low fps getting to drive in slo-mo, while their
reflexes are still at normal speed.  Kind of defeats the purpose.  Just do some
laps and time one against a stopwatch to see how close to realtime yours are
running.  It's all academic though, as they'll sort out the problem before too
long, I imagine.

Good question; it certainly seems easier, even with identical setups.  To test
this, rename your gpl.exe to gpl1.1.exe or some such and then copy the old one
(1.0) back into your gpl folder.  Then do some laps in 1.0 with a setup that
has over 2.5 inches of ride height, so it won't be affected.  Then quit, rename
the 1.1 exe file back to gpl.exe and try it again with all the setting equal.
Back to back, it's really not subtle.  Laptimes don't seem quicker, at least
without the benefit of slo-mo, but they are easier, and thus more consistent.
Like a bit more grip with a bit less ooomph.  Considering all the flack Papy
got for GPL's difficulty, it would be understandable, and perhaps even a good
move on their part if they did round the edges off a bit.  But who really knows
at this point?  Maybe it's just a new compound for those Firestones!

Cheers,

Steve B.

remove "edy" from address for email

Marc.

<snip>
  Maybe it's just a new compound for those Firestones!

stop me if I'm wrong.. but framerate is based on the number of frames per
second.
Frames.. PER SECOND!  Whether it's 2 frames per second, or 80 frames per
second, time still passes a second at a time.   So how can you say, if your
framerate is higher you are getting faster laps??
If your framerate is higher, you are going to do better because you can
react faster due to the higher framerate.  But that has nothing to do with a
direct relationship between higher frame rate=faster lap times.  It's just
your ability to react faster now that you are able to see more within a
second's time frame.

Eg. If you are travelling at 5 metres a second and the system is
calculating for one second ahead, then all the views, physics, etc,
are calculated for 5 meters from your last position, ( that is
assuming you're travelling at a constant speed in a straight line in
this simple example ). This would be a one frame per second case. If
the system was generating calculations based on say 5 frame per
second, then each position change would be one metre from the previous
position.

In all cases, to do the sums for the currently-being-calculated frame,
the program has to assume a time when the frame will be viewed, and
then number crunch it for that point in time. So how does the program
assume a time ? Presumably from your most recent frame rates actually
achieved. It may, say, take the average of your last three frames and
base its prediction ( ie guess ) for when the next frame will appear
on that. If your next frame appears on schedule then what you see will
look right, be in real time, and have the correct perspective for your
current position, and all is well in sim-land.

But what if the next frame actually appears at a different moment in
time from the predicted moment ? Then what you see will be wrong, and
out of time, for your movements in the sim world. If the frames
appeared too soon, then you will be further up the road than you
should, ( in the picture ), and things will be going too fast. If a
frame appears later than predicted, then you wont have moved far
enough ( in the picture ) and things will appear to be in slow-mo.

Now There's lots of things that the program might do about a
mistimed frame, including nothing at all. Eg., the program might ear
mark the frame to be released not before its appointed time. This
would avoid the situation of frames appearing prematurely and
therefore avoid fast-mos. But nothing much can be done if a frame
takes longer than expected to appear. The program can't really scrub
the frame, go back and calculate another one for the new point in
time, and then show that. The system could be tied up recalculating
frames willy-nilly. Even if its late, it still has to be uses as is.
The program can take into account the new frame rate and do a more
timely job of producing the next frame. One too soon or too late frame
here and there isn't going to cause a problem - maybe.

So The program really needs to be able to do a good job of
predicting when the next frame will appear. And it needs to be rather
conservative about it. As explained, a frame that's ready too soon can
always be held till the right moment but a late frame is simply wrong
and can't be fixed. ( This is why in GP2 for example, anything less
than 100% CPU occupancy will give you real time - if your frame output
is faster than expected they can simple be held for the right moment.
But once you go over 100% CPU occupancy then the whole visual
experience slows down. Obviously GP2 makes no attempt to guess when
the next frame will appear but takes its value from the
pre-established frame rates in the graphics setup screen, generates
the frames to that number, holds them if ready too early, but does not
adjust on the fly for slow ups. Well, that's one way to do it, and it
works great - so long as you're always below the CPU 100% occupancy
mark. Frankly I don't mind this approach. Its simple and you know
where you stand with it ).

So then what is GPL's problem ? Because it has come about as the
result of Papy trying to find new ways to clock-sync, one has to
assume that the next-frame-appear-time-prediction-routine has not been
sophisticated up to adapt to unusual frame rates cased by the new
clock-sync systems. Or it could be any number of subtle other related
things. ( The possibilities go on and on, or else it'd be easy to do
and anyone could do it )

Anyway my point is There's a difference between the actual frame
rate you are getting on your machine, which can be measured as a
historical fact of evens, and the frames ( pictures ) that you see,
which are generated for guessed-at points in time. If the two rates
are the same then everything is sweet, if not, then you get anything
from subtle to very severe affects of slow-mo or fast-mo, depending on
what the discrepancies are and how the program handles them.

It's a interesting problem. But we all want, real time, accurate time,
online and offline, and we want it now J

Phillip McNelley

er - the J was meant to be a :-) ( ***y MS Word strikes again :-)

PM

The problem is that with 1.1, a second's not necessarily a second.  With 1.0,
10 seconds of laptime took 10 seconds, regardless of the FPS you got while
driving, so the more FPS, the better for feedback, and thus laptimes.  In 1.1,
however, if you get 24FPS, 10 seconds of laptime will take about 15 seconds of
realtime, so your reflexes aren't tested as severely.  Conversely, if you get
38FPS, 10 seconds of laptime take a bit over 9 seconds of realtime.  This seems
not to affect everyone's system (or they just haven't noticed it yet), but the
more you vary from 36FPS, the more you'll notice it.  Drive some laps and use a
stopwatch to time the replay laps on your system.  You might be surprised!

Steve B.

remove "edy" from address for email

AFAIK the physics of the car are calculated 36 times per second and the
framerate depends on your system. If the framerate shows more than 36 fps,
the game (and the physics model) are indeed faster.

So if you get, say 38fps all the time (or 24-25fps all the time (or 34-35 as
I am getting)) the game is not running the same speed as the real time.
And your comments on the reaction time are still right.
This is how I have understood this, correct if I'm wrong...

Mika Takala

ICQ 14314015

as
I am getting)) the game is not running the same speed as the real time.
And your comments on the reaction time are still right.
This is how I have understood this, correct if I'm wrong...

Confusing or what! I don't know where frame rates fit with this observation,
but I find that the lap times are different depending on what view you use
to time the replay. The TV1 view gives a lap at Mosport 1.5 sec approx
faster than the In-Car view of the same lap. This is timed using the Papy
installed replay. When I timed a 1.25 lap of my own, the In-Car reapply
showed 1.25 sec, the TV1 1.22.60? If somebody has said this before sorry..
Steve

In GPL the frame rate is also tied to the speed the sim is operating.
It seems that somehow with the patch and some configurations this synch
is out of whack.  So frame rates can relate to how the sim simulates
time.

% stop me if I'm wrong.. but framerate is based on the number of frames per
% second.
% Frames.. PER SECOND!  Whether it's 2 frames per second, or 80 frames per
% second, time still passes a second at a time.   So how can you say, if your
% framerate is higher you are getting faster laps??
% If your framerate is higher, you are going to do better because you can
% react faster due to the higher framerate.  But that has nothing to do with a
% direct relationship between higher frame rate=faster lap times.  It's just
% your ability to react faster now that you are able to see more within a
% second's time frame.

--
**************************** Michael E. Carver *************************
     Upside out, or inside down...False alarm the only game in town.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./.  [-  < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=