Question about the 1.1 timing problem

It seems from the posts that 1) If your framerate has dropped, then time has also slowed down, meaning at lap that is recorded as taking 1:30 is actually taking, say, 1:45 of real time. 2) If your framerate is the same or slightly faster than it was, then a lap which is recorded as taking 1:30 is actually only taking, say, 1:20 of real time. Is this a fair assessment of the situation? The reason I ask is that with the patch my framerate is the same as before (or slightly higher) and I am managing to equal my previous best laps. Does this therefore mean that I am actually lapping faster than before? This then begs the question - has the physics model been "dumbed down" to some extent? The Lotus certainly doesn't seem to be as much of a "handful" as it used to be, and I don't believe the addition of FF has made that much difference to my laptimes, especially as the rideheight for my setup has gone from 1" to 2.5". Also the cars seem much easier to keep in a straight line on the straights. Just some more fuel for the debate. Cheers.. Phillip.. p.s. Can anyone tell me where to get "spyboy"?

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

Sort of like the new compound in NR1999 vs. N2? Marc. <snip> Maybe it's just a new compound for those Firestones!

WHAT THE HELL ARE YOU TALKING ABOUT?! 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.

I think it has to do with the way these sims calculate your next position from the last frame. To do this they must know how much time will elapse before you see the currently being calculated 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

>stop me if I'm wrong.. OK. STOP. :-) 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

GPL has an unique way when it comes down to the physics model. 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

Quoted text (9 lines)

>WHAT THE HELL ARE YOU TALKING ABOUT?! >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.

mika- check out my post about 'more 1.1 fps weirdness', where i mention that my fps seems capped at 34 when offline, and the regular 36 when on. is this what you're seeing, too? 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

% WHAT THE HELL ARE YOU TALKING ABOUT?! 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. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=<[ /./. [- < ]>=-=-=-=-=-=-=-=-=-=-=-=-=-=